31 October 2008

Onion rings

Further expanding on my point from the other day - aligning requirements to the organsiation's goals isn't that hard.  All it takes is an understanding of the big picture.

It never fails to amaze me how many IT team members, particularly programmers and DBAs don't actually get the big picture.  How do they know if what they are building is helpful or not?  How can they stop and assess requirements and look beyond them to see if there are better ideas able to be implemented?

Of course many are across the whole thing and do a great job of delivering value.

Help the others out by being clear about how your view of an IT product contributes to the organsiation.

As you develop a set of requirements, come in top down, starting from the business goals or startegy and work your way down to the details.

Is anyone not doing this these days?  If so - can you share a story about whether it's working or not working for you?


  1. Unfortunately, I don't know that many projects that are well aligned. There are hundreds of reasons projects get lost, probably the biggest being that 2/3rds of the projects should have never been started, but no one had the guts to say "No".

    This is an area of great interest to me and I believe that as the organization gets bigger it gets harder and harder to understand why things are being done. God maybe in the details, but before then, he is definitely in the why. If everyone doesn't know why a project is being done, the details don't matter.

    If you want to put some sanitized examples together, let me know. It would be an interesting series of posts, the anatomy of misalignment. And how corporate structures and (ineffective) governance lead to poorly aligned projects which lead to about 2/3rds of all projects failing.


  2. Business process work normally leaves me with the same thoughts and feelings...

    I have lost count of the number of times I have asked somebody how what they do fits into the bigger picture, who benefits from what they do and how do they benefit, or why they do something in a particular way.

    My questioning often induces a blank look and a shrug. It seems that people are often unaware of the reason they do what they do, and, furthermore, rarely question it. Maybe they don't think conceptually or maybe it's just a day job.

    (The ever decreasing circles concept is nice, could be further extended/decomposed into SDLC components.)

  3. Craig,
    One starting point for improving this situation is to seperate "Requirements" from "Capabilities." This inverts the first conversation. The "Business Problem" is tranformed into "Needed Business Capabilities."
    This capabilities are usually captured in a Concept of Operations document. ConOps has been in defense and NASA for a long time, but is not being seen in ERP and Enterprise class systems.
    From the ConOps, technical and operational requirements can be extracted.
    With this approach, connecting the business stratgey (Balanced Scorecard for example) to Capabilities is more consistent. This traceabiity can be flowed down the Technical and Operational requirements.
    We've found - and the literature supports - that poor requirements management is the source of many of the project failures.
    Words like: "who order this?" "why are we spending money for this feature?" and "gee I didn't know we had to buy that component to make this thing work" can be addressed up front.
    Controlling the expectations is the key to addressing requirements management generated issues.

  4. What SHOULD happen:

    -A PMO or other group manages a portfolio of projects, and communicates the alignment with each charter.
    -The project manager communicates this alignment effectively with the project team on a regular basis

    What usually DOES happen:

    -An exec starts a project because it "feels" like a good thing to do.
    -The project manager doesn't understand the alignment, the alignment is non-existent, or the project manager does a poor job at communicating it.
    -For the project manager who does try to communicate alignment effectively, it is a post-hoc rationalization from their own perspective, and may be totally inaccurate.

    Josh Nankivel
    pmStudent on twitter
    The Art of Project Management

  5. Thanks for your comments guys.