Off the Rails
The Problem: As all of us know and recognize, development projects are often late and deliver fewer features than marketing wanted, and the QA team is forced to do a subset of the testing. This results in one or more of these three outcomes:
The release is late
Features were dropped
Quality is lower than target
However, the project team knows far in advance of management if the objectives will NOT be met, yet the team defers the acknowledgement and admission of this reality – unless blame can be ascribed to another function (this is where politics comes in). Unfortunately, this behavior really impacts the business because the rest of the downstream players (marketing and sales) are not aware. The impact of the slips on sales OR when key features are dropped can be significant.
So What: It is easy to justify the ‘opportunity cost’ of a delay is equal to the potential sales rate. So a one week slip in a product that does $50Min annual revenue would be approximately $1M per week, or $200K per day, or $25K per hour! In reality this rate could be much higher if a key launch window is lost. Typically, this financial impact is in fact equal to the rate of sales on a week per week (or day by day) basis.
The Remedy: A formally defined Out of Bounds (OOB) process can dramatically reduce time to market (by as much as a 30% reduction) since the team does not wait for decisions nor is the team afraid to come up with the truth. The OOB process consists of a simple decision model that does not penalize the messenger or the project team leader. The process also gives teams more autonomy because it tends to reduce micromanagement since the leaders are confident that the project teams will notify them if they go off the rails.
Out of Bounds Process: At a key review date, or at a phase review, the team (with a Project Manager taking the lead) will propose to management the 3-6 most important program issues and associated limits. For example time to market is 12 months, and if it looks like we will exceed 13 months, we will have an Out of Bounds trigger from a one month delay.
An example of the boundary conditions is shown below:
We have seen this work very well because it is a defined process, it is very efficient (since many decisions can be handled by email rather than a meeting), causes bad news to be communicated rapidly without blame, and helps prevent micromanagement by the executives. If the team is within the project boundaries, there is little need for management involvement. An example process is shown below:
We once worked with a client that complained they were doing OOBs all time, and that was bad. However, in reality, that is good because this shines a light on all elements of a program that is broken. This same client got to a place where OOBs were only called infrequently and their process was ‘under control.’ This same company has been using this process for over 15 years and is indisputably the leader in its category.
The Lesson: Product development programs going off the rails is a frequent occurrence. By utilizing a simple process, such as the out of bounds review, teams can recover quickly and the financial impact of a delay can be minimized.