Skip to end of metadata
Go to start of metadata

Many of the patterns that are described in this wiki require some up front investment. The cost of the investment can either be direct in terms of added work or indirect through reduced business value in a release. The value of the investment is in reduced risk of failure or rework.

Investing in a MRP strategy is very similar to the development practice of refactoring. The reason developers refactor is that by cleaning the code it becomes easier to maintain. Refactoring is therefore an up front investment with long term benefits.

In Replacement projects there will often be an unwillingness to invest in changes to the system being replaced. The intuitive feeling is that these investments are a waste of money since the system is going to be closed down. This is unfortunate since many highly effective MRP strategies require that some changes are made to the legacy system.

technique technique Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 20, 2009

    A golden rule is to limit up-front investments to effort which can be measures to a positive ROI within 3 months development

  2. Oct 20, 2009

    Investments that reduce risk can be difficult to measure. Most projects believe they understand the users needs until a release makes it obvious that something is wrong.

    1. Oct 20, 2009

      So what you say is "Since I belive it is difficult, we shall not be bothered to try?"

  3. Oct 20, 2009

    If I quantify a goal of say reducing application processing time by 50% I can later measure success by looking at what has been achieved with the help of a new solution. If on the other hand my goal is to reduce the risk of a failed project, I will not really be able to measure the effects of any strategies used. If the project succeeds it may or may not be because of the measures taken.

  4. Oct 20, 2009

    I think we need to differentiate between individual measurements and general ones. A goal that is specific to a project should be measured by that project. Goals that are immaterial and general should be measured across projects. If we want to improve code quality by pair programming we should look at studies of the effects of pair programming in general. Same goes for reducing risk of failure.

    I would love to see research as to the correlation between long release length and project failure rate. I believe that it is strongly positive.