Stop the project plan crash. You are the expert.

Imagine the scene.  It’s 22:30, and an aircraft is preparing to take off for a long haul flight. In the cockpit, the captain and first officer are busy carrying out their final pre-flight checks.  They check the weather, the fuel levels and a whole range of technical dials and indicators.  They start to map out a detailed flight plan.

All of a sudden, the CEO of the airline bursts in through the cockpit door.

“What the hell are you guys doing?  I want this aircraft in the air ASAP.”

Model plane

You wouldn’t overrule a professional pilot… So why overrule a business change professional?

The pilot looks aghast:  “But sir, without sufficient checks and up-front analysis…”

“I don’t care for checks and analysis. I want to see action”, the CEO interjects. “Yes, I know analysis is considered ‘best practice’, but we’re in a hurry and don’t have time for all that ‘textbook’ stuff you guys insist upon. I want to see PROGRESS.  NOW.”

The pilot and first officer shrink into their seats.  “But we haven’t even planned our flight route.”

The CEO isn’t listening. “And why do you need so much fuel? I’m taking away half your fuel budget.  And I’ll expect to see the aircraft landed at London Heathrow in precisely 4 hours, not the 7 hours you’ve scheduled in your flight plan.  Do I make myself clear?”

The CEO storms out of the aircraft, back out onto the runway.

The pilot and co-pilot look at each other, knowing they’re departing with insufficient time, insufficient fuel, on an unknown flight-plan and without carrying out their normal safety checks.  It’s a disaster waiting to happen.

You wouldn’t overrule a professional pilot… So why overrule a business change professional?

The scenario I’ve painted above just wouldn’t happen in real life.  There is no way that a CEO would question the expertise of a pilot, and they certainly wouldn’t take away their fuel or half their flight time.  However, do you recognise any similarities between the challenges made to the pilot, and those challenges that are faced on projects?  I would hazard a guess that everyone reading this article has been asked by a sponsor or senior stakeholder to reduce an estimate to make it ‘fit’ a project plan, or start a project without carrying out sufficient up-front analysis.

As Business Analysts, we advise organizations in our capacity as experts in change.  We should expect healthy challenge from our project and business colleagues, but we shouldn’t be afraid to challenge them back.  It’s imperative that we act as a “critical friend” to the organizations in which we work – supporting them, but also being brave enough to ask the difficult questions and expose the cold hard facts.  When it comes to change projects, we’re firmly on the flight-deck.  If a red light is flashing, it is our obligation to escalate it.  We should do everything within our influence to stop a project plane crash by pointing out the risks and enabling informed decision making to take place.

So what are the warning signs?

  • No flight path:  If a project is lacking direction, there’s a severe danger it won’t land where the sponsor expects.  It’s worth pausing to understand why the project has been initiated and what goals and objectives it needs to achieve.
  • Insufficient fuel:  If there isn’t sufficient resource, a project is likely to crash and burn.  This needs a clear and honest conversation: If the project isn’t important enough to resource properly, perhaps it isn’t important enough to progress at all.
  • Unrealistic flight-time:  Encourage the project team to be realistic about delivery timescales. If there isn’t enough time to “land the project” then you might end up having to land abruptly, perhaps jettisoning some desired functionality along the way. Better to know this sooner rather than later, as it might change your approach.
  • Lack of contact with air-traffic control:  A plane needs help navigating the congested skies.  Organizations need to make decisions over competing projects within congested portfolios.  Our equivalent to air-traffic control is the project sponsor.  He or she should provide oversight, take accountability and be available.  If they are absent, this is a severe warning sign!

 

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

Comments

  1. Thanks Adrian – this analogy will be useful in some of those hard discussions. I like the “critical friend” designation – instead of beating ourselves up about always being the voice of doom, the one who punctures everyone’s balloons with facts.

    • Hi Karen, thanks for the comment, and I’m glad you enjoyed the article!

      I completely agree, as BAs we add objectivity and help people to see the “cold hard facts”. The important thing is that it’s done with rapport… we don’t have any hidden agendas. By acting as an objective critical friend, we can help ensure that decisions are made on an *informed* basis.

      Thanks again for your comment 🙂

  2. Thanks Adrian, nice post. No flight path, Insufficient fuel, Unrealistic flight-time, and Lack of contact with air-traffic control map to scope, cost, time constraints and sponsor involvement. These are certainly major causes for failure. One thing that can help management to understand is the statistics on project failures and the relationship between those failures and the quality of requirements.

    • Hi Jonathan, thanks for the reply and I’m glad you enjoyed the article.

      I completely agree, but have one observation to add.

      I’ve found it useful to quote specific examples of high-profile external project failures, as well as statistics. I agree that statistics are useful to illustrate the problem, but I’m increasingly finding a mixture of statistics (logic) with examples (emotion) help to get the point across.

      A useful example is the Ariane 5 rocket launch failure. There’s youtube footage of it exploding on take-off (thankfully, it was unmanned). The reasons are allegedly down to software specification: “The Ariane 5 software reused the specifications from the Ariane 4, but the Ariane 5’s flight path was considerably different and beyond the range for which the reused computer program had been designed.”

      (From http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29 )
      Showing a video of an exploding rocket seems to grab attention, and then this can be followed up and reinforced with the statistics.

  3. Michelle Swoboda says:

    Adrian, I love this article! Excellent analogy. What I do is highlight the impact of implementing before we are ready. When you sit down and discuss the risks – they will often realize that their decision was based on incorrect data and they will wait for the project to progress within its timelines.

    • Michelle, thanks for the comment.

      That is a great approach. Highlighting the risks and impact, and letting the sponsor make the decision on an informed basis. It’s also a really transparent approach — putting the facts on the table, and moving forward with agreement. Great approach!

  4. Alan Campbell says:

    Good analogy, Adrian. I see this situation all the time. In the minds of some people, if a consultant is not “doing” something (solution implementation), then they are not being productive. Yes, you might make it from point A to point B without proper flight planning, but why take the risk? Thanks.

    • Hi Alan,

      That’s a great point. A colleague of mine used to call this phenomenon the “illusion of progress”. There is a view that as long as people are *doing* that we’re moving forward…. however we might actually be moving in the wrong direction and taking time to reflect might be better!

      Adrian.

  5. Nice post, nice comparison/analogy, though we all must have come across such a problem in a way or other, and it always goes to the last call, which management has to take, and if you are not good enough to influence/convince them, then I would say, you have to fly the plane with the available resource on hand, though not optimal and result oriented but still to safe your job, you have to proceed with the given details. What I would like to hear from others around here, is how to tackle this situation and most importantly how to convince your senior or management, when you know what is right and wrong. Hope you comprehend what I mean, so we can take the step forward.
    Regards – Rahman

    • Hi Rahman,

      I do completely understand you. I think Michelle’s post above goes some way to answering your question, but I would add a few further observations.

      If you really are being pushed to proceed with a project without enough resource/time etc, then it can be really powerful to :

      1. Explain the risks and impact (as per Michelle’s post above)
      2. Describe what *can* be achieved (e.g. “We can’t implement the 100% gold standard, is 80% silver standard OK, followed by a second implementation x weeks later)?
      3. Examine scope and requirement priority (e.g. “Requirement xyz represents 50% of our effort, could you live with a workaround?)

      It’s all about dialogue. If the desired timeline is not achievable, then it’s about understanding what pragmatic compromises are available.

      Thanks again for your comment,
      Adrian.

  6. I really enjoyed this article, Adrian. I think it’s a great way of breaking down a real problem we tend to deal with in terms that people who don’t deal regularly in projects can appreciate. I’ll definitely be passing this along to my team!

  7. Hi Adrian, I do appreciate you to come up with such a nice analogy. To answer Rahman query on how to handle the such a project with some inadequate requirements, Within the present market situation it is always advisable to alert the project sponsor and stakeholders with the risks, severity of the impact ufront. Otherwise you will kept in a loop and may be blamed for the failure. Beware of the stakeholders who always look and try to take their blame or push on somebody else. Most of the stakeholders always try to impose their views onto the project before try to listen and identifying what is the problem. You need to be very smart and act as a “CRITICAL FRIEND” as Adrian mentioned. Stakeholder analysis is a key for every “Business Analyst” and bringing them to agreement on requirements is a challenge. This is one of the biggest constraint on any project. To save yourself (Job-according to Rahman post), Highlight all kinds of Risks, Issues and Constraints upfront and leave the decision to their panel instead of facing a failure. Thanks and all the best.

  8. Akarsh MG says:

    Great Analogy!!
    Adrian, I love this article!