Project Constraints: Scope

Every project begins with great expectations. Having made its way through the first few stages of the project cycle, a team finally reaches the implementation phase full of energy. In most organizations, what happens next is typical: stakeholders contact project managers, asking to “squeeze in just one more thing.” Or, team members start hearing news on the grapevine about how a project is “changing focus.” In the worst cases, project managers must cope with the demands of new stakeholders who weren’t present from the identification to the presentation portions of the project.

Whatever the cause, a change in the scope of a project can cause the biggest damage to a team’s end result. While some leaders pride themselves on pushing teams harder to achieve even more than they planned, most organizations simply fall into a hole of oversized expectations. Project managers can maintain control over this project constraint by watching for three common threats:

This term from the software development world can easily apply to any project that suddenly finds itself bloating with requests. Most project managers associate feature creep with conversations that contain the phrase, “while you’re in there…” Most incidences of feature creep actually start with good intentions. A team member may have discovered a need for a new enhancement, or an element from one portion of the project may become applicable to the project as a whole.

Regardless of the intent, it’s up to a dedicated project manager to make sure feature creep doesn’t cause the entire enterprise to derail from its other two project constraints. When time and budget can accommodate new requests, project managers can graciously agree to them. However, managers who discover that a “simple” task could throw a team over budget or off schedule must firmly deny new features during the implementation phase.

In many cases, project managers can use the “parking lot” method of logging requests and addressing them as time and budget permit. At other times, managers must simply refer requestors to the original project documentation to back up their belief that new features must be put on hold.