Friday, December 10, 2010

MIN = MAX-rule

MIN = MAX-rule
The MINimum that is required
is the MAXimum that we'll do
                        (Stefan van Aalst)                     

In the top 3 of reasons why projects fail or are less successful than they could have been, is scope creep / changes. The min=max-rule significantly reduces this cause for failure.


IMHO there are only two flavours when it comes down to scope:
  1. Must-have's
  2. Not-must-have's
The definition of must-have's is simple: without the must-have products the project will not deliver the benefits that it is required to deliver. In PRINCE2 terminology: the business case is seriously compromised. All other items fall into the category not-must-have's.

The best way to verify and test if a deliverable or product belongs to which category, is to create a Product Flow Diagram that at the top directly connects to the project deliverables and business benefits. If a product is not required for the full 100% to deliver other necessary products, deliverables or business benefits, that product is not a must-have.

Why is this the MIN=MAX-rule so important?
Imagine the situation that scope reduction is sought after. Not an unlikely situation in organisations that have a shortage in budget and or resourcing or when there is a due-date issue. Such a situation is usually a cause for a fierce debat, people taking positions, etc. However, the outcome is always simple:
  1. If not-must-have's have been identified:
    • one or more not-must-have's will be removed
  2. If not sufficient:
    • one or more must-have's will be challenged
    • back to #1
The worrying part is the following. 

First. Usually the reason why scope is being reduced is due to a shortage. Shortage in money, resourcing or time. If it is possible to scrap something, it means that it was not required in the first place. All the money, hours and days that went into it already therefore were wasted. 

Secondly. Some people have put good effort so far in realizing the not-must-have's. How would you feel if you were told: you did a fine job so far, stop working on it, we're not going to use it. How likely is it that you will walk the extra mile, work the extra hours if this happened a few times?

Thirdly. Removing the work done thus far is usually not done very tidy. It is not unusual in software to have all kinds of codes lingering due to scrapped features. Code that can cause some serious issues in production or with later releases.

What is the miminum?
The mininum scope is not just what is technically needed. The minimum scope is that what is needed to ensure the succesfull realisation of the benefits.

If this means that 'additional' products and/or deliverables must be realised in order to ensure sufficient cooperation of a major influencer, so be it. People's active cooperation and motivation are as much part of the equation for success as is that the thing works technically. Usually the cooperation and motivation is much more important than a smooth technically working thing.

How to establish the minimum?
The PFD+ technique provides excellent guidelines and questions to arrive at the mininum.


No comments:

Post a Comment