Project trouble can hit from a blind spot, even though you tried as much as possible to prepare for issues. You did a risk analysis when you took the project on, and even tried to be ready to mitigate unknown issues.
As I advised in my previous post, do an assessment to determine the problem. Figure out what needs to be fixed, or if the situation is even fixable. If the project seems to have reached a point of no return, here are some tips on how to pull it out of trouble:
Finally, keep in mind that not all trouble devours all. Before panicking, calmly look to areas that will guide you to a solution. You may even find your project is more sound than it seems.
How do you confront trouble on your project?
Good portfolio results depend on a collection of integrated projects that align with and support strategic objectives. Obviously, poor project performance will hurt a portfolio's goals. What is not so obvious is that troubled portfolios can cause projects to fail.
A troubled portfolio environment often results from an organization's misguided knowledge about portfolios. A bunch of projects thrown together doesn't make a portfolio. Through portfolio management, a portfolio should ideally consist of carefully selected, prioritized, monitored and controlled projects, and well-managed resources. If organizations don't have structured portfolios with guidelines and governance, they may, in fact, be creating projects doomed to fail. So the next time you face a troubled project, first assess if the portfolio is the problem.
A good sign that you have a troubled portfolio is when you are facing troubled projects repeatedly. If more than 30 percent of your projects are troubled or challenged, you probably have a troubled portfolio. Other signs of a troubled portfolio include:
However, it's not enough to identify a troubled portfolio. You have to know how to fix it. Do you have a troubled portfolio because the projects are troubled, resulting in poor portfolio performance? Or do you have troubled projects because the portfolio is not well-structured, giving birth to projects troubled from the start?
It would take many posts, maybe even a book, to discuss and analyze the answers to the questions above. However, here are some straightforward first steps for fixing a troubled portfolio.
An executive should:
A portfolio manager should:
To what extent do you think bad portfolio management can doom projects to fail? What first steps do you take when conducting portfolio recovery?
|Elements of the project are falling apart, whether with the team, with the supplier or in your project management domain. Now is the time to regroup, reengage and reset everyone back in the direction of the project goal -- before it's too late. |
To regroup, conduct a structured session with the core project team to capture the status of everyone's tasks. The regroup can be in the form of a meeting, brainstorming session or workshop. This way, no one on the team is invalidated for elements that went wrong, and you can show your appreciation for everyone's input. Allow for a discussion of their concerns.
To reengage, work with the team to align with the original goal, requirements and project deliverables.
Then, reset the expectations of each team member, as well as your responsibilities as the project manager. Finally, implement any changes required for the successful delivery of the project.
Separate failure to perform from a lack of teamwork within the group. This action allows you to focus on how to achieve the expected results of the project, with buy-in from the entire team.
What do you when your projects are off track?
|It's impossible to accurately predict the future. Yet, many project managers continue to try. They create schedules that implicitly state a task will be completed at 3:30 on a Tuesday afternoon, in four months. Or they predict that the total cost of their project will be precisely $10,986,547.55. |
Yet these pseudo-accurate estimates based on detailed calculations are no more accurate than estimates made in more general terms and covered with an appropriate range indicator. Achieving a detailed estimate for an $11 million-plus project to within -5 percent to +10 percent indicates a very careful estimating process in a stable, well-understood environment.
Attaching a precise number calculated to the nearest cent only raises stakeholder expectations about the degree of accuracy possible. And that leads to perceived "failure" when the stakeholder's unrealistic expectations are not realized.
Similar problems arise if a project is scheduled in hours, and the work extends for more than a few days. Planning a project over several months on an hourly basis produces a mass of inaccurate data once you get beyond the first few days. And again, when the project fails to achieve the degree of control over the future implied by the excessively detailed schedule, it will seem like it failed.
Pragmatic estimating at an appropriate level of detail sets realistic expectations. But beware: Your stakeholders may already have unrealistic expectations of what is possible from previous projects that "failed."
Dealing with this issue requires skills in managing upward -- a topic for a future post.
|What would be your reaction if I told you there's a widely practiced profession out there that pays well, with (usually) nice working conditions, and it involves continuously providing its customers with the wrong answers? |
Welcome to the wonderful world of cost estimating.
Take for instance, the original estimate for the National Ignition Facility project--it was just over US$1 billion. The final budget was US$4.2 billion. The Central Artery/Tunnel Project, also known as the "Big Dig," was originally estimated at US$2.8 billion. Through 2006, US$14.6 billion had been spent (though to be fair, this is only US$8 billion in inflation-adjusted dollars).
The original estimate for the Sydney Opera House was US$7 million. The final cost was US$102 million, more than 14 times the original estimate.
Why is estimating so tough? It's not as if estimators are dumb or poorly trained in their profession. I've earned my estimating certification, and that was one hard test--it melted my brain. I took the examination on a Friday and couldn't participate in light conversation for the following weekend.
The reason that initial cost estimates seem to so rarely align with a project's final costs has nothing to do with the work quality of the estimators. It has to do with the work quality of everybody else on the project team. You see, comparing the final costs of a project to their original estimates is a way of making the cost baseline team somehow responsible for everything that went wrong in a project.
In the case of the Sydney Opera House, bad weather, incomplete plans and drawings, and a lack of information about the material and the structure of its now-famous roof all added dramatically to the cost. The estimators didn't make those errors--other members of the project team did.
I have to laugh every time I hear a project manager lament all that's really needed is a good cost estimate--as if a sufficiently prescient estimate would work as a talisman to ward off rate variances, contingency events, poor performance and scope creep.
For those estimators who are reading this and can't believe your eyes, I figured I've spent enough ink lambasting you for hanging around projects and continually re-estimating the remaining costs as a way of providing project control capability. You deserve a break.
I'm especially interested in hearing from those estimators and project controllers who somehow find themselves the scapegoat when their original cost baseline gets blown to smithereens.