Conference Highlight: CSI: Project Management
Training 2012 Conference & Expo speaker Lou Russell outlines the top six reasons she has seen project management suffer.
Projects fail all the time, in fact many more projects fail than succeed. In IT studies in the 1980s by Capers Jones of the Stanford Group, projects failed 80% of the time. The Cutter Consortium in the late 1990s found that project success has improved a bit, but the chance of your project failing is still pretty high. Sure, there is weirdness in the discussion of projects failing. First, what is a project? Many people work on projects and don’t even know it. Next, what does failing mean? Does it mean late, over budget, poor quality, or does it ‘just depend’? Leaving this discussion for a later article, there are certain things that I see in my project management consulting work that fuel failure. Do these teams know that they are struggling? Absolutely. Do they know what to do about it? No. You’re probably on one right now. Here’s my personal autopsy on projects that I’ve watched die:
1. Meetings with too many voices. Much of our research with companies shows that good, effective project meetings can improve a project more than anything else. However, bad, ineffective project meetings can kill a project quicker than almost anything else. One of the most common mistakes is inviting too many people to too many meetings. When a project is challenging, you are a lot better off going ‘guerilla’ – get the people who can make the decisions in a room quickly, and go. Building consensus is a great thing, but not when something is on fire.
2. Building overtime into the plan. It is weird what I see in original project plans. These are the plans created BEFORE the project starts. This is the nirvana plan, the way you plan for it to go. Everyone knows that the project never really goes this way, and more likely or not, it is overly optimistic. Even so, I see so many plans built with overtime in them. Overtime should be a disaster strategy, not a planned strategy. Burnout is not a good thing, and shouldn’t be built into a plan. I’ve also seen bizarre timelines, for example, it is not at all unusual for the Help documentation for software to be due a month after the first products ship. Ouch.
3. Letting technical people use MS Project. Bad idea. Let technical people do what they are supposed to do – write code, build networks, create test scripts, etc. They have plenty to do. Hire someone who is an expert at project tracking and have them be the librarian for MS Project, or whatever tool you are using. Giving technical people new software to play with is like giving little kids a bunch of new colored markers in a bare room with white walls that you’d like to keep white.
4. No configuration management plan There are many methodologies to plan the development of something, like software or other products. The big lie is that development is a linear process. When you build, something surprising always goes wrong. Fixing that something, and updating all the people who are depending on your deliverable, requires handling complex communication. Teams don’t build plans for this communication until things get hysterical. Spend MORE time on your configuration management than on your original development plan, and build it early.
5. The wrong person as SME and/or no Executive Sponsor Same problem, different amounts of time before the project spins off into death. The Executive Sponsor is the single person funding the project, owning the business need and making decisions about scope. If there is an unclear sponsor, eventually the rug will be pulled out from under the project. If the SME (Subject Matter Expert) assigned to the project does not have the authority or expertise to help define requirements, you are also doomed, although it will take longer and the pain will be drawn out. Neither of these can ever work.
6. More than one Project Manager I do not believe in multiple project managers. I suppose there are projects that have been successful at the end with two project managers, but it’s uncommon. Think about it – how many pilots do you want flying the plane at the exact same time? How many Presidents of the United States do we want? How many Army Captains leading an infantry team through Iraq streets? Of course, backups are a good idea (like co-pilots) but only one person should be driving.
In summary, be creative and be real. A large corporation showed an impressive Project War Room, with detailed large, colorful charts of all the projects they were working on. It appeared they were completely in control of their project investments. Later, the leader of the (PMO) Project Management Office confessed “Oh, those charts are all fakes. We have that room to keep people off our backs so we can get the projects done.” You know what you have to do.
Bring a real project to Lou’s Training 2012 Conference & Expo workshop and leave with:
A complete Project Charter
A start at a realistic Project Plan that works backwards from the date just like you do
A changed view of project management – There is NO SUCH THING as control.
About Lou Russell
Lou Russell is a dynamic, entertaining speaker and a topic expert and author in the fields of training and performance, project management and leadership. Her humor and positive outlook come through in every presentation she makes, and even the most gnarly topics will bring you a giggle. Whether it is giving a keynote address for hundreds or facilitating a workshop for small groups, Lou’s insights spark a memorable creative chord. She can turn any setting into an interesting learning experience with immediate impact. No one leaves her session without new ideas. Invest your time with Lou and leave with (1) concrete tools and techniques to apply immediately to your biggest challenges, and (2) a new friend. You can connect with Lou on her business site, www.russellmartin.com, her blog, insanityconstraint.blogspot.com, or on Twitter at @nolecture.