How can team leaders best guide project management when there are significant changes to requirements?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
From a project management point of view, passing along changes to requirements forces you to ask a few questions to make sure that the team takes the right approach when adapting to those changes, and to make sure that management's expectations are properly managed in light of those changes.
Start with the premise that the previous requirements were validated to be the ones required to completely satisfy the goals of the project underway. In other words, as long as all of the implementation work required to satisfy those requirements is completed, all of the goals of the project will be met. While this may not be true, it is a useful point of view from which to assess the changes. Given that point of view, the first question that needs to be answered is "With these requirements changes, will the goals of the project (still) be met - assuming we implement all of the requirements as they now exist?"
Some people may immediately focus on what's been completed already, and has to be "thrown away" because of the changes. However, that isn't the right area of focus (it is only useful for retrospective, or for trying to quantify how much requirements are changing) from a project management perspective. That focus would be a "sunk cost analysis." What matters is given current resources, remaining time and the not-yet-completed (but now changed) requirements, how long will it take to complete the project?
Assuming that the changed requirements satisfy the goals, if the team can complete the remaining changed requirements, then project management is in good shape - and the team leads just need to let those folks know this. Usually, however, changes in requirements end up causing the forward-looking assessment to indicate that there is not enough remaining time in the existing schedule to implement everything as indicated by the changes. Therefore, the next question is, are there any requirements (as changed) that are not needed to support the goals? If so, they are the prime candidates for removal from the project schedule.
Right now, every project sponsor reading this has just had the moral imperative to say, "If I didn't need it, I would not have asked for it." Except for that very rare project sponsor who already anticipated scope-growing changes, and established the original schedule and budget to allow for not only everything that is "needed" but also some things that are only "desired." The team leads can let project management know the time/cost savings of dropping some of those requirements, given the new realities.
At this point, if everything has not been resolved, the project sponsor is going to be faced with a choice - extend the project (in time and/or budget), or accept a delivery that does not meet the goals of the project. The project manager has to present those choices. Note that "accept delivery, at reduced quality levels" is not presented as a choice. The previously intended quality levels were either (a) required to meet the goals of the project - like customer satisfaction and long-term maintainability of the code, or (b) were desired because someone just prefers being a perfectionist, and delivering to a higher quality level than is actually needed.
The team leads should present the project manager with choices, to be presented to the project sponsor. The best "inside the box" solution is usually some combination of delay and scope-reduction. This is because, in my experience, "firm" dates are regularly flexible, even when not arbitrary. All of the needed requirements are usually not really needed - because at least some of them represent delivery along a "more is better" continuum, and are usually also flexible about delivering "less" along that continuum.
The best "outside the box" solution comes from engaging the project sponsor to (a) revisit her goals (the ones required to enable execution of a particular strategy), and (b) revisit which and how much of those goals to support with the current project. The previous goals were not allocated to the project in a vacuum, but rather in the context of multiple projects. The project sponsor may be able to shift some of the goals from the (now changed) project to another project, shifting some of the requirements (and therefore implementation work) to that other project.
Dig Deeper on Software Project Management Process
Related Q&A from Scott Sehlhorst
Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing.continue reading
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype.continue reading
Scott Sehlhorst offers strategic guidance on how to approach application portfolio management with a focused vision.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.