Overview
PMBOK® defines Project Scope as "the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions." The scope of a project is the clear identification of the work that is required to successfully complete or deliver a project. One of the Project Manager's responsibilities is to ensure that only the required work (the scope) will be preformed and that each of the deliverables can be completed in the allotted time and within budget. Key to executing this responsibility successfully is clear definition of the scope and traceability from requirements to functional and technical design. Equally important to successful scope management is an agreed change control process and change control board or governance structure.
Tips
Project Scope Management Best Practices
- Obtain both business and IT team agreement on and commitment to following a change control process early in the project, no later than the start of SIT. Elements of a solid change control process include: (1) clear definition of what's a bug and what's a change; (2) the conditions and frequency of Functional Specification Document and Technical Design Document updates; (3) the conditions under which a change can be accepted for development without approval and which ones require approval; (4) clear definition of the change approval criteria and procedure; (5) a clearly defined change business prioritization schema; and (6) a clearly defined cutoff date for change acceptance and release for each test cycle as well as production code migration.
- Ensure that incoming requests are prioritized, fit the size of the available resources, and are agreed to via the defined change control process. If the project requirements, development, and test cycles are large, then be sure to alert stakeholders when their change requests will be addressed — don't just leave them in limbo. Make sure SMEs and users are part of the prioritization of change requests.
- Ensure that all incoming requests are fully specified before considering them "real" requirements. Ensuring change requests contain more information than just a one-linker and asking for more complete information up from buys the technical team some time and forces the requester to slow down and articulate his/her needs more diligently. In fact, a workaround may look more attractive as a result.
- Ensure that project planning is at a detailed level so that more is known about what will be built. The less detailed the requirements, the quicker the project can get off-course.
- Ensure solid scope definition using rigorous prototyping. The earlier this can happen in the project life cycle, the sooner the users can give feedback and start to understand what they want and don't want (since no BRD or FSD can be perfect). If this is not possible, use demos (i.e. "demo days") and Conference Room Pilots (CRPs) as soon as possible, as early as the development phase, when there is a block of functionality to show. Doing this during UAT can be fatal to a project; it is too late.
- Project Manager and stakeholders both need to be comfortable with change; it is a normal aspect of any software project. Factor this into your planning.
- Try to avoid gold plating. Remind the team of the "good enough" concept, 80% versus 100%, OK versus perfect, etc.
