Perpetual development
I slid the CD into the drive, and clicked the ‘install’ icon on my Windows XP system. The percentage complete indicator showed 5%, 35%, 78%, 91%, 99%, all within the first 20 seconds, and then stood at 99% for about 3 minutes.
Sound familiar? Many BPM implementations are no different. By all indications, one of them being the ubiquitous Microsoft Project™, the project seems to be clipping along at a reasonable pace. Status reports from the team indicate good progress, and you are on track; that is until you hit the last month of your schedule. Then you see a request for an extension for a month. One month turns into two, and two to three. Pretty soon, the 18-month project takes three years to finish; a 100% overrun.
It is not so bad that it took three years. Perhaps if the scheduling was done right, the actual project was supposed to take that long. What’s bad is that management had no indication of the project delay until the last month. By this time it was already too late for risk mitigation.
Why does this keep happening and how can you prevent it? That’s the theme of this article. Here is the key to avoiding this fiasco: Assess, Measure, and Act.
Assess
Say you plan to drive from Los Angeles to New York. How do you determine that you are reaching your destination? Easy. Just figure out how much more distance you have to cover to reach New York. That’s an appropriate metric to use.
However, if you decide to use the straight-line distance as a metric, at times you will see a closing gap, and at other times you will see a widening gap, since the road can curve along different directions. This is fine, as long as you are aware of this caveat. Such deviation is quite common in BPM implementations as well. For example, the team may invest time up front to build a robust framework, hoping to leverage it for standardization and faster development in the later phases.
Measure
Once you know what to measure, then you have to actually measure it. Your metric should be able to answer two questions: (1) are you making progress, and, (2) can you reach your goal on time?
It is imperative that you measure everything you can. Oftentimes you may not be the person doing the actual measurements. In that case, you insist on the verifiable metrics, and make sure that the values are not “padded” or “guesstimated.” In most projects, a person estimates the “percentage complete” metric value for a task. This has at least two problems: (1) the person’s perception of scope may be completely different from managements, and, (2) the measurement is subjective. So “90%” completion on a task means nothing.
Act
When you started out from Los Angeles, perhaps you thought that you had a lot of time to reach New York. Hence you took some detours to enjoy the scenery. Then at some point you determine that you are not making as much progress as you would like. So, you make adjustments to your travel, taking perhaps fewer detours, or driving longer hours each day. Such sort of adjustments is required constantly on a BPM implementation as well.
The problem with BPM implementation
Let’s switch to a different analogy of building a house. If you are building a house, you can visually see the progress as it’s being built. If you are not an experienced builder yourself, your estimate on the completion date may be slightly off. Nevertheless, you will know if the progress being made is slow, moderate, or good. That’s because it’s tangible – you can see the house being built.
A BPM implementation on the other hand is not ‘seen.’ Only its effect can be felt. As mentioned earlier, data for the progress reports may come from people and is often subjective. Sometimes people will guess; sometimes, they underestimate the scope, or sometimes they simply provide false numbers to pacify management, with a genuine intension of catching up later. There is no convenient way for the BPM project manager to gauge the progress for herself.
What can be done?
Addressing this problem is the central issue of this article.
Here is one option. Make the BPM project tangible. How? Map it into something that can be touched and seen. You are looking for ways to visualize the project. One possibility is to consider the completed project the equivalent of a Lego Blocks™ based house. As the implementation progresses, you add pieces to the model house.
I already mentioned that the “% complete” metric is subjective. So don’t build your model house based on that metric. Doing so simply moves your tracking mechanism from one form to another. What you really need is a fundamental and more objective way to gauge progress.
Objectively determining progress
First you need a good set of metrics that can objectively quantify progress. For reliability, you have to include multiple metrics. This is akin to the set of metrics that determine the stock price of a company stock. Just the earnings or the P/E ratio in isolation is not a good indicator of company performance. Multiple metrics have to be considered. The same holds true for BPM projects.
Perhaps you want to visualize the progress through a row of houses – one house for analysis, another for design, another for implementation and yet another for testing. Choose different objective metrics for different phases. As your project progresses, you will build out these houses.
The success of your BPM project depends upon the successful implementation of the use cases that are determined at the beginning of the project. For example, in an order management system, successful order entry may be one use case and checking the status of an order may be another.
If the business analysis is done right, you should have a number of use cases that showcase how the system should behave. Each use case will map to one or more features of the system. If you can successfully demonstrate a use case, you can be assured that the features that are required to make that use case work, have been implemented.
Say you had 100 use cases and 80 of them have been tested and they passed successfully. Then you have 80% completion. It does not matter that, according to your team the remaining use cases are ‘almost done.’ As far as you are concerned, the use case is not complete. It’s binary; yes or no. Keep is simple.
Visualize progress
Once you determine the metrics, you would want to monitor the progress in a public way. For instance, you could display the Lego Blocks™ model row of houses in a prominent place as they are being constructed. This not only helps to monitor the progress, but also serve as an incentive to make progress.
Say for simplicity that your Lego Blocks™ model house has 100 pieces. Each piece may then represent a use case. The use case is either completed or it is not. For each use case that is complete, you add a Lego block. You could also get creative and color code critical components with say red.
Caveat
When implementing BPM projects, some components are difficult to quantify. Architecture is one of them, and it’s not captured in a use case. Hence it is critical not to visualize progress based on a single metric. If that was the case, then you may see no progress for the first few months when the system is being designed. Alternatively, there may be some artificial pressures to ‘get something out’ based on a poor architecture, simply to satisfy management’s need to see progress.
It is also important that your team collaborative determines these objective measures of progress so that they feel included. The measure don’t have to be right the first time; they can be refined as the implementation progresses.
Conclusion
BPM implementations tend to overrun budgets and schedules. Monitoring them through visualization is an effective way to gauge progress and alert you far ahead in the schedule.
