29 July 2008

Valuable requirements

Projects are often supported by unrealistic business cases.

Many are overly optimistic.  Some are overly pessimistic.  Most are full of educated guesses (and some are not so educated.)  Many are trying to justify the project on only financial value statements. 

Let's start with first principles. 

Projects should deliver value to the clients.  That value can come in financial and non-financial ways. 

If the project is aligned with strategic imperatives then it is probably a better use of resources than a project that isn't contributing to strategy. 

But you also have to balance capability with desire, so some projects do end up being about quick wins and what we can do, rather than what we should do.  This is managed through a project portfolio approach.

So now I am getting to the trigger for this post.  I was browsing Scott Quick's website and found this quote from Forrester;
    "Successful packaged apps strategies require business process and applications professionals to align with corporate business drivers. But because business drivers for individual IT projects often shift with time, the portfolio of apps initiatives requires organization and alignment by economic state and project risk. Once alignment is achieved, business process and applications professionals should identify the high-priority initiatives that best align with current business drivers and create a business technology (BT) value plan that connects the dots between corporate strategy and application tactics."
Changing corporate business drivers?  Prioritise the important things first?

Sounds sensible to me.

The agile software development crowd have a solution for this - it's Scrum's product backlog and short delivery cycles.  But you don't have to use agile methods to address this issue.

Everybody is familiar with prioritising requirements and there are dozens of models to help you do this.  The problem is that many people get caught up in the optimum solution versus the bare-bones delivery paradigm.

It doesn't have to be one or the other.  It does end up that way if you don't prioritise your work properly though.

Each requirement line item has to be mapped back to the business strategy, and it must be clear about what the value it brings.

My personal bias is that I feel requirements often get convoluted and very detailed and so lose their relevance to business strategy and goals.  So for me, another important issue is in maintaining simplicity and clarity of your message along the project value chain.

So, how about it requirements managers, can you do that with the set you are working with today?  And if not, what needs to be done to improve things?

Maybe the thing we need to include in all our project documentation is a value management plan?

Image care of Soundman1024, CC and Flickr


  1. Have you ever worked with a Human Factors engineer to determine customer needs?

  2. Gretchen,
    No I don't think I have worked with anyone with that title, although I have used with people who go by the title HCI consultant.

    Is it the same thing?