Skip to main content

Tag: Stakeholder

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 projectprecheck.com.

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]

Lessons Learned on Jury Duty Part 1 – Why Do We Have To Wait So Long?!

The reality of a jury trial is different from what we see on TV or read in books, where the action moves quickly towards the acquittal or conviction of the defendant. On TV the opening arguments, the witness interrogation, and the closing arguments are all pertinent and exciting. Of course, on TV and in books trials are filled with action, with both sides winning points, stumbling, and articulating coherent and often poignant arguments. Oh, the fast-paced drama of it all.

So when I was summoned for jury duty, my expectation was that while there might be some down time waiting to be selected for a jury panel, once picked, things would move along quickly. Reality, not surprisingly, proved quite different. Perhaps some trials are filled with drama, interesting cross-examinations, and surprise endings. But my experience as a jury panelist was, for the most part, all about waiting.

What business analysis and project management lessons, then, can we learn from waiting? Here is the first one—remember that our stakeholders are waiting, too. Years ago the sponsor of a large project I managed handed me a Dilbert cartoon, the gist of which was that the less we know about something, the less amount of time we expect its development to take. My sponsor was telling me that he recognized the trap he was falling into–that because he did not understand the complexities of software development, he couldn’t imagine how it could take so long to develop the new application.

During jury duty, after 36 of us had been selected as potential jurors for a criminal trial, we were escorted outside the assigned courtroom to wait until we were called. Someone verbalized his frustration with the process. “What a waste of our time,” he complained. “No doubt the judge is having a martini lunch,” and so on. When we were finally seated in the courtroom, the judge explained the rules we were to follow and immediately dismissed us for a 25 minute break. The person who seemed frustrated before became infuriated. He poured out invective against all lawyers, court clerks, court officials, and public servants. It seemed to me, though, that there were several possibilities for the delay. None of us potential jurors knew what was happening behind the scenes, but that did not mean that there was no activity. It simply meant that we were unaware of what those activities were.

Most stakeholders don’t understand our processes and how long it takes to develop the end solution. After meeting with a business analyst or project manager, our stakeholders are often left to wait. We do our business analysis or project management work while they wait. We’re busy. The development team is busy. The product owner, if there is one, is busy. But the end users, having no idea of the complexities we face, just might be wondering what we’re doing and why they can’t have their end product sooner.
I worked on a project with a full-time product owner assigned, a retail buyer who was lent to us for the duration of the project. After spending a week collocated with us, she exclaimed, “I wish all the buyers could spend time in IT. I had no idea things were so complex! No amount of training in being a BA or PM could have prepared me for how much work is involved in getting the requirements and developing the system. I’m beginning to understand why things take so long.

Without training our SMEs or product owners to actually be business analysts or project managers, what can we do? One thing we might try is to offer our stakeholders the opportunity to spend time in our work areas. Offer them the chance to observe us. Throughout my career, both as a BA and a PM, I have learned invaluable information when I have been able to observe stakeholders working in their areas. Observation has provided an opportunity to better know some of my stakeholders. It has been a way not only to build trust, but get information I could not obtain in any other way. It’s been a chance to learn about work-arounds, as well as issues and frustrations end-users encounter with their systems. It’s one of the best ways I know to build trust while learning about the “as-is.”

When stakeholders spend time with us, observing us while we do our work, they have an opportunity to get a glimpse of our work from another perspective. The wider their understanding and the more complexities they observe, the greater their patience and acceptance are apt to be. By providing them an opportunity to attend all the non-elicitation meetings, to be present when we develop/review data, process, and use case models, to listen as we interact with and answer questions from other team members like the project manager and the technical people, we are providing a viewpoint that few people outside the development team have, and it’s a glorious way to build understanding and trust. So the lesson learned is the importance of trying to empathize with our stakeholders’ likely frustration with the waiting involved in their projects. Stay tuned for the next blog in which I will discuss the second lesson I learned from jury duty, the importance of communicating the whole project scope.

Don’t forget to leave your comments below.

Mitigating Risk and Leveraging Luck

Deservedly so, project management’s success has been defined in large measure by the project team’s procedural structures, sound executable actions, risk mitigation activities, and the like. An alternate view suggests there are forces at work at the margins that are prominent in delivering project success; namely, the combination of skill and luck.

A couple of basic assumptions are in order prior to discussing how skill and luck play out. Firstly, at the level most of us practice our profession, it is reasonable to assert the skills of the various stakeholders are technically and organizationally proficient. Secondly, we could view project complexity as an S-curve with simple/straight forward projects at the bottom left and highly complex initiatives ascending to the top right hand corner.

Skill + Luck

Assuming the project skill levels and complexity are sufficiently high, emphasis on process or procedural improvement may yield a negligible incremental benefit. What may be needed (as we move up the project complexity S-curve) is luck. An analogy to any (professional) championship game will see two highly proficient teams/players with the winner, more times than not, is defined by luck.

Luck, in the project management context, can be considered via two components:

  1. Diversity of Ideas
  2. Heuristics

What typically occurs is our project planning evolves from the perspective of the expert’s ‘position’; thereafter, project planning really becomes a puzzle-fitting scheduling matrix around the expert’s position. Invariably, this may run counter to reducing the collective error that often seems to surface when (complex) projects get off course. 

One of the paradoxical (yet common) behavioral characteristics of engaging with large groups is the greater the number of collectively consulted stakeholders, the more likely project team members will default to their own self-interest (i.e., a cost to the project) vs. the benefits (i.e., efficiency and exploring risk opportunities). In short, talking it through too much with too many people won’t necessarily help.

There are two ways of reducing the collective error and (ultimately) increasing luck. Firstly, the project manager has to harvest a greater diversity of ideas, particularly from the core project team members, to provide a richer solutions’ platform. This will increase the average divergence of the solutioning possibilities.

Secondly, the broader distribution or diversity of ideas that will eventually be discovered will actually decrease the collective error. The improved accuracy is the simple result from the project team’s taking into account the larger population of variations and collectively focusing in on the best approach or plan. 

Summary

At the project management margins, it is incumbent upon the project manager to regulate the amount of solutioning from stakeholders, increase the participation of the core project team as well as increasing the diversity of ideas. This is how the project team is likely to become lucky. As to where the project manager draws the lines as to where these variables conclude is a question of the project manager’s management skill. Stated differently, how the project manager and team go heuristically harnessing this potential is a chief heuristic differentiator between project success and mediocrity with regards to complex projects.

Don’t forget to leave your comments below.

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.

Guidance for Good Project Governance

bondale Sept11Behind every successful project is an effective governance process. On smaller projects, this governance may be primarily driven by the efforts of the project sponsor and project manager, but on larger, more complex projects you may need to have multiple governance teams and processes to properly guide and support the project.

For those of you who have not experienced the pain of managing a project that is lacking appropriate governance, here are just a few of the issues which might be encountered:

  • Inability to secure the committed allocation of required financial and people resources to deliver the project scope on time
  • Inability to get those issues, actions and risks addressed which have been escalated beyond the authority level of the project team
  • Protracted delays, excessive effort and staff frustration in getting key decisions made or, even worse, wasted effort and schedule impacts resulting from reversed or modified decisions
  • Lack of buy-in from key stakeholders
  • Insufficient visibility of the project’s importance at executive levels to secure sustained funding and perceived priority

If poor governance can be the cause of such lethal project impacts, wouldn’t you expect to see significant emphasis placed on this critical step?

Reviewing the track sessions for four conferences being held this year across Canada, I was only able to locate one session which specifically referenced governance in its title – while it is likely that a few more also related to subject, having attended a few of the track sessions in the Toronto conference, my experience was that this was not one of the most commonly referenced topics. This is not a criticism of that particular conference – having attended multiple project management conferences across North America over the past fifteen years, I can’t recall one where governance was a focal topic.

Furthermore, over the course of the project management capability improvement work I’ve done with companies, I’ve found that those which include a mandatory “Proposed Governance Structure” section within their project plan templates have usually done so because of lessons they have learned through the school of hard (project) knocks.

It would be impossible to provide a comprehensive guide for defining the right governance structure and process which will meet the needs of all projects as, just as with any other project management practices, these need to be tailored to the specific needs of each project and the culture of the organization in which they are being implemented.

Here are some tips to get you started:

  1. While project complexity as a whole drives the need for greater governance, the following specific factors should be evaluated to assess the extent of governance required:
    1. Degree of organization impact – the bigger the change to the organization, the more robust the governance required
    2. Number of key, influential stakeholders who have or are likely to have significantly differing agendas – the greater the likelihood of divergence of opinion on project direction and decisions, the more effort will need to be spent on governance
  2. If multiple governance bodies are being considered, make sure that there is a clear definition of the jurisdictional boundaries of each. Without this, you run the risk of getting a frustrated or disengaged sponsor who sees their decisions being overturned or questioned frequently. This also applies to standing governance committees within your organization – your proposed governance structures need to align with those as well.
  3. If you are considering a multi-sponsor model for projects where no single sponsor is capable of or will be perceived to be providing a balanced level of governance, remember that with two or more sponsors, you will need to budget some of your time to facilitating their transition through Tuckman’s standard team development phases. You will also need to budget for the additional effort and costs of having multiple executives directly engaged with your project. Finally, you should prepare yourself for the likelihood of conflict and churn across your team resulting from individual sponsors making decisions without fully consulting their co-sponsors.
  4. Establish clear terms of reference for each governance body detailing the types and level of activities each is responsible for as well as the overall mandate of the group. This process should start with how these bodies are named as an advisory group may be perceived to serve a very different purpose from a steering committee.
  5. Balance the desired project benefits against the administrative costs, effort & potential delays of having an overly onerous governance process. The more gates that a particular decision or action has to pass, the greater the project costs and potential for delays. After a leadership team has experienced issues of inadequate governance on one project, their tendency may be to overcompensate on the next.

The outcome will usually not improve, and governance practices will oscillate from minimal to excessive.

Establishing the right governance structure and process is like the tale of Goldilocks – missing the mark could be “un-bearable”!

Don’t forget to leave your comments below.