A significant question to ask is, “How often is the business case expressed in terms that could later lead to outcome realisation testing?”
My ongoing experience is that organisations still put insufficient effort into defining “proper” business requirements. This leads on to situations similar to,”The product behaves as required but our business has not improved”: or “We got we paid for but did we get a return on our investment?” I suggest this is a form of project failure: possibly the most significant. A possible (I think probable) cause is a lack of Project Owner/Sponsor skill. Do the Project Owners out there actually understand the extent of their responsibility relative to project governance? As a way of addressing this issue, the PRINCE2 people have instituted Project Sponsor Certification (not to sure about the value of certification — but at least it’s a step in the right direction).
I think that the lack of business requirements problem is exacerbated by the Fragile/Tragile practise of “the requirements are in the code!!” It also bothers me that so many still seem to think the business requirements have something to do with the content, look, and feel of the user interface: the classic confusion about benefit versus feature. So many organisations still call Functional (system) requirements Business requirements.
I feel that yet another issue is the seeming lack of understanding about the difference between project governance/management methods and system development and maintenance methods. I think Agile is a type of SDELC and project governance should wrap around it. I wonder if we should start Agile development only after business benefit requirements are well-understood and signed forward?
Looking at the issue of software becoming more complex, yes I agree it is. But I also think that there is much larger catalogue of solutions than there used to be. Shouldn’t we be making much more use of “software ICs”: electronic engineers rarely design their own components — they buy them from a catalogue. I feel that there is an argument for software construction to move more quickly than it is toward software component integration. If you can buy it, why build it? The idea of software ICs is of course not new: what has happened to all the hype about reusability from just a few years ago?
Given that software projects are more complex than they were, this could well mean that the management of software projects becomes more complex. That brings us back to the question of how do we improve project governance (of which individual project management is a part)?
People management is of huge importance: so why is it that so many Project Management offices seem to be staffed by grey bureaucrats with EQs approaching zero?
In the end, it seems to me that my maxim, “Manage the requirements and manage the people, then the project will manage itself” holds true.
Posted by John Watson