- Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
- Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them.
- Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase.
- Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need.
- Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources.
More posts in Project Failure
- Lack or no support by senior management
- Unclear strategic goals
- Lack of objective selection and prioritization criteria
- Poor guidelines and structure
- Lack of standardized project and portfolio management processes
- Resource allocation issues
- Poor key performance indicators (KPIs)
- Define accountability and ownership of the portfolio
- Provide visibility and transparency of the portfolio's performance
- Obtain senior management approval and support for project portfolio management
- Define processes and guidelines for portfolio management, including steps to approve project investments
- Clearly outline measurements and KPIs for portfolio monitoring and controlling
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?
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.
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.
Oh, there are certainly those cases where a project manager insists that no cost or schedule management systems be used, and it doesn't take long to drive that project into the ground. But in most other areas the link between act and consequence is not nearly so stark.
Renowned psychologist, B.F. Skinner, wrote that a variable rate of reinforcement virtually guarantees a behavior will continue. If that is so--and I believe it to be--then it follows that a practitioner who has experienced success using a particular technical approach may be inclined employ that approach over and over--even when it fails over half the time. That same practitioner might also be inclined to join with like-minded project managers to advance a new model or structure for success.
Their assertions may be correct and insightful universally, in some specific environs, or completely off base.
I entitled this post "Part 1" because I intend to take a close look at some conventions that may have been adapted in that spirit and without the scrutiny of an iconoclastic wise guy such as me.
Next up: Does risk management really help bring in projects faster, cheaper or with higher quality?
See relevant research from Project Management Journal® as reported in PMI Community Post: Avoiding Project Failure by Managing Organizational Culture
While project management-types usually don't stay in the industry for long before witnessing a project crash-and-burn firsthand, the ability to accurately identify and clearly articulate the proximate cause of that project failure is often elusive, with individual prejudices coloring analysis. Quality engineers tend to name a lack of quality capability as the main reason behind project failure, while estimators tend to believe inaccurate cost baselines or estimates at completion are the culprits.
I have a pretty clear idea of the main, if not only, cause of project failure, but before I name it, let me tell you what it isn't:
• No Six Sigma
• Lack of Agile project management
• Failure to engage stakeholders (see my previous post)
• Inappropriate leadership style
• Too few Project Management Professional (PMP®) credential holders
• Insufficient procedures or written guidance
I could go on, but this list should be sufficient to contradict the majority of management writers who are asserting the key causal factor in project failure.
So, what is the main causal factor? The project manager and/or project team made bad decisions.
This is not simply a semantic difference. The ability to make good decisions is absolutely critical to any and all project outcomes, including the ability to meet success criterion. This ability is influenced by several factors, including:
• The education/capability of the project team
• Some level of luck, certainly, but mostly:
• The availability of adequate project cost and schedule performance information, which almost always clarifies the best project decisions
So important is the generation and delivery of cost and schedule performance information that any manager who eschews such information has automatically signaled their incompetence, and inappropriate placement in any position of authority.
I'm essentially calling out the anti-cost/schedule performance system crowd. (You know who you are.) If you have ever argued against the introduction of an earned value system on principle, stop calling yourself a project manager because you aren't one. Of course, I'd love to hear from anyone disagreeing with me on this, so, please leave a comment.
For example, one favorite troll tactic is to lurk beneath a bridge and attempt to eat unwary travelers who attempt to cross. If we take the action of walking across a bridge as a metaphor for initiating any change, then the Implementation Trolls destroy you in transit, usually by ginning up to the organization's nominal resistance to change. While it is beyond debate that the amount of time and energy that goes into setting up a very simple earned value management system (EVMS) pays huge dividends in useful management information, the Implementation Trolls will complain long and loud about how even that small amount of effort is overly arduous. These beings complain so excessively about largely contrived grievances they should be made honorary members of the Trial Lawyers Association.
Then, once you've crossed the bridge and approached the castle that serves as the keep for your sought-after treasure, an advanced project management information system, you will encounter an entirely different breed of Implementation Troll.
Far from picking off your comrades for making people do stuff that's supposedly way to hard, these trolls will insist that anything you bring them is not good enough. These Implementation Trolls are invariably armed with clubs that have the infamous 32 EVMS criteria etched into them, and they take great pleasure in pummeling all those who approach. The infuriating thing about these trolls is that they will often present themselves as erstwhile allies to your cause, but will then gleefully destroy your efforts as being sub-standard. Like their notorious counterparts from Norse mythology, Implementation Trolls have what can only be described as bizarre senses of proportion and perspective, and will inflict their damage while pretending to occupy the intellectual high ground.
I'm very interested in finding out what the project management blogosphere thinks about Implementation Trolls.