21 January 2008

Prince Lite > Let the Dog Wag its Own Tail

A guest post from Dr Peter Merrick of Princelite.co.uk;

It is not news that a lot of money is wasted in IT projects. What is surprising is how senior managers take a complacent attitude to IT project failure; that is until the project is 9 months late and consuming money hand over fist, with little evidence that it is ever going to be finished.

In my experience the problem is not with technology. Let me dispel a myth; the user requirements will not become clear as the project goes along. If you are a business stakeholder who needs IT to stay competitive, it is no use delegating the details to your supplier. You have a part to play, and if you do not play that part then the project will fail. Depending on the amount of money involved, this will cost someone their job.

Let me be controversial. It is in the interests of the supplier NOT to work from a clear simple unambiguous statement of requirements, because where there is no specification, there is no definition of success or failure so how are you going to judge it? By the time you run out of patience, the bill will have soared.

Sure, databases and OO modelling is a specialist subject, but anybody can understand use case models, activity models and screen mockups and that is all business people need to understand to play their part because UML (the Unified Modelling Language) takes care of the rest. Technies know how to transform these ‘business oriented artifacts’ into code. The other great thing about this approach is the user acceptance tests are described upfront. Progress can be measured. Success is defined.

The technical community puts a lot of store in project management frameworks, like Prince2 or RUP, but these approaches are flawed because it is not project ‘management’ that is of interest, rather it is project ‘delivery’. The fact a project is well managed and that it ticked all the boxes, does not mean it will deliver a working system.

What is needed is a delivery framework that priorities the business community stakeholders; the senior management, the middle management, the project management and the users. That means producing artifacts that the business community can fully understand and own intellectually by making the fullest use of pictures and ensuring words are kept to a minimum and that the documents overall are short.

If they are not short, they will not be read, defeating the purpose. Furthermore, the gap between the business stakeholders and the technical stakeholders must be bridged by the business requirements specification which must provide a completely unambiguous statement of requirements.

My response to the problem of bloated frameworks is to define PrinceLite; a process designed to let the dog wag its own tail, by which I mean really put the customer back in the IT project driving seat.

The main points of this new framework is it explicitly recognises the needs of all management stakeholders, it defines artifacts that are easy to understand, yet is based on UML so they can be transformed into solutions, and it comes with downloads of worked examples www.princelite.co.uk.

Dr Peter Merrick holds a Ph.D from UEA in Software Engineering and has published on the subject of UML. He has worked for the Health and Safety Executive, HMRC, Great Hotel, University of Cambridge Examinations Syndicate and the European Patent Office. He currently holds a senior contract position with central government and is available to discuss any of the points he makes here or on the PrinceLite site.


  1. Can't agree more with the need of having business stakeholders and community involved more in the game. Afterall, there's a reason they are called stakeholders.

    The question, however, is - how do you solve this problem? Your suggestion of pictures and crisp "stories" is a good one. I agree and fight for condensing stories. And, let me tell you, it works. Showcases are yet another way to get the community interested.

    The other side of the equation is oftentimes missed and I wanted to bring it to your attention. The project teams should also try to get the stakeholders more involved. We are as much as fault as the business community. Software development community has bought too much into their own hype of being smart and intelligent people. Smartness and intelligence are not substitutions for agreements and vision setting.

    A few days ago I wrote a blog about the Dying Art of Conversation. While I didn't point to this exact problem as a direct consequence of lack of conversation, simply because I couldn't pinpoint it out, it definitely is an issue of less communication. Developers and Analysts have almost lost the ability to talk in plain English with the Business, which is precisely the reason that link breaks down and sometimes the stakeholders are alieniated and often, in large corporation, seem disinterested.

  2. Well, what can I say? It sounds like we are in complete agreement. Getting the business community engaged (and not just engaged like zombies) is a prerequisite to delivering something. It's not the whole answer, but it's a lot of it - the other is requirements! Is this the most misunderstood word in the whole of SE? We've got to link up Proj Mgt thinking with SE thinking end to end. We need a rigorous cast iron definition of what a really first class business 'requirement' actually looks like. Out with them, I say, and let's have a look. I'll show you mine, if you show me yours...

    Rajeev? anybody?

  3. Peter

    you won't find too much disagreement around here.

    Thanks for dropping by.

  4. Anonymous9:15 pm

    I appear to be rather late to this party but a good article, thanks.

    Only minor point I would make is that I do not view RUP as a project management framework. It is a software engineering method that assumes an existing PM discipline (I see it falling within the CS process within Prince 2).

    Peter - you ask what a first class requirement looks like? I would suggest that the min content for something to be classed as a requirement should be:
    - Statement of requirement.
    - Rationale for the requirement.
    - Test condition (i.e. what is the sign off condition for this requirement).
    - Priority (I know, I know they are all Priority 1)

    Unless you have the above information for each and every requirement on a project then you are allowing an element of ambiguity into your project, and as we know ambiguity leads to slippage.