Author: Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at [email protected]

From the Sponsor’s Desk – The Checklist Champion

Davison Oct23Co-Authored with Ruby Tomar

In my last post, we reviewed the challenges experienced by a project manager who saw an opportunity to improve the organization’s performance and took it, without official support. He launched a project to reduce the costs and time required to test the functionality for the consumer electronics device he and his team were supporting. It was a learning experience.

In this post, instead of the usual case, with the help of Ruby Tomar, we’ll look at a most informative book, the insights the author gleans about how to implement sustainable change and how you can leverage the Project Pre-Check building blocks or build your own to deliver your own sustainable change.

The book is The Checklist Manifesto: How to Get Things Right by Atul Gawande. He is a MacArthur Fellow, a general and endocrine surgeon at the Brigham and Women’s Hospital in Boston, a staff writer for The New Yorker, and an associate professor at Harvard Medical School and the Harvard School of Public Health. He also leads the World Health Organization’s Safe Surgery Saves Lives program. 

Dr. Gawande poses a question many of us have asked over the years – how do seemingly intelligent, knowledgeable, talented and motivated individuals and groups manage to get so many things wrong. In his book, Dr. Gawande refers to the work of two philosophers, Samuel Gorovitz and Alasdair MacIntyre, in search of answers. They suggested a couple of reasons for failure. One is ignorance, where we don’t have the necessary knowledge and skills to do the job. The second is ineptitude, where we do have the knowledge and skills required but fail to apply it correctly. How do we fix that?

The challenges Dr. Gawande faces are similar to the challenges we face managing business and technology change. The best practices he uncovers and the lessons he learns are also applicable to our program, project and change management efforts. Dr Gawande reveals the power of a seemingly simple tool, the checklist, to improve performance, reduce costs, increase returns and save lives in a wide array of endeavours including surgery, emergency room settings, construction, natural disasters, restaurants, finance, investing and many other circumstances.

We have borrowed extensively from Dr. Gawande’s book, extracting directly and paraphrasing liberally to give you a sense of the challenges his team faced and the amazing results they achieved. We thank him for his amazing achievements, terrific insights and generous support.

The Situation

The World Health Organization (WHO) contacted Dr. Gawande in 2006 to help them develop a global program to reduce the risks of surgery. “Officials were picking up indications that the volume of surgery was increasing worldwide and that a significant portion of the care was so unsafe as to be a public danger. Worldwide, at least seven million people a year are left disabled and at least one million dead—a level of harm that approaches that of malaria, tuberculosis, and other traditional public health concerns.” Dr. Gawande accepted the challenge.

A group of health care specialists from around the world gathered in Geneva in early 2007 to tackle the challenge. They understood the enormity of the task at hand. Some suggested more training. Others proposed incentive schemes such as pay-for-performance programs. They considered a set of WHO standards for surgical care. Dr. Gawande looked for and analyzed examples of successful public health interventions that the group could learn from. He states “All the examples, I noticed, had a few attributes in common: They involved simple interventions. The effects were carefully measured. And the interventions proved to have widely transmissible benefits.”

One of his favorite cases was a public health program to address the perilous rates of premature death among children in the slums of Karachi. The program used hand washing with soap in six different situations where cleanliness would have the most impact. After the first year “the incidence of diarrhea among children in these neighborhoods fell 52 percent compared to that in the control group. The incidence of pneumonia fell 48 percent. And the incidence of impetigo, a bacterial skin infection, fell 35 percent.”

States Dr. Gawande “Thinking back on the experiment, I was fascinated to realize that it was as much a checklist study as a soap study. So I wondered: Could a checklist be our soap for surgical care—simple, cheap, effective, and transmissible?”

His colleagues answered his question in the affirmative with a number of examples:

  • The Columbus Children’s Hospital had developed a checklist to reduce surgical infections. After three months, 89 percent of appendicitis patients got the right antibiotic at the right time. After ten months, 100 percent did. The checklist had become habitual.
  • A Johns Hopkins pancreatic surgeon showed an eighteen-item checklist that he’d tested with eleven surgeons for five months at his hospital. Likewise, a group of Kaiser Hospitals in Southern California had studied a thirty-item “surgery preflight checklist”.
  • University of Toronto had completed a feasibility trial using a much broader, twenty-one-item surgical checklist. Their checklist had staff verbally confirm with one another that antibiotics had been given, that blood was available if required, that critical scans and test results needed for the operation were on hand, that any special instruments required were ready, and so on.

The checklist also included what they called a “team briefing.” The team members were supposed to stop and take a moment simply to talk with one another before proceeding—about how long the surgeon expected the operation to take, how much blood loss everyone should be prepared for, whether the patient had any risks or concerns the team should know about.

These checklists not only helped ensure essential tasks were completed consistently, they helped build teams capable of responding to the unexpected. At Johns Hopkins, after three months use, the number of team members reporting that they “functioned as a well-coordinated team” leapt from 68 percent to 92 percent. At the Kaiser hospitals, after six months and thirty-five hundred operations, the staff’s average rating of the teamwork climate improved from good to outstanding. Employee satisfaction rose 19 percent. The rate of OR nurse turnover—the proportion leaving their jobs each year—dropped from 23 percent to 7 percent. And the checklist appeared to have caught numerous near errors.

Dr. Gawande and his colleagues were convinced. Further testing was warranted.

The Goal

At the end of the Geneva conference, the participants agreed that a safe surgery checklist was worth testing on a larger scale. The focus was to introduce a practice to significantly reduce surgical risks globally.

The Project

A working group was formed. They took the different checklists that had been tried and condensed them into a single one. They added any other checks they could think of that might make a difference in care. They incorporated the communication checks in which everyone in the operating room ensures that they know one another’s names and roles and has a chance to weigh in on critical plans and concerns.

They set up a proper pilot study of the safe surgery checklist in a range of hospitals around the world.

When Dr. Gawande returned to Boston, he told the nurses and anesthesiologists what he’d learned in Geneva. His team agreed to try it out.

It didn’t work out very well. On the first attempt, there was confusion about how the checklist should be administered. It was supposed to be a verbal checklist, a team checklist. Some of the checks were ambiguous. The checklist was too long. It was unclear. Everyone was frustrated, even the patient. By the end of the day, they had stopped using it. Dr. Gawande states “Forget making this work around the world. It wasn’t even working in one operating room.”

So Dr. Gawande went back to the drawing board. He consulted with the experts at Boeing, which has decades of experience developing checklists to address emergency, life and death situations that are trusted and used religiously by pilots world-wide. He also reviewed the experiences, practices and applicability of checklists at a major construction firm, a successful high end restaurant, the experiences, good and bad, from Hurricane Katrina, and checklist use in finance and the investment world. In every case, good checklists, used as an integral part of the organizations’ operations, made a significant, positive contribution.

Dr. Gawande returned to Boston. He and his team applied what he had learned in his research. They made the checklist clearer. They made it faster. They clarified responsibilities. They tested it in a simulation rather than a real surgery. Then they tested it in real life situations one case at a time, in different locations around the world. After each test, they assessed how well the checklist performed and revised it accordingly until they had a checklist that seemed to do the job. The final WHO safe surgery checklist spelled out nineteen checks in all. 

The safe surgery checklist on patient care in its final form was tested in eight hospitals around the world. They collected data on the surgical care in up to four operating rooms at each facility for about three months before the checklist went into effect. 

In early 2008, the pilot hospitals began implementing the two-minute, nineteen-step surgery checklist. The hospital leaders committed to introducing the concept systematically. They made presentations to all affected personnel. The WHO team supplied the hospitals with their failure data from previous sampling so the staff could see what they were trying to address. They also provided PowerPoint slides and YouTube videos, one demonstrating “How to Use the Safe Surgery Checklist” and one entitled “How Not to Use the Safe Surgery Checklist,” showing how easy it is to screw everything up.

The Results

In Dr. Gawande’s own words:

“The introduction of the checklist was rocky at times. There was a learning curve, as well. However straightforward the checklist might appear, incorporating it into the routine was not always a smooth process. Sometimes teams forgot to carry out part of the checklist. Other times they found adhering to it just too hard. The difficulty seemed to be social. Very few knew immediately how to adapt their style to huddling with everyone for a systematic run-through of the plans and possible issues. The nurses seemed especially grateful for the step, but the surgeons were sometimes annoyed by it. Nonetheless, most complied. Most but not all.”

“The final results showed that the rate of major complications for surgical patients in all eight hospitals fell by 36 percent after introduction of the checklist. Deaths fell 47 percent. The results had far outstripped what we’d dared to hope for, and all were statistically highly significant. Infections fell by almost half. The number of patients having to return to the operating room after their original operations because of bleeding or other technical problems fell by one-fourth. Overall, in this group of nearly 4,000 patients, 435 would have been expected to develop serious complications based on our earlier observation data. But instead just 277 did. Using the checklist had spared more than 150 people from harm—and 27 of them from death.”

With these kinds of fundamental improvements in patient outcomes, one would think that hospitals and surgeons world-wide would be falling over themselves to adopt the WHO checklist. Unfortunately, that was not the case. As DR Gawande commented “We were thrown out of operating rooms all over the world.” Unfortunately, resistance to change is a universal phenomenon. But Dr. Gawande’s team persisted.

“Perhaps the most revealing information, however, was simply what the staff told us. More than 250 staff members—surgeons, anesthesiologists, nurses, and others—filled out an anonymous survey after three months of using the checklist. In the beginning, most had been skeptical. But by the end, 80 percent reported that the checklist was easy to use, did not take a long time to complete, and had improved the safety of care. And 78 percent actually observed the checklist to have prevented an error in the operating room.”

“Nonetheless, some skepticism persisted. After all, 20 percent did not find it easy to use, thought it took too long, and felt it had not improved the safety of care. Then we asked the staff one more question. ‘If you were having an operation,’ we asked, ‘would you want the checklist to be used?’ A full 93 percent said yes.”

“Since the results of the WHO safe surgery checklist were made public, more than a dozen countries—including Australia, Brazil, Canada, Costa Rica, Ecuador, France, Ireland, Jordan, New Zealand, the Philippines, Spain, and the United Kingdom—have publicly committed to implementing versions of it in hospitals nationwide. Some are taking the additional step of tracking results, which is crucial for ensuring the checklist is being put in place successfully. In the United States, hospital associations in twenty states have pledged to do the same. By the end of 2009, about 10 percent of American hospitals had either adopted the checklist or taken steps to implement it, and worldwide more than two thousand hospitals had.”

Not bad for a little nineteen point checklist and some brave checklist champions who weathered their colleagues’ slings and arrows to save thousands of lives. A paradigm shift perhaps?

How a Great Leader Succeeded

Dr. Gawande and his WHO team did an amazing job of covering the change management landscape. So how can you leverage these insights and reap the successes that the WHO team achieved on your projects? 

Project Pre-Check is an example of a practice for guiding business and technology change that addresses the key components of the WHO effort: a stakeholder model to ensure the right players are engaged and responsibilities are clear, a comprehensive, 125 point best practice based checklist (the Decision Framework) and a five stage process to guide the decision-makers from inception to value realization. Here’s Ruby’s assessment of Project Pre-Check relative to the fifteen best practices WHO leveraged on their project.

Fifteen WHO Safe Surgery Best Practices Addressed by Project Pre-Check Features
1. Burning platform: they had the insight and foresight to identify the growing surgical risks.
  • One of 125 plus Decision Areas in Decision Framework
2. Goals: they had the audacity to establish and share a common goal.
  • One of 125 plus Decision Areas in Decision Framework
3. Affordability: they knew how much they could afford to spend to solve the problem. As the WHO official told Dr. Gawande at the start of the project “Oh, there’s no real money”.
  •  One of 125 plus Decision Areas in Decision Framework
4. Champions: they recruited project champions starting with Dr. Gawande. What a great champion he turned out to be.
  •  One of four roles in Stakeholder model
  • Enabled with five stage Project Pre-Check process
5. Sponsors: the WHO team ensured that every hospital involved in the project had a local sponsor to shepherd the change, establish priorities, align accountabilities and demand or coax changes in behaviours.
  • Enabled with five stage Project Pre-Check process
  • One of four roles in Stakeholder model
6. Targets: they identified and engaged the affected targets whose behaviours needed to change for the project to be successful.
  • Enabled with five stage Project Pre-Check process
  • One of four roles in Stakeholder model
7. Team: they built a team to build local teams.
  • Enabled with five stage Project Pre-Check process
  • Shaped by Stakeholder model
8. Think big, do small: they thought globally but acted locally, a surgery, a hospital at a time.
  • Covered by some of the 125 plus Decision Areas in Decision Framework
9. Best Practices: they searched for and applied best practices.
  • Accessed through five stage Project Pre-Check process
  • All of the 125 plus Decision Areas in Decision Framework
10. Measurement: they measured the status quo and the measured the results of their changes
  • Enabled with five stage Project Pre-Check process
  • Covered by some of the 125 plus Decision Areas in Decision Framework
11. Communication: they reported their findings, before and after.
  • Enabled with five stage Project Pre-Check process
  • Covered by some of the 125 plus Decision Areas in Decision Framework
12. Prototype and pilot: they tested their checklists offline, piloted their designs, learned from their experiences and tested and piloted again until they were satisfied.
  • Covered by some of the 125 plus Decision Areas in Decision Framework
13. Local control: they adapted their solutions to suit the needs of each country, hospital and team.
  • Enabled with five stage Project Pre-Check process
  • Enabled by 125 plus Decision Areas in Decision Framework
  • Decision Framework Write-ins
14. Success breeds success: they used their successes to convert the doubters and bring on more champions.
  • It’s up to you!
15. Smart: they used checklists.
  • Tell the world about your successes!

The Project Pre-Check checklists are downloadable at no cost at

We talked about two sources of failure up front – ignorance and ineptitude. Checklists can address both. They can help stakeholders identify what they don’t know, and get assistance. They can ensure that what is known and pertinent to the change in question is identified and applied appropriately. Use Project Pre-Check’s three building blocks right up front to conquer both failure factors. Or build your own. But please, USE A CHECKLIST!

And remember, if you have a project experience, either good or bad, past or present, that you’d like to share with others and have examined through the Project Pre-Check lens, send me the details. Thanks.

Don’t forget to leave your comments below.

About the Authors

ddavisonDrew Davison is a former system development executive, the owner and principal consultant at Davison Consulting and a senior consultant at The Manta Group. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check – The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at [email protected]

rtomarRuby Tomar is an action oriented, decisive and results focused Program and Project Manager with 16years of experience in the IT systems. With three patents filed and eight disclosures to her credit, Ruby is process and technology savvy with a strong inclination towards innovation and process optimization. She has worked in automotive, consumer, networking, and telecommunications industries and is an avid reader of technical and management research. She has an MS degree in Software Systems from BITS, India and is currently working as a Program Manager at HP. She can be reached at [email protected]

From the Sponsor’s Desk – The Champion’s Dilemma

Davisons Sept25In my last post, we reviewed an executive’s response to his company’s revenue declines brought about by the financial meltdown in 2008 and the creative steps he took to deliver rapid responses to his company’s challenges.

In this post, we’ll look at the challenges experienced by a project manager who saw an opportunity to improve the organization’s performance and took it without official support. He launched a project to reduce the costs and time required to test the functionality for the consumer electronics device he and his team were supporting. It was a learning experience.

Thanks to T.R. for the details on comments on the case.

The Situation

This consumer electronics company offers hundreds of devices to consumers around the world, from bread machines to TV’s, DVD’s to power toothbrushes. Most of those devices include a variety of functions and customization options and a user interface that allows consumers to access the device functionality. Where language is a component of the interface, the company provides support for the languages in use in the markets in which the devices are sold. When a device is changed, to introduce new functionality or better performance, or to gain cost efficiencies, the core functionality and interface are invariably affected. New versions are developed and tested for each supported language, a costly and lengthy process. 

In the release in question, the project manager guided a feature team of twenty engineers who developed and adapted the functionality of the various components and interfaces on the device. That included a small team catering to component and integration testing. Another team looked after the final testing of all the devices in the product family. 

The project manager for the feature team saw an opportunity to improve testing effectiveness and turnaround time that would reduce the time and cost of getting device changes to market. Quality, cost and time to market were critical to the product’s success. The existing practices, mostly manual and very labour intensive, took almost three person years of effort for each change cycle and almost a year elapsed time to cover the languages supported by the device. 

The PM tried to interest his manager in the venture by pointing out that the six related devices in the product family all had to go through the same testing trauma. That amounted to almost 18 person years of effort for every product release. He also suggested moving to a more agile approach to improve responsiveness in place of the waterfall style practices then being used. His manager could have increased the priority and provided the necessary funding but he couldn’t be sold on the idea. The status quo ruled! 

Unfortunately, without an official sanction and the resourcing and funding to go along with it, the PM couldn’t consider available quality planning, testing and management tools on the market. Nonetheless, determined to make a difference and with the support of his team, he assigned two of his staff to try and automate some of the testing practices. Any progress they made would depend solely on the initiative, spare time and enthusiasm of the engineers on his team. 

The Goal

The project team’s goal was to reduce the effort and time required to test the device in all supported languages and produce a better quality product as a result. Because of the unofficial nature of the project, there was no formal budget or delivery target. The PM also hoped to build the skills of the engineers on his team.

The Project

The project manager and his team went to work. The challenge was to compare the expected results for all possible execution paths and all languages to the results actually presented in the component outputs and interfaces. Their first approach was to build a tool that recorded the expected results. Another set of tools captured component outputs and actual interface layouts and text. A third set of tools compared the results and generated reports identifying the differences.

The team implemented and tested their approach on one of the fifteen execution paths. These were crude tools and it took considerable time and effort to get them working to the point where results could be produced. What they discovered on the one path they tested was a worthwhile reduction in the elapsed time needed to complete a testing cycle. Unfortunately, they encountered a number of obstacles along the way, including lack of language knowledge and shifting priorities which meant they weren’t able to complete the work on time. The project was put on hold, the testing was completed the traditional way and the team members were reassigned. 

Nevertheless, the PM with thrilled with what they had been able to achieve on a shoestring budget. He reviewed the results with his manager expecting a positive reaction and, hopefully, sufficient funding and resourcing to complete the job in time for the next product release. Instead, he earned his boss’s wrath. His boss chastised him for wasting scarce resource on an unauthorized venture and setting a bad example for his team members. 

The Results 

It’s clear most of the goals of this undertaking were not achieved. Testing time was not cut. Costs were not reduced. Quality was not improved. In addition, the engineers trying to deliver the improved test practices cut corners. They didn’t start out with an overall architecture or design which resulted in considerable rework and slowed their progress. They didn’t have a risk plan of any kind. They didn’t track issues and changes effectively which impacted the interoperability of the tool sets. They didn’t fully consider their resource needs, human or technical. However, there were some learnings that, hopefully, will yield substantial returns in the years ahead. They included:

  • Get your stakeholders engaged and involved up front. That is especially true of the sponsor role, the individual that establishes the priority and provides the funding to see the project through to completion.
  • Develop the specific project goals and expectations to encompass the frames of reference for all stakeholders. Engaging the leaders of the other product teams and the test team may have helped articulate a more saleable target and overcome some of the obstacles encountered.
  • Determine your project’s impact on and involvement with the external and internal environments and the productive use of proven processes and practices to help manage scope, risk and value. A little collaboration, forethought and discipline about what you’re trying to do, how you’re going to do it, who needs to be involved and what aids are available can make a huge difference in the outcomes.

After the fact, the PM looked at the elements that he considered when launching and shaping his project against the Decision Areas included in the Project Pre-Check Decision Framework. The Decision Framework includes 125 Decision Areas that should be considered on each and every project to understand the depth and breadth of the planned undertaking and to monitor the stakeholders’ expectations and views on each one through project completion. Here’s what he found

  • Overall, of the 125 Decision Areas in the framework, his project considered 25, including things like the opportunity, goals, requirements, benefits, locations affected. Decision Areas that weren’t considered including target dates, phasing and staging opportunities (although they did actually phase their development), quality factors, assumptions, risks and sponsorship requirements.
  • Of the 125 Decision Areas included in the Framework, he identified 100 as relevant, including the 25 he did consider. That means there were 75 Decision Areas that were not considered but may have been material to his initiative. They undoubtedly would have helped him build a more compelling case, sell the stakeholders on the importance of the undertaking and see it through to completion.

It’s easy to understand why a more holistic approach wasn’t taken. When the priority of your project is uncertain and your level of funding and staffing will vary accordingly, it’s difficult to justify the time and effort to fully explore the undertaking and engage the stakeholders. Conversely, without that investment, the chances of success are substantially reduced. That’s the champion’s dilemma.

How a Great PM Will Approach This Kind of Challenge Next Time

There is no doubt this project was a learning experience for the PM and his team. They saw the low hanging fruit. They just weren’t able to harvest it. The next time this PM is presented with a similar challenge, I expect the approach will be different:

  • He will continue to look for opportunities to improve his organization’s effectiveness.
  • He will continue to challenge his team to try new things, to build new skills, to prototype and test ideas.
  • He will, however, make sure that all the stakeholders are identified, engaged and committed. When the should-be sponsor is reluctant to support an initiative, often the other stakeholders can help build a compelling case and influence the reluctant sponsor-to-be, either directly or indirectly. In other situations they can help go up the organization or around the bottleneck to secure the necessary sponsorship.
  • He’ll use the Decision Framework or something similar to ensure that the impact and influence of the project is fully understand and managed on an ongoing basis.
  • He’ll also use the Decision Framework to identify and leverage available processes and best practices and to build team skills and improve project performance.

Before you jump in and try and solve a problem or take advantage of an opportunity on your own, identify and engage your stakeholders. If you and your team are the only stakeholders, great. Go for it! But that is seldom the case. It can be a challenge selling your sponsor and targets on the significance of the venture. But that’s what champions do. They garner support, commitment, priority, funding, appropriate timing, rational dependencies and managed risks. Remember, great stakeholders make great projects! 

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be part of a Great Team. And remember to use Project Pre-Check’s three building blocks right up front so you don’t overlook those key success factors. 

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 present it for others to learn from and comment on. Thanks

Don’t forget to leave your comments below.

From the Sponsor’s Desk – If in Doubt, Pilot

In my last post, we looked at CIO’s reaction to extreme demands from an Executive VP and how a measured response and pragmatic change management resulted in a successful project and happy stakeholders all around.

In this post, we’ll review an executive’s response to his company’s revenue declines brought about by the financial meltdown in 2008. We’ll see how he relied on his customers’ feedback and used a piloting and staging strategy to reduce his risks and deliver rapid responses to his company’s challenges.

Thanks to reader A.D. for providing the details on this case.

The Situation

This mid-sized insurance organization offered life insurance to individuals across the country. Its highest volume product was a competitively priced term life insurance contract that was sold through a network of independent agents and brokers. Most of the business was monthly pay automatic bank withdrawals or cash payments.

When the financial meltdown hit, the company noticed an increase in non-payment of premiums and subsequent contract termi

nations. At the end of 2009, the termination rate was 40% above their normal rate prior to the global financial crisis. And the rate was increasing month by month. This was a serious development that threatened the company’s long term health. 

The VP Administration surveyed a number of agents and clients across the country to determine the reasons for the increase in the termination rate. He found consistent responses from both agents and clients across all regions. The increase in terminations was caused by:

  • Clients couldn’t afford the premium
  • Clients were unable to pay when due
  • Clients moved without forwarding change of address or new banking arrangements
  • Clients lacked an understanding of the value of the insurance contract

In reviewing the survey results and the feedback from agents and clients, it became clear the primary cause for the increase in termination rates was financial distress caused by the financial troubles of the time. Clients were losing jobs, making less money, forced to deal with threats of foreclosure on their homes and dealing with family members who were experiencing the same difficulties. In that environment, the premium for an insurance contract that wouldn’t yield a return perhaps for years or decades was an easy expense to cut.

The survey also asked for suggestions that would make it easier for clients to pay and keep the insurance coverage in place. The top four suggestions were:

  • Allow premium payment by credit card to provide budgeting flexibility
  • Allow the client to select the premium due date to coincide with pay dates and other automatic deposits
  • Make it easy for clients to reduce the amount of insurance coverage and the associated premium while times were tough with an option to revert to the original coverage levels when a client’s ability to pay improved.
  • Continuously reinforce the reasons the insurance was purchased in the first place – to safeguard loved ones’ standard of living in the event of the premature death of the insured.

All of these suggestions had potentially significant financial implications and required major changes to company processes and systems. The VP wasn’t ready to commit millions of dollars and months of effort to make the necessary changes until he was convinced the investment would actually solve the problem. As well, there was considerable urgency to get solutions in place expeditiously. So he consulted with his fellow executives about the challenge, the survey findings and the best way to proceed. He enlisted the key stakeholders – the CEO, the VP Distribution, the Chief Actuary, the CFO and the CIO. Together they developed an approach that would pilot likely solutions in the hardest hit regions for a short period of time using whatever combination of manual processes and technology got them up and running quickly. The approach involved the following steps:

  • Assess the financial implications of each of the four suggestions and discard any that couldn’t be justified
  • Select the four hardest hit regions
  • Benchmark the performance in each region
  • Test each of the justified suggestions, one per region
  • Monitor performance for a period of three months.
  • If the results showed promise, repeat in another region. Otherwise cancel the test.
  • If the second region showed positive results, introduce nationally. Otherwise cancel the test.
  • Initiate projects to streamline and automate support for the national rollouts.

The Goal

The stakeholders agreed to pursue the above strategy with the objective of slowing the rate of terminations to no more than 10% above the annual average experience before the financial turmoil. Two months was allocated to launch the four pilots. There was some concern that the strategy would not explore the potential complimentary or conflicting contributions of the four suggestions together if all proved financially justified and showed positive results in the pilots. However, the stakeholders agreed that urgency trumped the need for further analysis. 

The Project

The Administration VP appointed one of his managers to guide the initial phases of the project and had her supervisors pick up her responsibilities. The appointed manager had an in depth knowledge of the organization and administrative processes and systems, was well regarded by head office management at all levels, had a great rapport with the agents and a superb, can-do attitude.

She assembled a top talent team including staff from the Distribution organization, Finance, Actuarial, IT Operations, application development and legal as well as a few go-getters from the Administration ranks. She also contacted the organization representing the credit card companies and her organization’s bank to put the credit card processing arrangements and agreements in place. 

The financial folks took the four suggestions through a financial due diligence and found each could be supported if they achieved the targeted decline in the rate of terminations. The four hardest hit regions were identified, current non-payment and termination data collected, each of the suggestions assigned to one of the regions and launch plans developed. The launch plans included dialogue with the agents and selected clients in the target areas, process design including agent and client communications, staffing and training, putting in place whatever technology support could be delivered in the two month window and tracking, reporting and control processes to monitor non-payment and termination rates and ensure operational quality and integrity.

In addition to the targeted project communications, the VP Administration distributed a series of updates across the organization, to agents and brokers and in client notices about the challenging times clients were facing, the initiatives the company was pursuing, the results of the pilots and the decisions that were being made. It positioned the project as a corporate priority internally and made it easy for the project manager to secure the staff and time she needed. It also showed the organization as a caring company trying to do what was right for its clients and the agents who supported them.

The Results 

The pilots yielded some interesting results. Three of the four suggestions showed significant improvement in both the initial pilots and the subsequent pilots and were authorized for national rollout. The fourth suggestion, allowing clients to select a premium due date more in line with their financial calendars, showed no improvement and was cancelled.

The pilots for two of the three remaining suggestions were launched within the two month target window. The adoption of credit card payments took an additional month to get underway. Introduction of credit card payments was the big winner in term of reducing payment delinquency, actually improving termination rates to better than pre financial meltdown figures in both the initial and subsequent pilots.

Reinforcing the original need for the insurance coverage through revised client communications, premium notices and agent contact improved results well beyond the 10% target. Finally, providing an option for clients to temporarily reduce coverage and premiums also achieved the target although very few clients actually took advantage of the offer. It seems the offer was just another way of reinforcing the original rationale for the insurance.

The bubble gum and bailing wire arrangements for administering the pilots proved to be a challenge. Limited automated support and lack of integration with the core administrative systems meant lots of manual process work and supporting spreadsheets. On the plus side, it did give staff the opportunity to test and enhance the process design.

Two subsequent projects were launched to improve and automate the national rollouts:

  • One project provided full automated and integrated support for credit card payments. However, the card payment option was modified to offer it only on overdue premium notices and not on the initial billing. This still made the option available to the client but reduced costs considerably.
  • The second project integrated the coverage reinforcement suggestion through coordinated client and agent communications, including the offer of temporary coverage and premium reduction. Actual automation of the coverage reduction was not done because of the few clients who took advantage of it.

Within a year of conducting the initial surveys, with the full implementation of the targeted solutions, the company’s termination rate was 12% better than their pre financial meltdown experience. In addition, their new sales were up 17%, due largely to a very positive view of the organization in the eyes of both clients and agents. I guess this cloud did have a silver lining.

How a Great Team Succeeded

This project was successful for a number of reasons

  • The sponsor, the VP Administration, showed the way by exploring and promoting approaches appropriate to the urgency: engaging affected stakeholders from clients and agents to executive peers, the use of short term pilots to gauge value, confirming results in a subsequent pilot and then going national.
  • The sponsor ensured his executive colleagues were fully engaged and onside with the strategy and the execution which gave the undertaking the corporate priority and support it needed to succeed.
  • The sponsor’s selection of the project manager ensured he had a talented resource on board with the skills, capabilities, attitudes and support to do the job.
  • The stakeholders adopted a risk management plan appropriate to the need. They didn’t know how the three accepted suggestions would interact and what results that would have on the bottom line. They’d figure that out later.
  • The staged rollout, from financial justification, the first pilot, the second pilot and national rollout allowed the company to delivery quickly and learn and adjust on the go, accelerating value delivery and reducing risk.
  • The sponsor’s communication efforts embraced and informed all affected parties, no doubt making a significant contribution to the overall results.

If in doubt, Pilot! This project is a great example of how to tackle uncertainty and external threats in a series of rapid, incremental steps, guided by a rational, overall strategy. If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be part of a Great Team. And remember to use Project Pre-Check’s three building blocks right up front so you don’t overlook those key success factors.

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 present it for others to learn from and comment on.


Don’t forget to leave your comments below.

From the Sponsor’s Desk – Project Patience is a Virtue

Davison FeatureArticle July31In my last post, we looked at the damage a CEO inflicted on his organization when he failed to fully assess a vendor’s claims and refused to listen to and act on the facts when the purchased solution failed to deliver to expectations.

In this post, we’ll review a CIO’s reaction to extreme demands from an Executive VP and how a measured response and pragmatic change management effort resulted in a successful project and happy stakeholders all around. 

Thanks to reader P.A. for providing the details on this case.

The Situation

This mid-sized financial institution’s clients could pay their utility bills, department store bills, and payments to most local and national businesses through their local branches. The company, in turn, used a third party payment processor to manage the processing of the payments on behalf of their clients.

Of course, there was a cost to this service, and it was escalating. The Executive VP, Banking Operations was tired of paying in excess of $600,000 annually for the bill pay service. She contacted her company’s CIO and asked him to insource the service. And she wanted the change completed in two weeks. It seems she had had a run-in with the third party processor and wanted out of the relationship ASAP.

Fortunately, the CIO was a veteran executive who understood the challenge of change. He asked the Executive VP what was more important, doing the change quickly or doing it well, with bullet proof processes and timely service. When challenged, the VP acknowledged that quality service was the priority. 

The Goal

The Executive VP and the CIO agreed to move the bill paying service in house with quality and service at least as good as that provided by the third party. They also agreed to cap the cost of the change at $600,000 to ensure there was an economic return to the organization. If they couldn’t find a way to bring the function in house at or below that amount, they’d look at other outsourcing options. Their target time frame for the change was six months.

The Project

The VP and CIO took an initial cut at identifying the processes and functions that would be affected and the organizations that would need to be involved. The Executive VP contacted the six executives involved and asked for their support and participation in getting the job done. All affected executives agreed to support the change and participate in the project.

The CIO assigned a seasoned project leader to the job, in part to help counter the Executive VP’s still pressing need for urgency. She agreed to a six month target but everything she said and did reflected her impatience with the status quo and desire for a faster resolution.

The new PM met individually with each of the committed executives to get their views on a number of topics the PM thought pertinent to the project:

  • How to wrap up the contract with the current payment processor and the risks associated with that process
  • The new direct feed to the businesses or their banks and the associated standards, practices and controls needed to manage the exchange of information
  • The impact of the planned change on other products and services, processes and functions, interfaces to other people and systems, technology infrastructure, information needs and organization structures, roles and responsibilities.
  • Their expectations regarding project reporting and communication.

The PM also discussed the executives’ expectations around such things as organizational priorities, service level expectations, compliance with internal and external standards, security needs, audit trails, peak and average volumes and scalability of the solution.

Of the six executives involved, he found there were usually one or two who had a very good understanding of the issues and needs on a given topic. The other executives were typically vague or didn’t know. He also found that most topics were adequately addressed by at least one of the executives or their staff. There were a few critical gaps however.

The PM consolidated his finding and shared the results with the six executives, the Executive VP and the CIO in two 90 minute sessions. The reviews helped bring everybody up to speed on the key project needs, issues and assumptions. The unknowns were assigned to one of the executives to get answers and recommendations and report back.

While all this was going on, the CIO and PM met with the payment processor’s account manager to inform him of their intent to cancel the contract, ask for their help to achieve a smooth transition and confirm the legalities involved. 

Based on this feedback, the PM developed a high level plan, identified the skills he’d need and started to pull his team together. He also developed a risk plan and a communication plan and produced an initial quality strategy and a release strategy that would involve staging the project rollout by individual branches and then by region.

With his team fully assembled, the PM brought the detail estimates and schedule together and finalized the quality and release plans. The result was a target implementation in 3 ½ months at a cost of $490,000 and a staged rollout over six weeks to manage risks. After endorsement from the six executives, the Executive VP and the CIO, the project was off and running.

The Results 

The insourcing of the bill payer service was implemented in four months and fully rolled out in five months at a cost of $412,000. The quality of the delivered solution was superb. The stakeholders were thrilled. In fact, the Executive VP was so pleased, she booked a local restaurant and hosted a dinner for the PM, his team members and the other stakeholders, an unheard of occurrence. Even the account manager at the payment processor was complimentary in his comments about the effectiveness of the changeover.

This project is a great example of what can be achieved with a holistic, patient approach to managing change.

How a Great PM Succeeded

The PM was successful in part because he had a very insightful and supportive boss, the CIO. The CIO knew that the change involved a collection of competing interests that needed to be rationalized and agreed to by the affected stakeholders for the project to have any chance of success. The PM tapped into and leveraged that support to gain full stakeholder backing on all the vital questions that needed addressing to fully understand and shape the insourcing effort. In addition, the PM:

  • Developed and implemented a plan that delivered the solution a month earlier than targeted, significantly under budget while managing the risks involved. He responded to the Executive VP’s need for speed and was rewarded with her compliments and dinner for all.
  • The PM solicited the stakeholders’ views on a number of important questions that determined the final scope of the change. However, by reviewing each stakeholder’s views with the entire group and using that group as a forum to increase overall understanding, resolve differences of opinion and address gaps in their collective wisdom, he cemented their support and commitment to the project. He created a fully informed, collaborative and activist stakeholder group. When issues arose that needed their attention, their decisions were rapid and unanimous. When he needed help on staffing, his needs were met. That high performing stakeholder group was the primary reason he was able to deliver ahead of schedule and under budget.
  • In spite of the need for urgency to respond to the Executive VP’s wishes, the PM took a calm, cool and collected approach to ensure all the i’s were dotted and the t’s crossed. He engaged the payment processor’s account manager early and often to solicit co-operation and critical information about volumes, peak and low periods and processing times. By confirming his organization’s expectations on service levels, he determined that the payment cycle did not have to happen on the same day the payment was received. The stakeholders agreed to a three day window which allowed the PM to avoid incremental operating expense that would have been required to handle the peak volume periods.

Project patience is a virtue! The project was a well-planned, well run and thoroughly appreciated response to an initial, emotional executive demand. If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a Great PM. And remember to use Project Pre-Check’s three building blocks right up front so you don’t overlook the key success factors. 

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 present it for others to learn from and comment on. Thanks

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Temper CEO Passion with Discipline, and Stakeholders

In my last post, we looked at how two sponsors and their stakeholder team took a risky but potentially lucrative undertaking from inception to profitable conclusion by focusing on incremental value and delivering one step at a time.

Davison FeatureArticle June12In this post, we’ll look at the damage a CEO inflicted on his organization when he failed to fully assess a vendor’s claims and refused to listen to and act on the facts when the purchased solution failed to deliver to expectations.

Thanks to reader P.A. for providing the details on this case.

The Situation

This mid-sized general insurance company supported its core personal and commercial insurance lines on decades old mainframe applications that had been modified and added to over the years to the point where they were costly to operate, difficult to change and slow to respond to new opportunities.

The CEO of the insurance firm had a friend and former colleague who had recently joined a major software development and outsourcing firm in a senior capacity. The friend started to pitch his company’s new general insurance system. The pitch included the fact that the system was written in the latest, object oriented language and ran on open source software. The friend suggested the new system would reduce the insurance company’s ongoing operating costs, improve their ability to implement changes quickly and correctly and reduce the cost of those changes dramatically.

The CEO was swayed by the arguments and brought in the CIO and the VP’s of the two product lines to hear his friend’s pitch. The CIO saw the proposed solution as a way to get out of the legacy applications’ limitations and be able to offer shiny new technology to retain and attract new staff. The product lines VP’s saw the proposed solution as a way to increase operating profits. They all agreed it sounded great and so collaborated to recommend the project to the company’s Board. The Board approved the project.

The Goal

The proposal approved by the board positioned the vendor’s system as a turnkey solution. All required functionality would be delivered by the vendor. The insurance company was responsible for building interfaces to other corporate applications including finance, management information, human resources, etc. The proposal included net annual savings of $2 million, an estimated cost of $5 million and a project timeframe of 48 months from inception to full benefit realization for both product lines. 

The benefits would be realized from reduced hardware and operating software costs. A number of intangible benefits were identified but not quantified including faster implementation of changes, improved software quality and fewer operating problems resulting in greater productivity for administrative and operations support staff.

The Project

The CIO assigned a senior project manager to the project. The assigned PM had years of experience with the existing applications, knew the business and the key players and had reasonable success in the past although not on anything this large. The CIO expected to fill that experience gap by assigning experienced staff from the software company’s pool of PM’s.

The CIO also formed a steering committee that included himself, the two product line VP’s, the Director of Computer Operations and the head of Internal Audit. The steering committee was to meet monthly.

The assigned PM proceeded to line up staff from the two product lines to help define process requirements and test the new functionality as it was delivered. He brought a seasoned programmer analyst on board to work with the business staff and bridge to the vendor’s staff. The PM’s plan was to set up a test bed with the vendor’s software and have the business staff review functionality on a process by process basis. Gaps and differences in functional requirements would be documented and returned to the vendor to be addressed.

To get the test bed up and running, the PM approached the Director, Computer Operations to acquire and install the new hardware and operating system software and services. The PM’s request was met with total surprise. The Director claimed he didn’t have the budget, the staff or the space. It wasn’t on his priority list! A hastily called meeting with the CIO got the Director on side, reluctantly, secured the capital and expense funding, confirmed the priority and resolved the space issue.

Unfortunately, the director had little experience and minimal contacts in the open source technology space so an urgent appeal from the CIO to the application vendor yielded the necessary contacts to get the infrastructure ball rolling. However, it took three months for the necessary equipment and software to be delivered, installed, configured and made operational and to contract with the vendor for the staff with the required skills and experience.

Without the test bed to assess the functionality of the software, the PM turned to the vendor for application documentation the business staff could use to start the assessment. It took six weeks from the date of the request for an envelope to arrive. An envelope! The documentation consisted of a twenty-two page marketing brochure covering all the features, functions and capabilities the software would have. Would have! Further pushing and prodding by the PM revealed the startling truth – the system was still early in its development cycle and the core functionality for the personal line wouldn’t be finished for two years. There were no plans in place for the commercial insurance components but the vendor insisted that the plans were being worked on.

It went downhill from there!

The Results 

Instead of pulling the plug then and there, the CEO insisted that the project continue. He justified the continuation on the basis that they would have complete freedom to customize the application going forward. That was a very costly decision!

  • The first leg of the personal lines application – auto coverage – was completed for the first state four years after the project started. The last state was finally implemented four years after that.
  • The home insurance coverage component is being worked on eight years later but still not done.
  • The commercial lines functionality will probably be dropped altogether.
  • The organization is now on its third CIO and fifth project manager. The original CEO is still calling the shots.
  • Total costs to date exceed $20 million and operating costs have not only not been reduced as planned, they have grown by roughly $5 million annually to support both the new and old applications and infrastructure.

How Great Stakeholders Would Have Helped

This was a CCoCC (classic case of creeping commitment). The CEO bought a “pig in a poke”! It’s hard to imagine this kind of fiasco happening in this day and age it was so poorly conceived, so badly structured and so terribly managed. When you’re committing millions of dollars of your organization’s scarce capital to a project, you need more than an old friend’s word that things will be wonderful.

There were three factors that caused this failure:

  1. No Stakeholders

    The Line VP’s, CIO and Director, Operations had no skin in the game. The CEO called the shots. The other participants had no idea what their roles and responsibilities were. The vendor wasn’t represented in the steering committee, nor were the hardware and software vendors. And where was the Board oversight?

    Had the other participants felt some responsibility for the decisions and outcomes, there would have been push back. The Line VP’s would have seen their anticipated growth in profits turning into a black hole. The CIO and Director, Operations would have recognized the challenges from the new infrastructure and the incremental risks to their organizations. The application vendor would have understood the threat to its market credibility and future profits. Unfortunately, the CEO was left to his own devices, to tilt at windmills.

  2. No Measure of Worth

    There was absolutely no boundary on expenses, no understanding of how much the organization could afford to spend. There were no formal gates or checkpoints where progress and risks could be assessed and go/no go decisions made. The contract with the vendor was as airtight as a leaky ship. And there was no mutual buy-in to an upper limit on the contract.

    Finally, continuing in spite of the setbacks was the order of the day. “We’ve invested too much to cancel now” was the ongoing mantra. What really mattered was not what had been spent. That was water under the bridge. What counted was whether this was a good investment looking forward. It wasn’t!

  3. No Discipline

    The normal project disciplines were almost completely absent because of how the venture was positioned – bring in some new application software and move the business over to it.
    • There was no due diligence on the offering. There was no RFP/RFQ process to consider alternatives. There was no checking of customer references. Of course, there were no other customers. They were the first.
    • There was no allocation for building the new infrastructure and for the staffing and training that would be required. There was no planning or architecture to guide the building and operation of the new hardware, software, services and utilities and to manage the new relationships.
    • There was no quality plan. No nonfunctional requirements targets. There was no change control process, no risk plan and no formal issue management mechanism.

In short, this was an outrageous, costly, seat-of-the-pants undertaking that should have been stopped before it even started. Isn’t hindsight wonderful?

If you find yourself in a similar situation, and I hope you never do, put these points on your checklist of things to do so you can be a Great Leader. And remember, look at Project Pre-Check’s three building blocks right up front so you don’t overlook the key success factors. 

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 present it for others to learn from and comment on. Thanks

Don’t forget to leave your comments below.