In my last post, Projects Done Well, a Recap – Part 1, we started to look at the lessons learned from the case studies we’ve covered in this blog over the last little while. We covered three of the top nine contributors to project outcomes, all effecting more than half the cases studied. Projects done well.
In this post, we’ll look at the next three 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 this blog 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. 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 covers 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. The incentives for the two PM’s should have addressed the other things that were important to the organization, such as quality, stakeholder buy in and value delivered.
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 have used 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: key 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 Way Forward
Part 1 of this series of posts focused on two factors in the Change Domain and one factor in the Environment domain that had a material impact on a sizeable number of cases covered in this blog. In this post, Part 2, we have covered three factors in the Assets domain that had a significant influence on a number of our cases. Project stakeholders need to address these key factors and the decision areas within them right up front to ensure a successful project.
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.
Drew Davison is the owner and principal consultant at Davison Consulting. 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 firstname.lastname@example.org.