Voices on Project Management

> Back to Voices Home

More posts in Project Failure

Getting Out of Trouble

| | Comments (3)
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:

  1. 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.
  2. 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. 
  3. 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. 
  4. 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. 
  5. 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. 

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?

Troubled Portfolio, Troubled Projects

| | Comments (1)
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:

  • 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)
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:

  • Define accountability and ownership of the portfolio
  • Provide visibility and transparency of the portfolio's performance
A portfolio manager should:

  • 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 what extent do you think bad portfolio management can doom projects to fail? What first steps do you take when conducting portfolio recovery?

Project Off Track? Regroup, Reengage, Reset

| | Comments (8) | TrackBacks (0)
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?

Unrealistic Detail Only Sets You Up for Failure

| | Comments (3) | TrackBacks (0)
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.

PMBOK® Guide for the Trenches, Part 3: Cost

| | Comments (6) | TrackBacks (0)
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. 

Scrutinizing Project Conventions

| | Comments (2) | TrackBacks (0)
Within the realm of project management--or any other complex system, for that matter--accurately identifying failure is difficult to the extreme. There are simply too many parameters to isolate, which makes writing about management a precarious proposition.  

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

Your Problem Isn't ...

| | Comments (12) | TrackBacks (0)
Project management practitioners who read the conventional wisdom on those things that threaten project success may be "getting sold a bill of goods" (a U.S. colloquialism meaning to be deceived).
    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.

Beware the Implementation Trolls

| | Comments (1) | TrackBacks (0)
Those project managers who have accepted the quest of advancing project management capability within your organization need to be aware of a very real threat on their path. Implementation Trolls are skulking all about you, ready to bring you down.
    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.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll