Helping Project Managers to Help Themselves

A couple of years back I was engaged on a project to help recover an agile project run amok.  The project was one of the first in the organization to use an agile development methodology and consisted of eight four-week sprints with six capability development teams.  The project manager was a very theoretical scrum master who was more concerned with having an agile "design win" than he was with ensuring the business sponsor was satisfied with the project result.  After about the third sprint there were significant issues with capabilities not working together, interfaces with external systems breaking, and problems with meeting sprint dates for committed capabilities.  To save the project, we had to take a number of steps that violated the purist agile model but were necessary if we were going to keep moving forward on the project.  Our implementation looked like a mishmash of agile and waterfall.  It wasn't pretty, but we eventually got the project done.

Ah, agile development.  I love the speed, focus, and excitement of seeing capabilities roll off the agile  assembly line.  I've had the pleasure of running some very successful projects where we delivered capability much faster than under waterfall.  I've also been involved in recovery projects like my earlier example where the brand of agile being used was fraught with schedule and scope issues and management was demanding change to get the project righted.  Through these experiences a few tenets became painfully clear:

1. Business stakeholders want something when they want it; they don't care how well the project adhered to a particular development methodology.
2. Agile principle adherence shouldn't become the focus of the project.  It is the vehicle in which a project gets implemented, not the reason for the project.
3. Agile doesn't mean skipping any kind of testing, particularly integration and regression testing. It just means you are compressing and overlapping and being less "over the wall" in test stages.
4. Successful agile requires focused business user involvement through design, development, and testing.  None of this "let me know when it's done" stuff.
5. Top down project management orchestration is crucial.  Empowering teams is important, but can't be taken to a point of anarchy.

Depending on where an organization is at in its systems development methodology journey, it may not be able to jump to a purist agile model and be successful.  I've learned that the following six principles are paramount in a successful agile project.

1. Embedded Power User - Having an experienced and forward-thinking dedicated user who can guide capability development and bring other users to the table as needed ensures that the capabilities under development will align to the business and will minimize capability gaps after implementation. The embedded power user also has a responsibility to know and communicate the current shortcomings as well as clearly articulate future state capabilities.
2. Time Fences - Rather than having team members set their own delivery dates, the project team needs to work to defined time fences and flex the work to hit the time fence.  Key to this is the project manager having some flexibility to alter a time fence if it makes sense to do so.
3. Governing Architecture - I watched an agile project with six capability teams go off the rails because each team was given too much architectural freedom of choice.  About five sprints into the project the capabilities didn't fit together because of individual decisions made by capability teams, creating massive rework.  There needs to be a concise functional and technical architecture that capability teams must snap to.
4. Small, Frequent Deployments - I like executing plans that have monthly capability releases.  It keeps the energy going, gives business users and stakeholders something to look forward to each month, and gives everyone something to celebrate each month. it also exposes weaknesses and integration challenges sooner than later.
5. Persistent Testing - Developers tend to like "grand reveals." where a capability isn't shown to others until the developer is sure everything works 100%.  I prefer to have testing and power users involved as close as possible to development to find problems early on.  There is a big trust issue that has to be overcome when you take this approach; the developer needs to not be randomized by "Are you done yet?" questions and needs to know that if something breaks during development the power user won't start launching flares that the product is of poor quality.  The developer, in turn, needs to avoid  the grand reveals where fixing problems later in the schedule becomes more expensive.  This also keeps the power users honest by minimizing late-breaking statements like "that's not what I want".
6. Strong Project Management - Agile isn't code for anarchy, and it's not a time when the PM is relegated to administrative errand-running.  The PM needs to be driving accountability, ensuring issues are being addressed,  risks are being mitigated, dates are being met, and scope is being adhered.  The PM also sets the communication rhythm for the team and works to keep the team on the same page. At the end of the day, the PM gets the first bullet if the project fails and needs to ensure everyone is doing his or her job to meet scope, schedule, and budget goals.

I've never seen a project manager get points because he or she followed the rules of agile on a failed project.  The first and foremost goal is agreed-upon scope delivered on time and within budget.  Keep the above principles in mind as you take on your next agile implementation to better ensure success and not get tied up in whether or not you're doing agile right.

So after you've celebrated that new job or promotion, the reality of what you've gotten into sets in. Now what? Where do I start? Who do I talk to? What are the most important things I need to address? Who can I impact if I do something wrong? Who can impact me if they do something wrong? The question list goes on, adding to the stress of taking the new job. Random execution not only translates to focusing on the wrong things, but also dramatically impacts your credibility with your manager, team, and stakeholders. The answer is not to arrogantly come into the job with all the answers, but to come in with a plan to understand the environment, draw conclusions on the most important things to focus on, and develop an execution plan to act on those conclusions. The answer is a 100-day plan.

First things first, your plan may not take exactly 100 days to complete. Depending on your situation it may take fewer days, or, if you are stepping into a major crisis, you may have to expedite the plan or do it concurrently with addressing the crisis. Generally speaking, your plan should not take more than 100 days to complete. The rationale is simple; you want to be viewed as someone who takes deliberate, thoughtful action, not someone who takes forever to figure out what needs to be done. If you can get it done faster and do quality work then by all means do so; just be deliberate in your action.

My 100-day plan focuses on six steps as shown in the graphic below, followed by more detail:

1. Develop a 100-Day What/Who/When/Asks Plan
2. Identify Who Informs, Concurs, and Decides
3. Understand What Works, Is Broken, and Could Be Better
4. Develop a What I Learned Summary
5. Create a What Actions Do We Need To Take? List
6. Develop an Execution What/Who/When/Asks Plan

Note: click on each graphic to see a larger, easier to read picture

The 100-day plan's purpose is designed to help you do the following:

• Understand who the key stakeholders are in and around your organization and the roles they play
• Identify what is working, not working, and could be working better in your area of responsibility
• Summarize what needs to be done and when it needs to be done by
• Communicate a clear execution plan of the most important things to focus on, who needs to do them, and when they need to be done by.
• Establish credibility with your manager, team, and other stakeholders as someone who listens and seeks to understand before taking action.

Following is an explanation of each of the six steps comprising the 100-day plan with an example of how the deliverable should look.

Step 1: Develop 100 Day What/ Who/ When/ Asks Plan

Step 1 is articulate your 100-day plan tasks, who will be performing those tasks, and when you anticipate the tasks being complete. Being "aggressively realistic" is important here; meaning you move the work forward as quickly as you reasonably can while ensuring a quality end product. Once you've determined the what, who, and when of your tasks, articulate any specific requests to your management to help you get the plan executed. Does your plan require travel which requires expense approval? Do you need your manager to provide an introductory email to some stakeholders informing them of your new position and that you'll be contacting them?  Think through what those "asks" are then do a plan review with your manager for concurrence and approval.

Step 2: Identify Who Informs, Concurs, and Decides

Step 2 is the development of an internal and external list of stakeholders who you want to interview as part of your current-state understanding. Internal stakeholders are those who are within your direct organization including direct reports, extended team members, and other people who impact or are impacted by the work your organization does. External stakeholders are those outside your organization who may or may not be impacted by your work but can provide good information on the current state. External stakeholders also can include experts outside of your company who provide information on industry trends, best practices, or other data points which could help give information about your future direction. For each stakeholder you should identify whether the stakeholder informs you (provides advice but is not directly impacted by your execution plan), concurs with you (doesn't formally approve your execution plan but you want/need their buy-in), or is a decision maker (formally approves your execution plan). I also think it's important to do a checkpoint with your manager as she/he may have additional stakeholders who are functionally or politically important to include, along with their appropriate inform/concur/decide status.

Step 3: Understand What Works, Is Broken, and Could Be Better

Step 3 is about interviewing your stakeholders to understand what is currently working, what's broken, and what might be working but could work better. This step is vital to not only understanding the current state but to establish a reputation with team members and stakeholders as someone who listens prior to taking action. I've found it helpful to focus on four areas in your works/broken/better discussion: organization strategy, people, processes, and technology. Depending on your situation these areas may be different. The last question I like to ask is, "If you were sitting in my chair, what are the top three things you would you do?" This is particularly effective not only in understanding items stakeholders think are important, but the priority they place on those things they identify. You may customize what you talk about depending on your stakeholder, but it's better to have a structure to work from then alter as needed, rather than totally winging it. Remember to interview your manager to understand his/her top priorities and perspectives.

Step 4: Develop What I Learned Summary

Step 4 is about taking what you've learned through your discussions and documenting trends and important facts that will influence execution plan actions. This is not an audit trail of everything you heard in every discussion; if you do that then you're likely to come out of the exercise with an unwieldy an non-actionable list. Conciseness and clarity are important here as this sets the stage for what you will focus on in your execution plan. You'll also want to do a checkpoint with your concur stakeholders to confirm you are focused on the right working/broken/better items and underscore that you've listened to what others have told you. Again, this is a crucial credibility builder with those you will be working with.

Step 5: Create What Actions Do We Need to Take? List

Step 5 begins the translation of what you've learned into what needs to be done to fix what's broken, improve upon what can be done better, and not disturb things that are working well. Each action includes three descriptive pieces of information: why it needs to be done, what the consequence if it isn't done, and when it needs to be done. Through articulating these factors you begin to develop a prioritized list of actions that comprise your execution plan. Do a checkpoint with your concur stakeholders prior to completing your execution plan.

Step 6: Develop Execution What/ Who/ When/ Asks Plan

Step 6 is about taking the actions in step 5 and creating a what/who/when plan which facilitates you working on the most important actions and getting them done first. It's totally reasonable to divide your actions up into phases, with your first phase of actions having a more detailed plan and subsequent phases being done once the first phase is complete. I can't stress enough the importance of focusing on the most important items from step 5 first and not getting distracted with trying to plan out all of your actions. In this step you'll do a concur checkpoint to ensure their buy-in prior to doing a decision maker checkpoint. You want to make best efforts to secure concur stakeholder buy-in and avoid having dissenting stakeholders discredit your conclusions and plan.

As mentioned throughout, your situation may require compression or expansion of the above steps. What doesn't change is the understand/conclude/act cycle that you'll need to go through to understand what you're getting into and determine what you need to address, while building trust and credibility with your stakeholders and management.  Next time you take on a new job, use this model as a framework to help you execute a practical 100-day plan to get you off to a good start.

Want the PowerPoint slides used in this article? Message me.

  So let's get right into this....

Ever known a manager who held great respect of his or her team but was not respected by his or her management?  Or maybe you've had a manager that just couldn't get things done effectively because he or she just didn't know how to "work the system"?  Or even still, are you are a manager who is continually frustrated because you can't get your manager to do what you need him or her to do?  If any of these sound familiar to you, welcome to the world of ineffective upward management. 

Upward management is one of those skills that some do very well, many never seem to master, and virtually all learn only through on-the-job lessons-learned.  When done well, both the manager and employee work as a team to ensure each other is informed, address problems before they spin out of control, and be more effective at managing.  When done poorly, both manager and employee are not only ineffective at getting the job done but are chronically frustrated due to missteps and surprises. 

Through the years I've come to categorize most poor upward managers into four personality types:

• The Brown-Noser - This is the employee who treats his boss as some kind of rock star and constantly searches for what his boss wants to hear.  Rather than upwardly managing, the brown-noser upwardly affirms whatever it is the boss is thinking.
   
• The Rebellious Teenager - This is the employee who consciously conceals information from her boss because she wants to demonstrate that she can get things done without help from her boss.  Rather than upwardly managing, the rebellious teenager keeps her manager in the dark by withholding information.
   
• The Cowardly Lion - This is the employee who simply is afraid to share information with his boss because he fears his boss' reactions.  Rather than upwardly managing, the cowardly lion avoids sharing information unless completely painted into a corner.
   
• The Erupting Volcano - This is the employee who subscribes to the "more is better" school of information management and will tell her manager every gory detail of every single event every single day.  Rather than upwardly managing, the erupting volcano spews data like hot lava and forces her manager to pick out the important facts.

So how do you avoid missteps in managing upward?  Give this baker's dozen a look and see if one or two of these nuggets can help you be a better upward manager:

• #1 - Understand your boss - Think about how your boss likes to communicate; does she prefer written emails or verbal discussion?  Does she like structured one-on-one meetings or informal chats?  Get a clear understanding of how your boss likes to engage and adapt your style to her style. 
   
• #2 - Stick to objective facts - When presenting information avoid emotionally-biased assessments.  Sure, you may have put your heart and soul into a project but if the project no longer makes business sense to do then it's your responsibility to put personal feelings aside and do the right business thing.
   
• #3 - Don't dump problems on his or her doorstep that you should be solving yourself - Yes, your manager has greater responsibility than you, probably gets paid more than you, and most likely has more organizational influence than you.  That doesn't mean you get to delegate things you should be solving yourself.  Handle the problems that you're paid to handle and enlist your boss for the stuff that requires his influence in the organization. 
   
• #4 - Be specific about what you need - Whether it be money, resources, or some other form of assistance, be very specific about what you need, why you need it, and what will happen if you don't get what you need.  Credible objectivity is crucial here:  if it looks as if you are "stacking the deck" by exaggerating consequences or embellishing benefits you're likely to not get what you need.  Also, subsequent asks are going to be viewed with greater skepticism. 
   
• #5 - Don't ever give reason for your boss to question your credibility - Simply put, if you get caught stretching the truth on even the smallest of facts, you've now given your boss reason to question not only the little things but also the big things.  You've got to stay pure with your boss and protect your integrity by never allowing your credibility to be put to question.
   
• #6 - Don't manage upward at the expense of managing downward - I've known one too many managers who did a great job of keeping his boss happy but had a team that wanted to string him up by his thumbs.  Look, at some point in time those that manage up at the expense of managing down will get found out and will have to pay the piper.  Don't play Russian roulette with your career by keeping your boss comfy while ticking off your team. 
   
• #7 - Respect your boss' time - Got a meeting with your boss?  Show up on time, come prepared to discuss whatever topics need discussing, and end the meeting on time.  Your boss is busy and her time should be utilized as effectively as possible.  Don't let your boss see your meetings with her as a waste of time.
   
• #8 - Diligently follow through on commitments - So your boss asks you to complete an assignment by tomorrow.  You agree to meet the commitment.  The deadline passes and you haven't met the commitment and all you can offer up is some lame excuse.  Sheesh.  Even if you think an assignment given to you is the dumbest assignment on earth, if you've made a commitment to do it then meet the commitment.  Not following through shows a lack of respect for your boss and breeds distrust. 
   
• #9 - Present options - In decision making managers like to see alternatives and the consequences associated with each alternative.  Some of the best decision making meetings I've been in with my bosses have been where we had meaningful dialogue around two or three viable options to resolving a tough problem.  My job in the process was to frame up the options, provide facts to support each option, and provide a recommendation.  Sometimes the recommendation was taken, sometimes not; the most important thing was that a good decision was made because there was good informed discussion.
   
• #10 - Make your boss look good - Let's say that your boss is due to make a presentation to his boss and is relying upon you to provide some critical information.  You give your boss the information he needs and he presents it to his boss.  He then gets fricasseed because the information is wrong.  Guess whose office he stops at first on his way back from getting barbecued?  Simply put, don't put your boss in a situation where he looks bad in front of his management; you've not only hurt your credibility, you've hurt his credibility.  
   
• #11 - Don't suck up - Telling your boss what she wants to hear can label you as a spineless know-nothing who doesn't have the intestinal fortitude to manage effectively on your own.   You'll not only quickly lose the respect of your team, your boss will ultimately see through you and not respect your leadership abilities.  Sure, you may get the occasional self-absorbed manager that craves shameless idolatry; but by and large bosses view sucking up as incompetence.

• #12 - No surprises - Ever tell your boss that your project is on schedule and on budget then at the last minute spring a huge schedule or budget slip on her?  Particularly early in my career I've had this happen more than once.  For it to happen more than once is shameful to say the least.  Bosses don't like surprises where they are forced to accept a problem without having the option to try to fix it before it got out of control.  When you see problems make sure you northwind your boss; just make sure you're working diligently to resolve the problem and not just to cover your @$$.  

• #13 - Admit mistakes...quickly - Look, screw-ups happen.  Heaven knows that I've got more screw-ups to my name than many managers will ever see.  The important thing is to own up to your mistakes quickly and outline what you are going to do to rectify the mistake.  Being the last one to recognize you've made a mistake just diminishes your credibility, so own up to those gaffes and get to work fixing them.  

A sad tale of a how a sponsor/PM relationship killed a project...

Exec identifies a need for a project and nominates self as sponsor.  PM gets assigned to project and assembles project team.  Sponsor is vague about problem to be solved other than "we need a new system".  PM can't communicate problem to be solved to the team because he doesn't understand what the problem is.  Sponsor continues to ask for more and more things to be included in project, PM doesn't have courage to say no.  PM treats sponsor as "that person in the corner office" and doesn't know how to ask for help, so he escalates everything.  Sponsor has to make some tough decisions but is unwilling to do so because of the political fallout.  PM provides bad information about decision alternatives so sponsor ignores him.  Due to changing priorities project no longer makes sense to do, but PM lobbies to keep the project going.  Sponsor loses interest because there are bigger fish to fry.  PM and team are disillusioned because sponsor doesn't care.  Project dies a slow death.  R.I.P.

While this is a fictional story, you can undoubtedly relate to most of these things happening on one project or another in your career.  The sponsor/PM partnership on a project is one of those "soft skill" factors that gets frequently overlooked when assessing a PM's skills but is a key determinant in the success or failure of a project.  Under a healthy partnership, the sponsor and PM work as a singular unit to ensure the project gets what it needs to be as successful as possible using only as many resources as absolutely necessary to secure success.  Under a less than healthy relationship the project will undoubtedly cost more in time and money assuming it even gets completed at all. 

Throughout my career I've been both a sponsor and a PM and have first-hand experience in how this relationship needs to work from both sides of the desk. Through my experience, I've locked down on ten truths which I feel are crucial to securing a healthy sponsor/PM partnership.  See if these resonate with you:

Truth #1: Great sponsors clearly articulate a root-cause problem to be solved. Great PM’s make sure the team knows (and remembers) what problem is being solved.   No surprise that great projects start with a great problem statement.  Where things go awry is when there's fuzziness about the problem statement between the sponsor and PM and when they aren't completely unified on the problem being addressed.  The sponsor needs to be clear about the problem, the PM needs to keep it at forefront and never allow the team to drift from solving the problem.

Truth #2: Great sponsors ensure the solution solves the root cause problem. Great PM’s don’t allow solutions to lose focus. It's so easy for a project team to get all lathered up in the coolness of a solution and the incremental value which can be had by just taking on a bit more scope here and there.  I love when project teams can kill two birds with one stone, but at the same time the sponsor and PM need to be very disciplined about keeping the project team focused on solving the root cause problem and not allowing scope to explode due to emotional frenzying. 

Truth #3: Great sponsors enforce a “good enough” mindset. Great PM’s don’t use “good enough” as an excuse to cut scope. Using a "good enough" mindset means being very conscious of not gold-plating a solution and putting incremental work into a feature that doesn't yield incremental benefit.  PM's, project teams, and sponsors alike fall subject to gold-plating to increase coolness or solve out-of-scope problems.  The sponsor needs to continually remind the team to not gold-plate and to do what's required to solve the problem.  At the same time, the PM can't use good enough as license to trim scope to solve a budget or schedule problem.  Certainly budget and schedule problems will happen, but the PM can't hide behind good enough and unilaterally trim scope based on his or her convenient definition of what good enough means.

Truth #4: Great sponsors ensure the project has the right resources to get the work done. Great PM’s articulate clear resource requests and “right size” the ask to the need.  No news flash here; projects need people and money to get things done.  Where things go awry is when project needs are poorly articulated, lack credibility, or are flat-out ignored.  This is one of the most important areas of an effective sponsor/PM partnership.  The PM needs to be crystal clear about what resources are needed to complete the project, thoughtful about alternatives to fulfilling the need, and objective about the consequences of not filling the need.  The sponsor needs to be convinced of the resource need, then needs to either support the PM to secure the resources or understand and accept the consequence of not securing the resources.  This truth is a massive failure point in projects with both the sponsor and PM being culpable.

Truth #5: Great sponsors hold the PM and team accountable for results. Great PM’s embrace the accountability and enforce it with the team.  Any leader worth his or her salt understands the concept of accountability.  Most sponsors joyfully embrace this role and effectively drive accountability across the team and with the PM.  The PM has a specific responsibility to embrace the accountability, demonstrate respect for the sponsor with the project team, and cascade the accountability throughout the project team.  Too often project managers will bad-mouth the sponsor to the project team and undermine his or her credibility as sponsor which creates ill-will between the sponsor and the team.  The sponsor needs to drive objective accountability and the PM needs to demonstrate respect and ensure all team members are held appropriately accountable for results.

Truth #6: Great sponsors are on top of the big issues and stand at the ready to help resolve them. Great PM’s articulate issues clearly and timely and escalate only those they can’t solve.  Too many times in my career I've seen a project sponsor be treated as if they were royalty.  The PM would make the trek up the mountain to report progress to the sponsor in hopes of pleasing him or her and getting a nod of approval from his or her highness.  Here's the reality:  the best sponsor/PM relationships are when both the sponsor and PM recognize the sponsor plays a specific role on the project and fills needs that he or she is best suited to fill.  The sponsor needs to be on top of the big issues which are appropriate for him or her to be addressing and be "at the ready" when the team needs an issue to be addressed.  At the same time, the PM needs to make sure that only those issues which are appropriate for the sponsor to address are being escalated.  Too often the PM will use issue escalation either as a means of "covering your butt" thus putting the sponsor on notice for an issue or will escalate inappropriate issues due to flat-out laziness.  The PM needs to escalate only those which cannot be solved at his or her level and ensure the sponsor is given as much time as reasonable to put the issue to bed.  The sponsor needs to be ready and willing to act. 

Truth #7: Great sponsors are an advocate, coach and battering ram for the project. Great PM’s know how to leverage a sponsor and listen to the sponsor’s counsel.  Some of the best sponsors I've worked with provide an open door to coach and counsel the PM.  The sponsor shows an active interest in the PM's success and deliberately works to help the PM grow as a professional.  They also serve as an ambassador for the project to other areas of the organization to ensure other stakeholders and constituents are supportive of the project.  Their interest is much more holistic and strategic; they want to help the organization be better and help the PM be better at his or her job.  At the same time, the best PM's see this relationship as an opportunity to grow personally and professionally and actively seek out and listen to a sponsor's coaching.

Truth #8: Great sponsors willingly make tough decisions even if unpopular or politically charged. Great PM’s provide clear and unbiased alternatives, information and consequences to support decision making.  On virtually every project there will be at least one decision which the sponsor has to make which will be unpopular with some organizational faction.  The PM has a clear responsibility to provide the sponsor with an objective point of view on decision alternatives, allow the sponsor as much time as reasonable to make the decision, and, while being politically aware of consequences, not be politically driven by consequences.  The sponsor needs to ensure alternatives are appropriately vetted, the facts and consequences are understood, and then make the decision as timely as reasonable.  The PM needs to be believable and objective, the sponsor needs to be courageous and timely.

Truth #9: Great sponsors don’t opportunistically increase scope if the project is going well. Great PM’s keep the team focused on delivery and don’t claim victory too soon.  In the 2006 Olympics, snowboarder Lindsey Jacobellis had the gold medal all but won. On the last jump of her race Lindsey does a hot dog move and trips at the finish line only to walk away with the silver medal.  Victory was in sight, cockiness crept in, then something bad happened to blow it.  Projects are no different.  The sponsor and PM need to jointly ensure that victory doesn't get claimed too soon, that scope control doesn't get sloppy, and that the team stays focused on driving the project to conclusion.  The sponsor needs to resist the desire to add "just a little feature" at the end and the PM needs to not allow the team to relax. 

Truth #10: Great sponsors continually evaluate priorities and are willing to pull the plug on a project if it no longer makes sense to do. Great PM’s don’t get emotionally tied to a project and don’t lobby to keep it alive if it should stop.  Sometimes a project no longer makes sense to do.  Whether it be about changing priorities, overly aggressive benefit statements, or under-estimated costs, both the sponsor and PM need to keep an ear to the railroad tracks and ensure the project still makes sense to continue.  If the sponsor has bigger fish to fry he or she needs to either continue to commit to the project or kill it.  The worst thing a sponsor can do is allow a project to die a slow death due to disinterest.  It not only wastes time and money but also creates disillusionment with the team because management isn't demonstrating support.  The PM needs to keep a "business first" attitude and recognize that sometimes a well-intentioned project no longer makes good business sense to continue.  Lobbying to keep a low-priority project going will just delay the inevitable.

The project sponsor/project manager relationship doesn't have to be contentious or stressful. When both are rowing in the same direction it can greatly reduce friction on on projects and make for more effective execution. Take the time to build the partnership.