Difference between revisions of "Project Management Execution"
(Created page with "The project manager has to stay steady at the helm making sure these things happen; they won't just happen by themselves. To articulate this a bit more here are three formulas...") |
|||
Line 7: | Line 7: | ||
== Snuff out and squash "shiny objects" == | == Snuff out and squash "shiny objects" == | ||
First, let's put shiny objects in context; to me a shiny object isn’t important to the task at hand and isn’t time-sensitive. If something comes across your desk that can be done later without impact to your work, yet interrupts what you’re doing, then this in my view constitutes a shiny object. It’s also important to distinguish between shiny objects and the garden-variety fire drill. The primary difference to me is a fire drill needs to be done immediately; otherwise there is some material and tangible business consequence; whereas with a shiny object there is no material and tangible business consequence if it doesn’t get done. This is an important distinguishing factor because many shiny object violators I know view their shiny objects as fire drills and take comfort in responding to fire drills because of the sense of accomplishment they feel in putting out the fire. Be on the lookout for shiny objects and squash them before your team gets derailed. | |||
== Watch the "off-workplan" tasks == | == Watch the "off-workplan" tasks == | ||
Recently I worked with a project team that had a pretty decent project plan with dependencies, resources, and timeframes all laid out. The problem, though, was that the project plan assumed 100% resource focus but only about 60% of the resource focus was dedicated to the project plan. The other 40% was consumed via to-do lists, which the project manager kept in addition to the project plan. Thus, the project was doomed to a 40% schedule slip right from the get-go because of the to-do list tasks. As the project manager, you have the responsibility of ensuring that all project-related activity is reflected in your project plan and that you specifically articulate the percentage of time resources are dedicated to tasks. | |||
==realistic estimates== | ==realistic estimates== | ||
Line 15: | Line 15: | ||
== Hold weekly status meetings == | == Hold weekly status meetings == | ||
I am a big fan of weekly status meetings and weekly status reports, particularly on high-visibility projects. In fact, I have become a strong proponent of creating my project status report (see my status report template at the bottom of this article) right in my status meeting. Key to this is focusing on project plan tasks, milestones, risks and issues during the status meeting. I've been through way too many status meetings where the focus was on each team member talking about accomplishments and effort versus results. Now, it's nice that all of the team members are working so hard, but when everyone starts patting themselves on the back for how many hours are being worked at the expense of managing to schedule, you've got a sick project on your hands. Keep the status meetings focused on schedule, risks and issues and keep them very regular. Don't let weeks go by without doing them unless you're willing to play Russian Roulette with your schedule. | |||
== Expose the violators == | == Expose the violators == |
Revision as of 14:42, 24 April 2014
The project manager has to stay steady at the helm making sure these things happen; they won't just happen by themselves. To articulate this a bit more here are three formulas for you to keep in mind:
- Planning + Execution = Project Success
- Execution - Planning = Randomized Flailing
- Planning - Execution = Well-Dressed Inertia
Through my experience I've come up with six techniques that can help you as a project manager better ensure project success. While this isn't an exhaustive list of everything you can do, it does highlight some specific areas, which can help keep a project from derailing:
Snuff out and squash "shiny objects"
First, let's put shiny objects in context; to me a shiny object isn’t important to the task at hand and isn’t time-sensitive. If something comes across your desk that can be done later without impact to your work, yet interrupts what you’re doing, then this in my view constitutes a shiny object. It’s also important to distinguish between shiny objects and the garden-variety fire drill. The primary difference to me is a fire drill needs to be done immediately; otherwise there is some material and tangible business consequence; whereas with a shiny object there is no material and tangible business consequence if it doesn’t get done. This is an important distinguishing factor because many shiny object violators I know view their shiny objects as fire drills and take comfort in responding to fire drills because of the sense of accomplishment they feel in putting out the fire. Be on the lookout for shiny objects and squash them before your team gets derailed.
Watch the "off-workplan" tasks
Recently I worked with a project team that had a pretty decent project plan with dependencies, resources, and timeframes all laid out. The problem, though, was that the project plan assumed 100% resource focus but only about 60% of the resource focus was dedicated to the project plan. The other 40% was consumed via to-do lists, which the project manager kept in addition to the project plan. Thus, the project was doomed to a 40% schedule slip right from the get-go because of the to-do list tasks. As the project manager, you have the responsibility of ensuring that all project-related activity is reflected in your project plan and that you specifically articulate the percentage of time resources are dedicated to tasks.
realistic estimates
Think realistically aggressive when developing estimates - I've worked with three distinct personality types when it comes to estimating levels of effort. The first personality type is Ms. Reality. She looks at a given set of tasks and develops a realistic yet aggressive expectation of what will be required of her to complete the task. More importantly, she hits her dates with a high degree of reliability. The second personality type is Mr. Op T. Mystic. Mr. Op consistently under-estimates tasks and provides a "if all of the stars align" projection on completing tasks. Tasks quickly get to 90% done then stay there forever. The third personality type is Mr. Gloom N. Doom. Mr. Gloom typically provides worst-case estimates and will slather on contingency like barbecue sauce on ribs. The secret sauce (can you tell I really like ribs?) here is to recognize the personality type you work with and try to snuff out reality with each personality type. Sure, you'll get some push-back particularly from Mr. Gloom, but unless you apply some aggressive reality to your estimates you're going to have a hard time getting sponsors and higher-ups to view you as a credible project manager.
Hold weekly status meetings
I am a big fan of weekly status meetings and weekly status reports, particularly on high-visibility projects. In fact, I have become a strong proponent of creating my project status report (see my status report template at the bottom of this article) right in my status meeting. Key to this is focusing on project plan tasks, milestones, risks and issues during the status meeting. I've been through way too many status meetings where the focus was on each team member talking about accomplishments and effort versus results. Now, it's nice that all of the team members are working so hard, but when everyone starts patting themselves on the back for how many hours are being worked at the expense of managing to schedule, you've got a sick project on your hands. Keep the status meetings focused on schedule, risks and issues and keep them very regular. Don't let weeks go by without doing them unless you're willing to play Russian Roulette with your schedule.
Expose the violators
So okay, before I have every HR manager ready to shoot me let me explain what I mean. In status meetings, I think it is completely within bounds for a project manager to expect project team members who don't deliver on their commitments to explain to the project team why they aren't pulling their weight. Too many times I've seen project managers shield slacker project team members or not force them to explain their actions (or inaction as the case may be). What each member of the project team needs to recognize is when he or she doesn't perform it isn't just the project manager that is being let down; it is the entire team. When each project team member feels accountable to the rest of the team for delivery and directly feels as if he or she is letting the rest of the team down he or she is more likely to perform and meet dates. This can be very effective in getting teams to perform, just make sure it is done with respect. It's about getting teams to perform, not about skewering someone's dignity.
Use the 1/1/1 rule when planning tasks
Great execution starts with great planning. Sure, we've all seen acts of heroism where a project team worked 90 hours a week to get a poorly conceived and planned project done on time. However, no one likes to work in that mode. Projects that are well planned are more likely to be delivered on time, per customer expectation, and within budget, period. A key component of good planning is using what I call the "1/1/1" rule in work breakdown structure decomposition, which stands for "one deliverable, one person, one week." Driving to this level of detail in a project plan ensures there is no ambiguity on who is responsible for the task and what the deliverable associated with the task needs to be. Also, by using a one-week duration you better ensure the task will be completed within one weekly status reporting cycle. Most importantly, you'll minimize surprises of a "90% complete" taking forever for the last 10% to be complete.
Summary
Excellent planning coupled with strong execution is crucial to ensuring the success of any project. Subtract planning or execution from a project, and you either get the randomized flailing of a project out of control, or the well-dressed inertia of a good-looking project going nowhere.