Although strong project management discipline contributes to overall success, it may be time to shift your perspective. By viewing your project as a process, you can apply process improvement technology and watch performance really take off.
SHL Systemhouse, Ottawa, Canada, a major systems integration company specializing in large IT projects, did just that on one of its outsourcing initiatives, and the results were dramatic. The company won an outsourcing contract to operate, support and maintain a complex billing application for Manitoba Telecom Services, Winnipeg, Canada, a major Canadian telecommunications firm. Systemhouse would operate the system, provide application-level support to customer users and maintain and enhance the application. The win-win opportunity would provide the company with additional revenues and the customer with strong service and stable costs based on the number of invoices produced.
IF YOU WANT TO DO MORE, DO IT BETTER, DO IT FASTER AND FOR LESS, MAKE PROCESS IMPROVEMENT, LEAN DESIGN AND EMPOWERED TEAMS PART OF YOUR STRATEGY.
However, after a year of operation, neither firm was satisfied with the results. The customer felt that the responsiveness and the level of service for support and change requests could be improved. Systemhouse, on the other hand, while doing its best to satisfy the customer, was experiencing profit expectation shortfalls of close to $1 million a year.
Because the company already was applying its strong project management discipline and project delivery methodology, it turned to process improvement with an empowered team. After a four-month process improvement journey, the team achieved fewer than six defects per year, shortened cycle time from an average of more than 100 days to less than 30 days and garnered a smaller multidisciplinary team with high morale.
These results were dramatic and beyond what the team had expected. Not only were they able to meet and exceed customer expectations, they also closed the profit expectation gap.
Road Map
A team of six representatives from the actual project team and one facilitator knowledgeable in process improvement techniques met several times per week while carrying out their normal duties and were able to achieve these results with little additional investment or commitment. Because process improvement is a holistic approach that includes workflow, policies, people, tools and organization, it can potentially bring order of magnitude improvements in productivity to both projects and business processes.
The team followed a “road map” (Figure 1) that instilled a common process discipline on the team and can be applied to any business process or project.
Define your baseline benchmark.
Improvement implies a comparison between two measurable points of reference. The team selected a set of performance metrics:
▪ Customer—Satisfaction and quality
▪ Financial—Team size
▪ Internal Process—Cycle time (how long it took for a request to go from birth to a new release)
▪ Learning and Growth—Employee satisfaction.
The team then set out to measure the current state for each metric, which resulted in a baseline benchmark (Figure 2). Any time a change is made to the process, a new baseline is established to confirm that it has a positive effect—and to shift the focus from opinion to facts.
The team interviewed the customer to obtain the satisfaction metric. The rest of the measurements were internal to the process. None of the metrics were open to interpretation or opinion from the team or from management.
Select the problem focus.
The baseline provides everyone with a common understanding of how the process is currently functioning. It forces all to achieve a good understanding of the situation before any solution is applied.
Management was interested in reducing costs and satisfying the customer while the customer's chief concerns involved the excessive time it took to go from request to implementation and the number of subsequent errors.
The team chose to address the customer issues first, believing that if these were addressed, Systemhouse's internal solutions would follow. This is the most critical part of the whole improvement process: selecting the correct issue. A proper customer focus drives the remainder of the process and increases the chances of success.
Understand the value stream and quality performance.
The value stream is that set of activities, policies, people and other resources required to take the product or service from initial request to customer delivery. The team mapped out the major activities of estimating, prioritization, analysis, design, coding, testing, implementation and emergency fixing. This ensured that everyone had a common and complete view of the whole application support process.
In addition, every process improvement initiative must have some sort of quality measure as a baseline metric. In this case, historical data showed that every release contained errors that were not caught through testing. These faults led to customer dissatisfaction and increased costs due to the development of additional emergency releases required to correct them.
Understand the project's organizational structure and workflow.
The team compared the dynamics of the process to the organizational structure. It learned that workloads for analysis, design, coding and testing varied significantly at different stages of each release. However, the structure and job descriptions provided for a fixed (non-varying) capacity of the major skills. The constant gap between the demand and supply of skills produced delays and waste.
Understanding workflow was one of the longer steps requiring a half-dozen sessions. The team mapped out the entire process in detail and reviewed each step to determine if each added value.
Determine cause and effect.
The customer's chief concern was the cycle time: There was a release every three months. Following a month-long prioritization process, each new release was planned over two months in parallel with the development of the current release.
A request that followed this normal path would take about six months, leading to the long cycle time of more than 100 days. Numerous “expedited” special releases were required to accommodate important changes, and these special releases always conflicted with the current work, causing plan changes.
Formulate solutions.
By now the team understood the end-to-end process. Be-cause it understood cycle time was key, it applied a rule of thumb from the concept of “lean design” and cut the batch size in half.
In this case, the release, or batch of requests, was the batching mechanism. Because requests were not standard, the team's approach was to increase the frequency of releases to every six weeks.
Reducing batch sizes highlights process roadblocks. For example, the operations department required a two-week lead-time to move a release to production. For a three-month cycle, this was just an annoyance, but at six weeks, it became a difficulty. If the team cut the batch size further, it would become a roadblock.
A number of non-value-added functions also were discovered, such as reviewing each user request and doing a preliminary analysis and estimate. Because many requests were never acted on, this effort was wasted. The customer reluctantly agreed to forgo the preliminary estimate and base its prioritization strictly on the expected benefits (putting value first).
As a natural byproduct of analysis, an estimate was prepared as soon as work began on the request. In practice, there was virtually no case of a request being cancelled at that time. After all, these were the changes most likely to provide a benefit. More time could be spent on value-added work on the release, essentially increasing the effective capacity of the team.
Implement improvement and monitor results.
Cutting the batch size in half and eliminating some non-value-added work were among the changes made during the first pass. With the implementation of the two changes, a new performance baseline was achieved. Responsiveness improved immediately along with customer satisfaction.
The elimination of much of the non-value-added work also meant that even though the team now had half the time to deliver a release, the release actually contained about 70 percent of what would have been in the larger release. Although all the indicators had improved and the customer was pleased, the team still had a ways to go. In addition, management's goal of eliminating the deficit was still up for grabs.
The team repeated the cycle several times over a four-month period, making major progress (Figure 2). Although the team had set out primarily to meet the customer's goal, in the end, it succeeded in turning the project structure into a smooth, predictable, high-performance process while cutting the team size to less than half—without compromising any of the performance indicators.
By the end of the four-month journey, the team was on a regular weekly release cycle. Each release went in cleanly; no special releases were required to accommodate important requests. The team understood the process well, so much of the management and planning time required for the large releases disappeared. Only lean process remained, with the majority of effort going directly into the release. PM
Angelo Baratta of Baratta Systems Innovation Inc., Mississauga, Ontario, Canada, has more than 20 years of experience in the management and delivery of information technology projects.
Reader Service Number 077