13 July 2008

Properations


I made up the word 'properations' - for the situation where you find yourself in that no man's land between projects and operations.

Have you ever found yourself in this situation? The project should have finished, but just keeps on going? The scope is creeping you out, the client just isn't ready to take on the product, you just can't get that last sign-off...

For whatever reason, you just can't get to "done."

What did you do about it?

How can we avoid this situation?

5 comments:

  1. Hi Craig,

    This exactly where I find myself at the moment with a large eHealth project I have just inherited. It started 10 years ago, and over seven million dollars has been spent on it, but more than half the end users refuse to use it! They have built from the ground up their own tool, which has its own set of problems, not the least of which is enterprise level backup!

    I have suspended all work on the first project and funding for the 'ground up tool'. My intent is to kill both projects, work out how to backup and migrate data from both tools, and buy a commercial off the shelf product, possibly through a private public partnership.

    More than half the problem can be attributed to inadequate and/or overly ambitious requirements. The next problem was poor user engagement and multiple delayed roll-outs. Then the product simply didn't keep up with technology - Moore's Law!

    It's a good case study on how not to run a project - arghhh!!!!

    Best Regards, Graham

    ReplyDelete
  2. Yes.

    Why do smart people like us end up in places like this?

    :)

    ReplyDelete
  3. Glen B. Alleman6:29 am

    Add two deliverables near the end of the project
    1. Transition to Business
    2. Transition to Production
    These two steps move the project from development and deployment into the production envirnment and then into the production environment with the business running the system.
    There are many tasks and deliverables in these two phases that make that transition.

    ReplyDelete
  4. Yes Glen,

    Defining what done looks like early is a really important task. Sure it changes as you travel, but it's a (the?) key defining milestone.

    ReplyDelete
  5. Problem #1: Humans are flawed.
    Problem #2: Technology is flawed.

    That's the reality, and it's better to accept it than to hope that you're project won't have to deal with it.

    So from a scoping perspective, you'll always underscope. You can't capture every tiny tidbit of detail upfront, and even if you did - the people absorbing the requirements won't be able to fully absorb it all.

    I think the key is executive sponsorship. There has to be someone overarching all of it, who can chop out the unnecessary fluff, mandate that users will use it, determine the critical go live pieces, etc...

    For example, when we were building the Death Star - it was getting horrifically behind. I had to personally oversee it - I told them to cut out the cafeteria, do the ventilation later, and focus on the power systems and energy laser so that I could blow the planet Alderon in time.

    Collaboration only gets you so far...

    ReplyDelete

Search This Blog