The scope crept, the risks leapt!
Or "where did I go wrong???"
Everything is under control. The initiation of the project went smoothly. The SWOT (strengths, weaknesses, opportunities, and threats) analysis was complete. The project plan came together without a hitch and the execution of the project began.
All of a sudden the sponsor came up with additional features that needed to be added to the project. Also, some of the project team members, unbeknownst to the project manager, decided to engage in “gold plating” their assigned tasks. Upper management decided that the project was not aligned properly with the mission and goals of the company and needed to be adjusted.
Many project managers are faced with changes being made midstream in the project. The changes may add cost, delay the project or impact on the quality of the deliverables. Or all three or a combination of the three may occur!
What actions may a project manager take to bring the project back in line without risking triple constraint issues as well as impact on the reputations of all involved? This paper shows various tried and true techniques and “best practices” that a project manager may use to bring the project to a successful completion.
In the movie The Producers (Brooks, 1968), which starred Zero Mostel as has-been Broadway producer Max Bialystock and Gene Wilder as his accountant, Leo Bloom, the characters came up with a scheme to make a fortune by producing a Broadway play that will be “a sure-fire flop.” To achieve their goals on this project, the two secure the rights to a tasteless play, hire an inept director and actors and top it all off, attempt to bribe the press for a positive play review! In spite of these machinations, the play becomes the smash hit of the theatrical season! Max sums up the result by saying, “Where did I go right!?!”
Project managers on the other hand say, “Where did I go wrong?” when their project is failing, even though they've done everything “right.” For example, the project manager is using A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute, 2008) for guidance, thoroughly vetting the project with the project sponsor, team, and stakeholders, as well as aligning the project with the organizations mission and goals. Yet midway through, the project manager finds the schedule slipping, the budget has been exhausted, and the scope has expanded to the point where the original plan does not have much in common with the current project!
In both of these scenarios, the common thread is that a project plan, no matter how well-conceived can fail! One needs to be realistic in that even when everything is done “by the book” there is still a possibility of the project going off course, usually due to scope creep. And in many cases, the project isn't cancelled; instead it still has to be completed and there is more to do!
Subtle changes, small miscalculations, and mind changing can affect any project during the execution phase. These modifications, unseen at first, will come to the forefront quickly for the project manager and team to deal with.
What this result underscores is that the skills and techniques expressed in the rational view of project management, regardless of how aggressively they are pursued, may be insufficient to assure project success. If indeed, as suggested by the literature, systematic biases are common in the human decision-making process, then there are fundamental reasons why project failure should not be an unexpected result. (Shore, 2008, p. 13)
When the Scope Creeps
In sum, scope-creep can mean that big risks go with the big benefits of an expanded job. Be sure to spell out warnings that may not have been applicable to the original job. The moment you hear your owner wants you to do more, much more, take a deep breath and retrieve your file with the engagement letter. (Herrmann, 2012, p. 29)
At first, scope creep may be looked upon as a positive in that the sponsor is engaged and wants to contribute to the success of the project. Or it could be a quality issue where the client wants to change something to make the product of the project “value-added.” Or one of the team members has come up with a “better way” to solve a problem that will, in the short run; cost more and take more time but in the long term bring the project in under budget and ahead of time.
But taking a second look at what has transpired may uncover problems that simply were not anticipated in the original project charter or any of the subsequent documents of the project plan. It could be that the project needed to be treated as a case of “progressive elaboration” where it would be assumed that more relevant information would be uncovered as time went along. Or perhaps the project manager, sponsor, and team were caught in “going through the motions” of project management because they had been on other projects together. The explanations of why the scope crept and therefore the risks leapt can be infinite; but in order to rectify a failing project, there has to be a consensus on what happened and how to move forward.
So let's back up a moment, what can we do besides accepting defeat? What is the first thing we, as project management professionals, can do to move the project forward even though something has obviously gone wrong?
Do you have a checklist? Sounds simple, but many project managers rely on past experiences, “gut feelings,” and other things to find a solution. But a simple checklist can work wonders to jog one's mind on possibilities that need to be attended to. Stal-Le Cardinal and Marle (2006, p. 228) suggest a very broad look at how the project fits into the organization:
- The company's corporate strategy;
- Historic and standards: global or specific to the company;
- Initial resources available in the company: human resources, skills, knowledge, material resources, and money; and
- Constraints and assumptions.
Whereas Atkinson, Crawford, and Ward (2006, p. 688) came up with these possibilities from the “Rethinking Project Management Network” series of meetings:
- lack of a clear specification of what is required;
- novelty, or lack of experience of this particular activity;
- complexity in terms of the number of influencing factors and associated inter-dependencies;
- limited analysis of the processes involved in the activity;
- possible occurrence of particular events or conditions which might affect the activity;
- emerging factors unknowable at the start of the project; and
- bias exhibited by estimators, typically optimism bias.
In essence a project triage needs to be created to avoid inevitable risks that will occur if action is not taken in a reasonable amount of time. Moving from a very broad list of issues to specific ones will need a collaborative mindset amongst the project manager, sponsor, team members, and stakeholders (Figure 1), as well as loosening up on the rigidity of the original project plan.
Figure 1: Moving the Troubled Project Forward
In uncertain environments, when the goals and tasks are not fully defined, it is best to avoid a highly structured and tightly controlled project team structure. Maintaining a loose organizational structure with significant flexibility is even more important in dynamic situations where tasks are not only ill-defined, but also change and evolve over time. (Nogueira & Raz, 2006, p. 8)
Clearly an approach has to be developed to move the project forward. Organizations that are moving into new product development or have little project management experience may accept the above path forward because it is straight-forward (Look from the top down, look for specific issues, and bring the team together to consider alternatives.) but there are organizations that have processes or have experienced “lessons learned” and may fall back on what has worked in the past (Figure 2).
Figure 2: New vs. Mature Project Organization Response to Failed Project
Back to Basics
If the project is taking on new challenges beyond the scope of the current agreed to charter and scope statement, then it might be best to move that change to another project. In other words, either a new version of the product or a follow-up project to implement the additional work and resources. This would save the current team the added work and it may be found that the additional changes could be defined as “nice to have” instead of being strategic to the project in the first place.
Bear in mind that depending on the project there may be no options except to move forward. If the project is strategic for the organization, it will need to be completed no matter how it started or what state it is in.
“Projects linked to client requirements or key business or governmental strategies, for example, will carry on - no matter what.” (Gale, 2010a, p. 30)
Institute a change control board. But be clear on who should serve on the board and the roles and responsibilities of the members of the board. A simple best practice would be to make sure the board has an odd number of members so that one of the members may serve as the tie breaker or perhaps have an even number of members and then have the project sponsor serve as the tie breaker if there is no consensus. And make sure the project manager is one of the members of the board.
Explain and show the ramifications of the scope creep and the associated risks to the sponsor and upper management. Assuming that the organization has had experiences of this type it should be straight-forward on what will happen if the project scope is not brought under control. The additional positive affect would be that this conversation spurs additional solutions to bringing the scope under control and avoiding subsequent risks.
Bottom-line thinking is a part of this discussion as well. Rarely is scope creep mentioned without cost and schedule being part of the conversation. This can add to the urgency of coming up with a solution as well as bring a clear understanding of what tasks need attention in the immediate future to avoid additional monies being spent or the project dragging on.
Revisit the team contract with team members. Reiterate what was agreed to and who is responsible for what tasks. Although the project manager needs to stress that this is a review and not a search for those guilty of changing the scope of the project through “gold plating” or by other means. In addition, it will reaffirm what needs to be done and answer any lingering questions on what needs and what does not need to be done.
Review the project charter with the sponsor. There may be points of misunderstanding or issues that need to be resolved at this point in the project. If possible, this may be a two-step process where the project manager and the sponsor meet and then report their findings to the team for review. This could show that what the sponsor and project manager felt were the main goals of the project are not matching up with the team members. This could be repeated with the end user as well to make sure that their expectations and needs are being met (Figure 3).
Figure 3: Reviewing Documents, Strategy, and Scope with Stakeholders
The project manager must understand that reviewing documents and having frank conversations with stakeholders will not always move the project forward nor mitigate risks. However by engaging these different groups a path forward that had not been thought of before may be realized and utilized by the project manager (Figure 4).
Figure 4: Engaging the Project Community
One of the consistent and most striking findings from this field study is the need for increased involvement from all project stakeholders—both within the organization and among the external partners. (Thamhain, 2004, p. 45)
Understanding what happened and how to remedy the situation starts with making a deep dive into how the project had been defined in relation to the organization. At this point, this is an assessment phase that makes no determination on who may have brought the project off course.
When Mr. Vincent is brought in to rescue projects, he begins by helping the team define the objective, even if the project is already in the works. He also talks to key people on the team, identifies stakeholders and reviews project documents before making any assumptions about what—or who—caused the problems in the first place. (Gale, 2010a, p. 32)
Helm and Remington (2005, p. 57) suggest that a successful relationship between a project manager and an executive sponsor should have the following traits:
- Appropriate seniority and power within the organization;
- Political knowledge of the organization and political savvy;
- Ability and willingness to make connections between project and organization;
- Courage and willingness to battle with others in the organization on behalf of the project;
- Ability to motivate the team to deliver the vision and provide ad hoc support to the project team;
- Willingness to partner with the project manager and project team;
- Excellent communication skills;
- Personal compatibility with other key players; and
- Ability and willingness to provide objectivity and challenge the project manager.
All of these traits are intertwined with each other. For example, even though the manager may have the seniority and power to move the organization doesn't necessarily mean that they'll support the project or project manager. Clearly, the project manager needs to be able to relate what has gone wrong, what needs to be done, and ask if the executive has additional insights that may alleviate the scope creep and avoid future risks.
The project manager needs to be cognizant of the executive's viewpoint on the project as it relates to the whole organization. Also the project manager needs to be able to put themselves in the manager's shoes in order to understand how all the pieces fit together.
However, based on the interviews conducted, it is evident that if project sponsors are actively engaged throughout the project process, the relationship with the project manager becomes a key focus area. (Sewchurran & Barron, 2008, p. S67)
Engagement is a positive event because the sponsor is then up-to-date on the proceedings of the project. Also the sponsor is clear on what the objectives are and how they have changed as the project has moved on. However, it can become problematic if the sponsor becomes too engaged because then the project manager and the sponsor may find themselves at odds on how the project is being run.
Team members and subject matter experts are another place a project manager may seek solutions to project scope creep. Pavlak (2004, p. 13) suggests using Tiger Teams: “Tiger Teams are intensely managed small groups of selected experts. Their core performance comes from open and honest dialog, productive conflict, and the struggle to fit the problem pieces together to produce a unified whole.”
These can be members of the original team or new members to give a fresh viewpoint on the project. The idea behind this is that these teams can quickly determine what went wrong, what needs to be done, and the way forward. The challenge is, like an executive or a sponsor; to have the right people on the right team having a clear task to work on. The project manager may have to take time to interview team candidates in order to determine the right tiger team mix.
Customers can add information or clarity as well to the process of discovering issues and coming up with solutions. As aforementioned, clearly recounting what the scope of the project is and what features are “must haves,” “good to have,” and “nice to have” can clear the way to what exactly needs to be done to complete the project (Figure 5).
Figure 5: Stakeholder Scope Feedbacks
Concentrating on the “must haves” will get the job done. If there's time for the “good to haves” then so much the better for the customer. The “nice to haves” may be removed or considered for future projects. Acceptance testing of the product of the project will help make sure that the project's goals are met and the customer is satisfied with the results.
Bringing it all together, using the skill sets, knowledge, and experience of all the people involved in the project will bring more possibilities for alignment with the mission and goals of the organization as well as add to the satisfaction of the results by all parties. This of course isn't the easiest thing for the project manager to accomplish since it has to do with multiple groups that have varying perspectives on what needs to be done, different viewpoints on how this will or will not add value to the organization's bottom line and whether the project will be successful overall.
The use of computer technologies will help uncover issues, connect stakeholders, and establish better project communications with the result of better transparency for the organization. However, if these technologies haven't been employed since the start of the project, the project manager will have to decide if the organization can supply the services, or if the services should be contracted or can it be supplied virtually from “The Cloud”? And of course, is the skill sets of the project stakeholders up to the level of using the technology or will there have to be training?
The project manager, by using software simulations, scheduling applications, modeling programs, or simple number crunching algorithms will add insights into the causes of scope creep as well as assist in reversing or mitigating it to move forward. Even if these applications were used from the beginning to build the project schedule, strike a baseline, and monitor what transpired there may be additional features to be used to mitigate scope creep and risks. Usually a user of an application learns only enough about the program to do the job at hand, no more, no less. By bringing in an outside consultant or trainer, additional features may be learned to solve problems.
Figure 6: Using Technology
Connecting stakeholders to each other is another possibility with computer technology. It is very hard to imagine running a project today without simple tools such as email, word-processing or project scheduling tools. But being able to have the information at the sponsor's, teams, and customer's fingertips can add to interactions as well as communications thus adding to project transparency. An Intranet website or organizational portal may be a solution to connect every stakeholder on the project. Being able to have a document repository, announcement pages and discussion areas are the minimum tools needed to encourage collaboration. There are specific tools that may accomplish this and depending on security needs or the organization's guidelines, they may or may not be opened up to users outside of the organization.
Using established Cloud applications have the advantage of already being up and running so that the project manager may setup up the software tool quickly (or the project manager may not have to set up anything!). This may include Microsoft Office tools from various vendors that have been adapted to the Cloud which team members, sponsor, and stakeholders are familiar with. Another possibility is to leverage establish social media to augment communications among the stakeholders. There must be though, agreement that using these tools will not affect the security or integrity of the organization's personnel or assets.
Each of these aforementioned ideas can be split up into short and long-term solutions with an eye on continuous improvement(s) for maturing the organization's solutions and projects. In the short term, to bring a project back from falling off the cliff, keep in mind these three itemsas suggested by Gale (2010a, p. 34):
- What can be accomplished in the time remaining with minimal risk?
- What can be done with a higher-risk, more intensive plan?
- What should be cut or moved to another project?
On the other hand, long-term solutions are spawned from short-term successes. Even though “best practices” are valuable to document and maintain they should be incorporated into the culture of the organization.
Organizations need to realize that best practices are merely benchmarks that are constantly evolving,” says Bharath Balakrishnan, project manager, finance strategy and transformation at Hewlett-Packard, Bangalore, Karnataka, India. ‘They should be considered as goals that require constant monitoring for future progress of the organization. (Hunsberger, 2012, p. 41)
Stepping back and understanding the type of project and what approach will give the best results may be a helpful part of maturing your project management regimen as well. For example, the project manager should be initially familiar with the waterfall method of project management, a very linear approach to any problem. However, there are other choices and hybrids. Jackson (2010, p. 61) points out the attributes of three approaches:
- Traditional Waterfall
- Heavy up-front planning
- Sequential order of work
- Iterative Waterfall
- Less up-front detail planning
- Shorter work iterations
- Least up-front detailed planning
- Very short work iterations, or sprints
There is great debate on what “traditional waterfall” means in the computing arena as well as other disciplines and it has been designated as a static, unchangeable approach. Clearly, any one of these approaches should have a prototype or the ability to iterate a task in order complete the project with a useable project.
Guarding against scope creep is a continuous process on any project. Creating or adopting a methodology for the future can bring consistency into the organization on how projects are vetted, staffed, and run. Such frameworks as capability maturity model integrated (CMMI) in the information technology field or other business process frameworks have proven to add to the maturity of an organization's project management discipline.
Establishing a project management office (PMO) to centralize project selection and execution strategy will add consistency and quality as well to the projects being run. Having a program director with a staff of project managers to handle all of the on-going projects in an organization will help in mining information from past projects, learn from each other and mature processes.
If all else fails, there is the option of celebrating failure. This may sound extreme but there is something cathartic about a company that admits that sometimes things go wrong. Tata Sons, a holding company in Mumbai, India, holds an annual “worst project” celebration.
The first year, event organizers received only 12 applications, but this year there were more than 200. Each application represents a project team that set out to accomplish something but failed. “That's more than 1,000 people who got over their inhibitions and took a risk,” Mr. Copalakrishnan says. (Gale, 2010b, p. 50)
Whenever scope creep occurs there is always going to be associated risks involved. An expanding project may at first be considered “a good thing,” but under closer scrutiny, it can be seen as problematic simply because there may be no end in sight for the project.
Discovering what the causes are, engaging with the stakeholders and leveraging information technology are keys to bringing the project back on time and within budget. And like Max Bialystock, the project manager at the end of the project may say, “Where did I go right?”
Atkinson, R., Crawford, L., & Ward., S. (2006). Fundamental uncertainties in projects and the scope of project management. International Journal of Project Management, 24(8), 687–698.
Brooks, M. (1968). The Producers 1968 Movie Trailer [Video file]. Retrieved from http://youtu.be/pTW2ZSjG5N0
Gale, S. (2010a). Back from the brink. PM Network, 24(3), 30–34.
Gale, S. (2010b). The upside of failure. PM Network, 24(10), 49–54.
Helm, J., & Remington, K. (2005). Effective project sponsorship an evaluation of the role of the executive sponsor in complex infrastructure projects by senior project managers. Project Management Journal, 36(3), 51–61.
Herrmann, R. F. (2012). The pitfalls of “scope-creep.” Architectural Record, 200(1), 29.
Hunsberger, K. (2012). Giving process it's due. PM Network, 26(7), 38–41.
Jackson, M. (2012). Step by step. PM Network, 26(6), 56–61.
Nogueira, J. C., & Raz, T. (2006). Structure and flexibility of project teams under turbulent environments: An applications of agent-based simulation. Project Management Journal, 37(2), 5–10.
Pavlak, A. (2004). Project troubleshooting: Tiger teams for reactive risk management. Project Management Journal, 35(4), 5–14.
Sewchurran, K., & Barron, M. (2008). An investigation into successfully managing and sustaining the project sponsor–project manager relationship using soft systems methodology. Project Management Journal, 39(S1), S56–S68.
Shore, B. (2008). Systematic biases and culture in project failures. Project Management Journal, 39(4), 5–16.
Stal-Le Cardinal, J. & Marle, F. (2006). Project: The just necessary structure to reach your goals. International Journal of Project Management, 24(3), 226–233.
Thamhain, H. J. (2004). Team leadership effectiveness in technology-based project environments. Project Management Journal, 35(4), 35–46.
© 2012, Dr. Loran W. Walker DMIT, PMP
Originally published as a part of 2012 PMI North American Congress Proceedings – Vancouver, B.C. Canada.