Article Overview
Okay, a project is underway, the project milestones are set based on deliverables and the processes by which the company and the project have agreed. The work has begun, and your latest status review shows the project might miss a milestone. It’s time to look at the scope and deliverables impacted. Are there non-essential tasks that can be left out? Is it possible to de-scope one or more of the deliverables?
Table of Contents
- Prioritizing
- Communicate the Changes
- Pushback
- Methodology
- Recovering the De-Scope
- Summary
"By general law, life and limb must be protected, yet often a limb must be amputated to save a life, but a life is never wisely given to save a limb," ~Abraham Lincoln
Hopefully, at the start of the project, we have prioritized the scope. This prioritized scope identifies what is fundamental to deliver. Sacrificing the entire project for something that is not essential to the project's success, is not prudent decision-making. To that end, we will relate a true story.
One of us was a manager at an engineering firm. The managers of the various departments required to perform the project would get together and discuss the amount of project work underway presently, and how this proposed new project would fit into the workflow along with the preliminary scope and early estimates. A large project, in terms of scope and effort, was under consideration. The managers had great concerns about how this work would fit into the department workload, and meet the expected schedule. I saw this and suggested we talk with the people sponsoring the project to find the most important parts of the scope for delivery in that time frame.
The lead manager (Chief Engineer), essentially said “the sponsor asked for all of the scopes, that is what we are going to do.” It is admirable to work toward meeting all of the customer’s needs, however, not at the risk of losing all. A prioritized scope does not mean you are going to intentionally neglect some portion of the scope, only that project decisions can be made consistent with the sponsor's or customer’s prioritized need.
Projects can be scoped to accomplish a variety of customer and organization’s objectives; from experience, this happens frequently. This is where agile and scrum are productive, the work is only on the most valued of the scope. This is not just anecdotal, there are studies that indicate, at least for software projects roughly 45% of the features in the software will never be used (Jim Johnson keynote speech XP 2002, Sardinia Italy). For additional information we suggest a book (at least the first chapter) of Agile & Iterative Development – A Manager’s Guide by Craig Larman. The first chapter provides a nice review of common project failures including the scope and period of delivery. It is best to not put the important scope of the project at risk with features that are of little to no value to the customer. Review and prioritize the scope with the customer and project sponsor at the beginning of the project, to clearly define the paramount accomplishments expected from the project. This is an approach to risk management of the scope of the project by ensuring the most valued scope of the project is known, and appropriate actions are taken to ensure that delivery.
If this prioritization was not accepted at the beginning of the project, a prudent project manager will keep a delineation of the various scope items, and track metrics that will help predict whether the project is going to meet the targets when tradeoff decisions are required, and when this looks like the project will not deliver to expectations. This will allow a revisit of this discussion with the sponsor.
Whether the project has prioritized scope, the project would benefit from a focus on those things that are most important for the company and the fundamental reason for accepting the project. It is the project manager's priority to ensure the most important parts of the scope are delivered, and the benefit of the project undertaken is realized.
If the project that was required to deliver a set of features, when it became clear that the entirety of the project scope would not be delivered, go to the project sponsor to define what could fit within the time remaining, and what they found most important. Sometimes a sponsor does not want to hear the fact that the project will need to descope to meet the schedule. It is important to be well-armed with some measurements that demonstrate the schedule and rate of accomplishment rate. Suggest to the sponsor that the remaining features could be delivered post initial delivery as part of the product development plan.
Use the status metrics to demonstrate the need for changes. Use tools such as configuration management to clearly identify what the changes entail. Clearly list the scope and the attributes that constitute well for that scope. Map the prioritized scope to a specific iteration of the product going through the development. The graphic below demonstrates how this incremental delivery of the expected scope could be articulated, each of these packages would have clearly defined scope elements included in that definition of the iteration.
There is often some resistance. Share just the facts and don’t embellish. Share the forecast, metrics, and measurements with the team members. The team should see the writing on the wall regarding the scope versus the time available. The team members should agree with the changes; haven’t seen a team yet who did not like reduced scope or work.
Assuming the changed scope was reviewed with the project sponsor prior to going to the team, the PM should confirm with the sponsor the team’s buy-in to the changes. This discussion with the sponsor is another opportunity for the sponsor to challenge the changes or want a deeper explanation of meeting the client's requirements.
Throughout this process, the sponsor might have been discussing potential changes with the client. In some organizations, this is the process and in other organizations, the PM is directed to discuss the changes with the client. This is when the quality of the decisions made could be challenged. So, be prepared!
The methodology doesn’t matter, the approach to take should be commensurate with the scope, risk, and the organization's processes and assets. Generally speaking, rescoping the project may be easier with an Agile methodology, as it is small increments. Whereas the conventional approach while being incremental and iterative the schedule increments are larger than the 2 to 4 weeks sprints.
This can happen if the sponsor is okay with moving these deliveries to later iterations of the product. The problem often is associated with securing additional funding as funding and delivery date/schedule are somewhat connected. If the sponsor wants these features, delivered in another iteration and there is funding available for it, then it could make sense to plan the next steps in the product development lifecycle. This is then another project, building off the previous delivery, which means a w schedule, perhaps more funding unless some of the original budgets remain.
It is a time-honored practice of prioritizing the elements of the project scope. In fact, agile versions of accomplishing the objectives of the works take considerable effort to prioritize (most value) the scope. This has been part of conventional projects although the practice, from experience, may not be very widely practiced. Project managers should be proactive, not coming to the project sponsor as disaster strikes, but rather, be to think ahead.
Knowing what is most important in the project allows a focus on those attributes. Decisions are made in projects all of the time, sacrificing some things, because another thing is more important.
We suggest at the beginning of every project, the scope be prioritized. One should not wait until the bottom falls out of our project falls out. Have the discussion when there is more time to really consider the approach rather than the stress of a ticking clock in our ear getting louder as we set about determining the best course of action. Late in the project, fter expectations have been set or established, this discussion becomes difficult. It is important to have clear metrics that provide some real understanding of the project for the sponsor, and for the stakeholders and team members.