17 October 2008

Understanding projects

Executives and CEOs around the globe want to know why projects cost so much and so often let them own by deliverring poor outcomes and going over budget and over time.

It's an issue worth exploring. Even though we as practitioners are vaguely aware of where the project's key risk and failure points are, business sponsors and stakeholders continue to be disappointed.

What are you doing, or have you done to ehlp your non project professionals work with your team?


  1. It's all about service. When you work with a stakeholder or sponsor at any level, understand what their perspective is, and what they are expecting from the project. Show them that you are there to help them personally through your project. Go the extra mile to make it easy for them. Add little things that you anticipate they would like to see without them having to ask for them.

    Josh Nankivel
    The Art of Project Management

  2. I found that delivering early, valuable results help a lot. By early I mean something like after 2-5% of the project time, and then every 2-5% again. The customer wants to be more successful after the project, compared to before. If you deliver something he can use right away, and deliver frequently, he's likely to declare the project successful. I never met a customer who is not happy with this.

    Rolf Goetz, ClearConceptualThinking.net

  3. Ahh Rolf, you are srumming or some such. Good work.

    Can you give an idea of one of the larger agile projects you've deliverred?

  4. Craig,
    While delivery early and often "may" be an acceptable approach, the ability of the business to absorb these multiple releases is important.
    More important is to produce a "known" valuye stream to the business. Things they not only want, but things that actually move the value of the business forward.
    Discovering these "values" (whihc by the way MUST be monetized in units meaningful to the business) is a requirements elicitation process. But before requirements elicitation (gathering is onlyoine step of elicitation), there must be some understanding of the needed business capabilties.
    "What would we do with this system f it was free, worked perfectly, and was available this afternoon?"
    This information is usually captured in a Concept of Operations (ConOps). While a defense system notion, ConOps are used for Enterprise Content Management (ECM) and ERP.
    With Capabilities, requirements derived from those capabilities, THEN the delivery of functionality can take place.
    But in ALL situtaions the availability of functionality must coinside with the firms ability to absorb this functionality in their business operations.

  5. Glenn

    I get what you are saying.

    Let's put aside all scepticism for a moment and say Scrum does deliver features faster and more reliably and defect free than most other project methods for a moment.

    Are they the right features?

    The mechanism in scrum is to ask a product owner what to do next. Not much seems to be written about how the Product Owner goeas about thi task.

    For complex enterprises facing complex problems I expect some deep thinking has to happen first.

    Requirements may trickle into the tech team, but a big picture - maybe a business architecture - view needs to be established.

    And then there is the change management aspect to consider. Training, getting people to adopt the change, scheduling other changes among system releases etc can also be a complex activity.

  6. I think I'll put that that previous question up as it's own post for better visibility.