Skip to end of metadata
Go to start of metadata

Regardless of how you plan to tackle MRP in a project, the first rule for an optimal MRP is that pain is preferable to a long release. Only include functionality that is absolutely essential. Features that are valuable but not essential should not be in a release that is more than three months long. The hard part is getting stake holders to accept a painful release. This is especially true for functionality directed towards customers. The obvious fear is that the business will lose customers if the release isn't good enough.

Minimizing features in the MRP does not mean that one should release a system that will be useless for internal users or customers. The features that are included in a release should also be of high quality. Pain is caused by the features that are missing, not by including poorly built features.

Mitigating pain

There are many strategies that make it possible to release a very limited version:

  • Use Limited releases so that only a few users/customers are affected
  • Pain relievers can compensate users and customers for any inconvenience they experience
  • Differentiators can give users and customers gains that outweigh the losses

The important thing is to make all stakeholders understand why the release must be limited and give them an idea of how long it will take to get a more complete version deployed. Once the release is in production it is much easier to prioritize functionality based on business value.

Pain in Replacement projects

Getting stakeholders to accept a painful release is particularly hard in a Replacement project. The gut feeling in the business will be that you must wait until "the new system is as good as the old one". One of the core responsibilities of the product owner is to work with stake holders and make them understand that it is in their interest to have as short releases as possible.

Labels:
technique technique Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 19, 2012

    I realise that this wiki have some articles that are a couple of years old now, but a lot of them still applies

    In this case I cannot see how to get customers to accept a replacement that does not fulfill the minimum of the previous release !!?

    If I run a web interface for instance for my bank accounts, I should then accept a interface that may only allow me to see my cash statement and not move money - a function that the old one have had for many years potantially.
    That will not fly !

    For internal customers/tersters getting a beta/pre-relase out is much easir, but then you of course get other problems (as mentioned elsewhere in this wiki)

    /K

  2. Nov 19, 2012

    You are right in that the amount of pain that you can make users endure depends on the type of user. That said there are ways of getting users to accept quite a lot of pain. When Google Docs first came it was painfully lacking in a number of very basic features (and a gazillion other ones too). The reason a lot of people still chose to use it was not because it was free. They used it since it provided features - simultaneous editing and cloud based accessibility - that people valued so highly that they were willing to bear the pain.