From the Sponsor’s Desk – Projects Done Well, a Recap – Part 2
In my last post, Projects Done Well, a Recap – Part 1, we started to look at the lessons learned from the 22 case studies we’ve covered in this blog over the last two years. We covered three of the top nine contributors to project outcomes, all effecting more than half the cases studied.
In this post, we’ll look at the final six factors that most contributed to project success or failure and suggest how you can leverage these findings to improve the performance of your own projects.
Check the Part 1 post if you’d like a refresh on the methodology we used. Essentially, we analyzed the 22 cases presented in the From the Stakeholder’s Desk blog on Project Times against the 18 Factors in Project Pre-Check’s Decision Framework. The Decision Framework helps stakeholders form and deliver a common vision for a planned change from inception through completion. In Part 1, we looked at two factors in the Change domain – Stakeholders and Dimensions, and one factor in the Environment domain – Business Plan. In this post, we’ll look at three factors in the Assets domain – Resources, Delivery and Project Management and three factors in the Project domain – Planning, Control and Communication. This should shed still more light on what we can do to make projects routinely successful.
In summary, nine of the eighteen factors in the Decision Framework were identified as critical to the project outcomes in ten or more of the cases as shown in the chart. The bottom line: get your stakeholders agreeing on these factors first and your project has a much better chance of achieving its goals.
The nine factors identified here as the leading contributors have a broad impact on pretty well all business and technology projects. Pay special attention to them.
The Assets Domain
The Assets domain addresses stakeholder decisions regarding the people, processes, products, tools and facilities that are required to support a planned project or which may need changes for the project to succeed. In essence, the Assets Domain is the supply cabinet to the project world.
The Assets domain includes the following factors: resources, delivery, project management, business operations, security administration, technology operations and infrastructure. Three of those factors contributed to project success in our review: resources, delivery and project management.
The Resources factor includes seven decision areas including skills and capacity, skill development, resource procurement, contract management, team formation, performance management and succession planning.
The Resource factor was a contributor to project outcomes on 19 cases.
In The Offshoring Challenge, Part 1, the challenges of forming effective teams and ensuring the availability of required skills and capacities with an off shore software development organization were never tackled. The domestic and off shore teams never really had shared goals, objectives, processes and ground rules, there were no actions taken to address the cultural and language differences and the distance and time zone challenges were never dealt with. The final result: actual costs were double the original budget and the project was delivered nine months late.
Why is the performance management decision area a concern to stakeholders? Check out You Get What You Pay For. In that case, the two project managers were incented to meet a date. So they met the date! Unfortunately the implementation was a disaster. Nothing worked. The changes were pulled out. There was no contingency plan so the reversion to the original systems was messy and time consuming. The cost to complete the project ballooned to $70 million, 40% greater than originally forecast.
In the post Tenacity Can Achieve Miracles, the QA manager had the knowledge and skills necessary to turn around a serious quality gap that was causing a loss of customers and revenues. She was also able to tap into an available supply of QA talent to lead her teams successfully. In addition she was able to form three multi-disciplinary teams quickly and effectively using her knowledge of team building practices. She brought together small groups of staff with clear mandates, appropriate availability, the right perspectives, knowledge and skills and short term time frames to deliver a meaningful result.
Finally, Fix the Business Process First demonstrated the kind of success that can be realized when the right skills and capacity are put in place. In this case, the organization had never done an end-to-end process assessment. The sponsor contracted with an external group that had proven capabilities to assess end-to-end process performance to manage the project. That included a “boot camp” for involved executives and staff to reorient their frame of reference from organizational silos to a process view. The project was a resounding success.
Takeaway: the stakeholder group needs to have a complete understanding of the Resource factor decision areas relative to the project needs and be fully on side with that view and any plans to address the gaps.
The Delivery factor addresses the processes that are in place and can be used or adapted to develop and implement the target solutions. The Delivery factor includes the following decision areas: management of change, software delivery, technology change, quality assurance, prototyping, partitioning, time boxing, reuse and project close.
The Delivery factor had a material impact in 11 of the 22 cases.
An example of a project that paid the price for not addressing the Delivery factor was presented in the post Managing IT Services Contractors. The project was delivered successfully, but five months late and sixty percent over the original estimate. The vast majority of the overrun came from the contractors’ failure to deliver. Key contributors to that failure were the lack of technology change and QA processes that the participants could use as a road map for managing the change. That contributed to numerous disconnects between the project team and the contractors on key fundamentals including roles and responsibilities and the quality practices and a plan to deliver to those expectations.
In Knowing Your Project Profile, the project ultimately delivered a significantly better return than originally anticipated but the two project managers ended up as goats. They adapted the in house quality practices ensuring a high quality solution in all respects. They used prototyping effectively to understand the business requirements. Unfortunately, they didn’t address the incremental functionality that was added to the scope resulting in higher costs and more time. That surprised the other stakeholders. They also missed an opportunity to partition the project into phases to accelerate benefit delivery and reduce risks. If the PM’s had considered the Delivery factor decision areas up front, they might have been heroes.
Takeaway: it’s imperative that the stakeholders have a discussion on the processes and practices that will be used to deliver the solution and are in agreement on the decisions reached. This factor is often seen as the exclusive responsibility of the PM but keeping it to oneself is a mistake. The more the other stakeholders understand the choices and agree on the direction chosen, the greater the overall commitment.
The Project Management factor covers those practices and guidelines that PM’s can use off the shelf or amend as appropriate to guide their projects. The Project Management factor includes the following decision areas: the project management process, organization profiles, estimating guidance, project tracking and reporting templates, requirements management frameworks and standard practices on risk management, issue management, change control, defect tracking and gating.
The Project Management factor was a material contributor to the success of 11 of the 21 cases.
In the post Anybody Can Manage a Project, Part 2, we saw how a new hire with a financial background and no prior project management experience was able to deliver a global project successfully with accolades from all the stakeholders involved. Part of her success was due to the use of in place processes and templates to guide her actions, including the standard reporting templates which she tweaked to address her sponsor’s needs. She also obtained stakeholder agreement on the risk management, issue and change control practices to be used on the project.
In the post Anybody Can Manage a Project, Part 1, the individual assigned to manage the project had no prior project management experience either. However, in her case, she didn’t have the benefit of stakeholder discussions regarding the project management process to use, how to estimate the work, manage requirements, track and report progress, manage risks, issues, changes, etc., nor did she take advantage of materials or expertise within the organization that could have helped. A new project manager was finally assigned and the project was delivered for almost twice the original budget, nine months late.
Takeaway: all stakeholders need to be engaged in a project on a regular basis, certainly weekly, often daily. They need to know how the work will be planned and managed, who the players are and what their responsibilities are, how they’ll be involved and the basis of that involvement. This factor is also often seen as the exclusive concern of the PM but that’s unwise. Stakeholders who understand the choices and agree on the direction chosen will be more committed and more effective.
The Project Domain
The Project domain addresses the specific project decisions that need to be made to shape and deliver changes that achieve the organizations goals. These decisions deal with how to deliver to the stakeholder expectations articulated through the decisions made in the other domains. The Project domain includes four factors: planning, organization, control and communication. Three of the factors – planning, control and communication – were among the top nine factors contributing to project success.
The Planning factor takes the relevant decision areas addressed in the Assets domain and applies them to the unique needs of the project. Huh??? OK, an example: if the stakeholders agree that they don’t have the right skills, or enough of the skills required when considering the Resources factor in the Assets domain, then the plans to address that gap are included under the Planning factor. It covers the following decision areas: business alternatives, technology alternatives, release plans, cost estimates, benefit plan, quality plan, resources and facilities plan, contracts plan, communication plan and risk plan.
The Planning factor was a contributor to project success in 13 of the 22 cases.
The Power of Teams post shows the positive results that can be achieved by building a resource plan that addresses the critical skill and capacity needs. As well, the project developed and managed a comprehensive risk plan that was used to guide the project around and over the many obstacles that arose. The project implemented successfully just prior to the yearend freeze, twelve and a half months after launch. The actual cost was slightly under budget and the quality of the delivered software, processes and services was outstanding.
On the downside, The Offshoring Challenge, Part 1 shows what happens when the Planning factor decision areas are ignored. Identification of possible risks and development of a mitigation plan is a prerequisite for just about every successful major change undertaking. Had that been done in this case, chances are the risks relating to quality, communication, team performance and expertise and other factors would have been addressed. In addition, there were no plans to manage the vendor contract, the quality of the delivered products, skills and capacity issues and guide the communication with the stakeholders. The final result: actual costs were double the original $7 million budget and the project was delivered months late.
Takeaway: exposing the Planning factor decision areas to the other stakeholders and asking them for their thoughts on each item can be intimidating. Early on, the majority of response will be, more often than not, “I don’t know”. However, as the project progresses and positions and proposals are developed, the dialogue will increase and stakeholder collaboration will evolve to mutual understanding and, finally, agreement. How powerful is that! Take advantage of it – a process to gain stakeholder agreement and cement their engagement at the same time.
The Control factor includes those control mechanisms that help stakeholders shape and guide the project to achieve the objectives of the planned change. It includes the following decision areas: release plan performance, contracts plan performance, risk plan performance, team plan performance, change tracking and reporting, issue tracking and reporting, and project completion.
The Control factor was a material influence in the success of 13 of the 22 cases.
The post A Perfect Project highlights the value of mastering the Control factor. In this case the PM clarified and quantified the project’s goals and measured project performance against those goals on an ongoing basis. She developed and managed a risk plan that resulted in some pragmatic changes in approach to improve quality and value and she controlled the development of the application through a number of phases and rolled out in stages to reduce risk and accelerate business value. The project was hugely successful. It delivered on plan and within budget and the high quality of the implementation was confirmed by the standing ovations the PM received as she travelled across the country introducing the new environment. It also won the Conference Board of Canada’s ITX award for technology innovation and excellence. The ROI calculated by the judging committee was about 800%.
In the post You Get What You Pay For, the entire organization was surprised when the $20 million first release was a disaster that had to be pulled from production. Aside from the fact there was no formal stakeholder group to guide the way and monitor progress, the two PM’s didn’t use effective controls on risks, quality, issues, changes or team performance. In fact, the product from the selected vendor had two major deficiencies – their systems needed major modifications to handle individual pension records across organizations and they had never co-sourced a solution before. The latter fact did not come to light until the first phase implementation failed.
On a positive note, the project highlighted in Ten Winning Project Management Practices implemented and applied control practices effectively throughout the initiative. From a financial point of view, good planning and good controls were in place. The nursing units had a positive experience with the ‘Last Call Walk Through’ process, which provided an opportunity to provide quick fixes and quick wins. The biweekly status meetings with stakeholders and the monthly milestone summary sheets were very helpful. The project was deemed a highly successful undertaking by all stakeholders and provided the learnings and foundation for Digital Imaging rollouts to the other hospitals in the region.
Takeaway: over the course of a project, stakeholders will encounter many variances between the plan and actual results and will have numerous decisions to make. The Control factor is the catalyst for those decisions. It is the compass that tells the team where it’s headed. As Yogi Berra once said “If you don’t know where you are going, you will wind up somewhere else.”
The Communication factor deals with the ongoing practices and decisions that will ensure all participants in the change are fully involved and informed in a timely manner concerning the progress of the project. Sponsors, change agents, targets and champions all have a stake in the success of the project and therefore have a significant interest in the Communication factor and the two decision areas, monitor updates and monitor feedback.
Communication isn’t just about sending out periodic status reports. It’s about fostering a multi-way dialogue, ensuring stakeholders get what they need, in the format and medium they need, in a suitable time frame.
The Communication factor was instrumental in the success or failure of 20 of the 22 cases.
A good example of a project that covered the Communication factor with aplomb is the previously mentioned Ten Winning Project Management Practices post. The strength of the project, and a major contributor to its success, was communications, including:
- The regional bulletin, a key communiqué to those in the field.
- The community sites had direct ownership of the communication plan at their site.
- The stakeholder and target audience analysis laid the foundation for getting the details on identifying all the training targets.
- Different strategies worked at each site, according to their needs.
- The Leadership forum (regular monthly meetings of the Diagnostic Imaging Managers) worked well to promote agreement and standardization across the regions.
- The eRoom provided a central online repository for the current and archived documents, readily accessible to all project team members.
Another example of the power of a well-managed Communication factor is the project reviewed in the post Speaking Truth to Power. The new contract PM assumed responsibility for a project due to be delivered in nine months. The project reported a Green status – everything going according to plan – from its inception. He found that there was no believable plan in place, no risk plan, incomplete testing and acceptance plans and inadequate resourcing. In short, there was absolutely no justification for a Green status.
At the end of his first week on the job, the contract PM filed his first status report, with a status of RED. That colour would grace all the status reports for the following ten weeks. That got the stakeholders’ attention and earned him a good deal of stakeholder wrath. Gradually, he was able to get them to agree on project scope, develop a comprehensive plan to deliver on target, get the right resources and, after almost three months on the job, report his first Green status. He also adopted a project reporting scheme that objectively determined the status colour and ensured the stakeholders were on side with the criteria used. That took some executive heat off him in the second and third months and encouraged the decision makers to focus on the issues rather than his judgment.
As the ultimate testimony to his achievement, his project was the only one of the nine initiatives in the program to deliver on plan!
Takeaway: you can do a wonderful job getting the stakeholders engaged, project dimensions agreed to, the right assets lined up, the relationship of the project to the broader business plan clarified, a comprehensive plan and resources in place but if you don’t manage the Communication factor, your project will probably fail. The Communication factor is the glue that holds everything else together. It’s a force multiplier!
The Way Forward
A number of organizations and individuals have researched project performance over the years to identify the magic formula for project success. The table below shows a sample of the findings on the top eight factors contributing to success or failure. The Standish Chaos studies have been running since 1994. Professor Ryan Nelson of the University of Virginia has been studying project performance results over a number of years and identified the top reasons for failure garnered from 99 project reviews. He’s not alone in his findings. The results are very close to the successes and failures we’ve uncovered above and in the previous post when we looked at our 22 case studies as summarized in the Project Times column below.
You will notice that the top nine Project Pre-Check factors we’ve looked at in this two post recap address each of the success factors from a number of different perspectives. There are also nine more factors in Project Pre-Check that we haven’t covered that add additional diligence to the project experience. Effective stakeholder management ensures that all factors with the potential to impact project success are addressed and monitored collaboratively and consensually.
So, you have a choice, as a sponsor, change agent, target or champion. Proceed according to these findings and your projects will be much more successful and the experience will be a rewarding one. Ignore these findings and join the ranks of stakeholders who were too busy to learn from the experience of others. More often than not, their projects failed. That’s why Project Pre-Check is a great place to start your project. It supplies a terrific best practice based framework for building an effective guiding coalition that will be there when conflicts and crises arise to ensure your projects are done well.
In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.
Don’t forget to leave your comments below.