Pipeline Publishing, Volume 5, Issue 7

	This Month's Issue:
	Product Lifecycle Management

How did that PM get to be in charge?

article page | 1 | 2 | 3 |

relying on IT provided not much advantage to the company.

The frustration in the business departments became so great that they started to ignore their IT groups and go it alone. As a result we have business managers that are no doubt completely qualified in their sphere making decisions on systems and who should manage their technical implementation. These are smart people, but with no experience in IT management or deployment. This can have just as unhappy results as the previous situation. In fact, this is exactly how the unfortunate PM mentioned earlier ended up in his current no-win situation.

So how should these folks select the "right" PM? Is there a better way? Here are some of my perspectives on this as a long-time project manager, program manager, decision-maker, and even, now and again, a client.

First, check the fundamentals, the candidate PM's skills, experience, qualifications etc. This should be an obvious step, but you may be surprised how often it is omitted. Now the candidates have been qualified against the basics how do you further minimize your project risk? Domain knowledge is a key consideration and preferably includes experience managing projects exactly like yours. Having successfully managed several similar projects is even better! Just because a person's job title is "PM" does not mean they are qualified to manage any type of project.

This is a problem, particularly in the IT industry. There is a view that all IT project managers are the same. Not true. I would describe myself as a software development and software package implementation PM. Please do not assign me an IT infrastructure project, like an IT network design and deployment project. Don't ask me to manage desktop setups and server deployments. Yes, these come under the umbrella of IT Projects, but they are not in my core skill set. Sure, I could quickly learn, but the project will

So how should these folks select the "right" PM? Is there a better way?

probably take longer, cost more, and will no doubt experience problems along the way as I work out the best way to do things. An IT Infrastructure PM would do a better job.

If I have an issue with my heart I will get a better result by seeing a cardiologist rather than a podiatrist. Both are doctors but... you get the point. Not all PM's are equal: look for experience relevant to your project, the closer the fit the better.

What if you don't have a PM that is a good fit or you want to develop and extend your current cadre of project managers? A PM has to get experience somewhere, so not every job can have an old hand. How do you manage the risk profile of that project that has been assigned to a relatively inexperienced manager? First, make sure the experience gap is not too big. "In at the deep end" works, but only sometimes, and some projects are too valuable to risk. But where the gap is crossable, the answer is skill mix. Take a team view and make sure the PM has selected strong resources to support him or her – and that those needed skilled resources are made available. The PM mentioned earlier in this article would have benefited from this approach. If he had the support of a few top caliber Business Analyst and Systems Analyst types who had delivered similar projects he could have leveraged their knowledge to build a solid plan. But that didn't happen. His Program Manager held the purse strings and wouldn't pay for the necessary skills. Ouch.

What if this project is entering unchartered territory? Optimism is a wonderful thing, but many people have been burned when they're the first to adopt new technology. Entering unknown territory requires realistic estimating and budgeting; over-optimistic budgets and timelines can doom projects before they start. Expectations have power: when you put forward a project proposal with a defined budget and timeframe, project sponsors expect them to be met. Assign a PM who can plan, plan, plan. One who can carefully scrutinize vendor and developer estimates, question everything and not accept unsubstantiated answers. Someone who checks the math several times, factors in risk and contingency and makes sure the sponsors understand the risk profile and potential impacts. Ensure he or she documents the risks and mitigates them. I have found that mitigation usually comes in the form of smart, experienced resources. Doing all this up front greatly improves the projects' prospects for success and can save you from those very uncomfortable "please explain" meetings.

article page | 1 | 2 | 3 |

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.