3 October 2008


Let’s say you are efficient and skilled.  Let’s also say it takes you 6 weeks to collect and lock down your project requirements. What do you do if you only have 3 weeks?  And on top of that you are new to the organisation and need a week to get settled in and learn who is who and what is what.

What do you do?

Your sponsor wants the new product launched, and wisely they are not pushing you to go live before you are ready.  Your sponsor is lo wisely not pressing for the Rolls Royce edition of the product.  They just want a basic serviceable product that they can put in their next quarter’s advertising and promotion plan.

But one of your stakeholders has put up a mandatory requirement that forces you to build the Rolls Royce solution.  And it’s not just some minor player in the business politics.  It’s the information security people who present a report each month showing how much data theft is going on and how much money is quietly being stolen.

What do you do?

Photo by LunaDiRimmel @ flickr


  1. Craig,

    I remember a cartoon that used to hang on my wall. It is by Randy Glasbergen. On it you you see a man handing a project charter to a woman. The caption says: "Here is a project for you. It has no budget, no project team and it is due tomorrow. But finally, there is your chance to REALLY impress everyone."

    The situation that you describe in your question reminded me of this cartoon because both show an impossible situation. There is no way that you can win: Deliver the basic product and your stakeholder will be annoyed; deliver the Rolls Royce and you will not launch on time.

    I could recommend two possible ways to approach this:

    1.) Do what your sponsor says because that is where the money comes from. Tell your stakeholders that they will first receive a basic product, which will be upgraded later.

    2.) My preferred approach: Put everything that you know about schedule, scope, budget etc. down on paper. Work out a few options. Now invite the sponsor and stakeholders to a meeting and lead them to a consensus. After all, you are between a rock (sponsor) and a hard place (stakeholder) and one of them will lose if you don't bring them to the table and bring this awful situation to a resolution.

    Impossible situations like this SCREAM for a resolution that requires to have everyone affected help find a way out.

    Until next Time,
    Cornelius Fichtner, PMP
    The Project Management Podcast

  2. It reminds me of the story with the PM who takes up the job after hic predecessor has be fired, and has left him three letters "in case of emergency", the first one instructing the new guy to put the blame on the one who left.

    This would be tempting in case you are faced with stakeholders who won't negotiate anything. In any other case, negotiation with all stakeholders would be the preferred solution, as Cornelius rightfully puts it.

    Patrick Prodhon

  3. In my opinion, this is the perfect place for an Agile approach. First, you definitely have to get the stakeholders together, but in addition to that you need to prioritize features and get them to agree on it.

    At least you need your sponsor to back you up on the features and what order they will be built in.

    Since the one stakeholder requires the Rolls Royce, you will eventually need to get there. The key is the incremental releases to meet the sponsor need with the understanding of the security need being met.

    Otherwise, there is no way to meet this requirement. Your stakeholder and sponsor need to be responsible and adult and work with you on the problem.

  4. Craig,
    Here's what we do in domains where this is common practice.
    Build a requirement flow down tree. This sounds silly, but it is not. Starting with my favorite requirements tool - MindManager. The root node is the delivered product. Start partitining the requirements into their logical categories, and further desomposing them. Do this in an interactive manner. BTW, this can be done with stickies on the wall, but MM just skips to the end.
    Start isolating the requirements into categrories and finding common connections. This is different than just making lists. Lists are linear. MM is non-linear (although hiearchical) and provides a "visual" connection between and amoung the requirements.
    Collecting "groups" can then be seen as providing the requirements in some form - maybe not 100% but in some way, while maintaining the product structure and architecture.
    This is a Systems Engineering approach.
    See Systems Engineering:Coping with Complexity, Stevens, Brook, Jackson, and Arnold, Prentice Hall for specific guidance

  5. Patrick,

    You have left me hanging.

    What was in the other two letters?

  6. Glenn

    This model sounds similar to something I read on a blog this week (Tyner Blain) where Ishikawa diragms were recommended.

  7. Janet

    Sounds like you and I rea reading from the same playbook.

    Glenn's model also seems to achive this goal.

  8. Craig,

    Sorry I'm so long answering :-)
    The two other envelopes say : "Blame the team" and "Prepare three envelopes".
    I'd rather not blame the team, unless I really had to !

    Patrick Prodhon