From the Sponsor’s Desk – Knowing Your Project Profile
In my last post, Avoiding New Technology Risks, we looked at the steps one project manager took to leverage a promising new technology while avoiding the pitfalls often encountered with new technology introductions.
In this post, we’ll look at the approach one CIO took to confirm his gut feeling that a project was going to be well over budget and behind schedule. Thanks to reader B.L. for the details on this case.
This Canadian insurance company was experiencing significant growth and having difficulty maintaining service levels at an affordable cost. The underwriting organization, in particular, was having a challenging time. Experienced underwriters were hard to find and training new staff was a long, slow process. The sales agents were unhappy with the response and level of quality on new applications for insurance. It cast the organization in a bad light with their clients. And, of course, agent compensation was negatively affected.
The VP responsible for the underwriting function, in consultation with the CIO, decided to explore the use of technology to alleviate the pressure, improve service and reduce costs.
The VP of the underwriting function, the sponsor of the initiative, decided to launch a development project to automate much of the underwriting process. The plan was to have the applications for insurance processed by staff in the sales offices across the country using the new automated service with the potential for immediate approval and contract production if everything checked out. The target was to get the project implemented and operational in a year or less.
The sponsor and his staff calculated that they could save over $1 million annually in reduced administrative costs in his organization while cutting processing time from 10 days to 1 day on 60% of the applications. As well, sales agent compensation would be accelerated, service to clients would be improved dramatically and dependence on scarce underwriting resources would be reduced.
In consultation with the Sales VP, it was determined that the additional time required from administrative staff in the sale offices to process the insurance applications could be factored into the existing workloads and would require no incremental staffing. The project was a no brainer!
The sponsor appointed a manager from his organization to act as overall project manager. His job was to implement new underwriting and administrative processes and practices that would affect the sales agents, administrative staff in the sales offices and underwriting and administrative staff at head office.
The CIO appointed a project manager from his organization to guide the development of the technology solution.
The two managers collaborated on the estimate based on their previous experiences and arrived at a cost of $2.5 million and a year or so duration. They agreed to adopt the in-house system development methodology, a typical waterfall practice. They formed a steering committee with the key stakeholders – the sponsor, the VP Sales and the CIO – and proceeded to form their teams to tackle requirements definition.
The sponsor was adamant that the new automated system reflect their current underwriting practices to maintain or improve on their claims experience. So, the project managers adopted a prototyping philosophy that they could us to demonstrate practice compliance to the sponsor and his senior underwriters as well as to the staff in the sales offices. As the requirements definition progressed, the project managers encountered a multitude of “what if” questions in response to their prototypes, mostly from the senior underwriters. That required another round of prototypes and reviews and lead to more “what if’s”, and so on.
The planned three month requirements phase extended to four months, then five but the project managers insisted the overall project was still on target. Their rationale was that the requirements would be so well defined and fully approved that the 10% change contingency they had included in the budget would not be required. They also argued that the level of detail in the prototypes would enable multiple parallel development streams and reduce the cost and time required for the development and testing phases.
Project Profile Chart
The sponsor and the VP Sales bought the argument. The CIO did not. He had his Project Office pull together a profile for projects completed by the system development group in the previous two years. The profile showed that, on average, the development and delivery phases consumed over 60% of elapsed time and over 70% of resource costs. He concluded that the project would take another year to deliver and exceed the estimate by $1.5 million.
The CIO was right. The project took a year and a half to complete and cost almost $4 million. The IT project manager tried to reduce the elapsed time by developing the application components in parallel as he had argued previously. However, resource constraints limited the contribution the approach could make to accelerating the schedule.
The upside? The project was delivered successfully. The quality of the solution was excellent. The staff affected by the change in the sales offices and head office were enthusiastic about the system. The clients appreciated the service improvements. The project actually delivered over $2 million in annual benefits, largely because of the scope expansion resulting from the “what if” cycles. Even with the increased cost, the actual payback was greater than originally anticipated.
How a Great PM Could Have Helped
The project managers did a number of things well:
- Forming the steering committee help all areas affected by the change get involved and onside.
- Use of prototyping to facilitate requirements definition really did engage the experts and resulted in full backing from all involved. It also did contribute to a much lower level of change requests and helped deliver significantly greater value than originally planned.
- The quality practices leveraged from the in-house development methodology were applied effectively throughout the development process, ensuring a high quality solution in all respects, including the required ease of use for each target audience, appropriate performance and security, provision of an audit trail, integration with back end administrative systems, continuity of processing and adaptability to future changes.
Unfortunately the PM’s missed a couple of opportunities to help the project excel and damaged their bosses’ perceptions of their performance in the process:
- They didn’t recognize that the “what if” cycles were signs of scope creep. There’s nothing inherently wrong with expanding project scope but it has to be managed to expectations. In this case, it wasn’t.
- There was a good deal of urgency in getting relief from the growing costs and service problems. But, the plan didn’t recognize the need for a fast response. Instead, the PM’s planned to define all requirements up front. Had they adopted a phasing strategy from the get go, they would have had an opportunity to deliver a first release sooner than planned and would have had a framework to manage the “what if” cycles more effectively.
- The IT PM started looking for resources to support his parallel development plan as the requirements stage wound down. Instead, had he really understood the urgency of the situation, he would have had a resource plan in place from the start with the required staff ready to step in when needed.
- Finally, the PM’s didn’t have a Project Profile for the organization in question. If they had access to that information, it would have forced more rigor on the cost and time forecasting and reduced the wishful thinking that they ultimately engaged in to justify their circumstances.
This could have been a great project! In fact, after the initial disgruntlement over cost overruns and schedule slippage, the stakeholders were extremely pleased with the results. The PM’s could have been heroes. Instead, they were goats. It would have helped if the other stakeholders had challenged their approach and assumptions earlier. Unfortunately they didn’t. The PM’s missed the opportunity to take advantage of a few simple practices that could have made all the difference and they paid the price.
If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great PM, and your sponsor’s best friend.
In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.
Don’t forget to leave your comments below.