It is usually easier for a project team to identify what the software project should include than what it should?of include. The goal and objectives statements describe what is to be part of the final project scope. What is often harder to describe is what it will not include, but this is absolutely necessary to help define the edges of the project scope. Later, preparation of the SRS will detail the contents of what is included more finely.
Use the Is/Is Not technique to help draw crisp boundaries around the project scope and its objectives individually. This technique is simple. For each goal or objective, your team uses brainstorming techniques to define what it is and make a list for the team (see Figure 7-6). Next, brainstorm a list of what it is not, and make that into a list. Both lists can then be used to make a list of assumptions about the project.
Figure 7-6. Is/Is Not Technique
Figure 7-6. Is/Is Not Technique
This exercise pulls out hidden assumptions that team members had about the project scope or its work products. It is better to find that out early rather than get deep into the project and discover misunderstandings about the project objectives and scope. For instance, using the example goal statement in Box 112, we might say that the project:
® for the engineering department;
® to be deployed before we begin the next major external project; ® to be successful per existing application deployment criteria;
® to serve as a training project to familiarize the team with the new project management process.
® intended for use by other departments or external customers;
® a full-blown labor accounting system;
® intended to be accessed by PDAs or wireless Web cell phones;
® required to interface to existing earned value management programs such as MS Project;
® to be in beta test mode when the next external project begins;
® to use outside contractors for development.
These characterizations become a way to crisply define the edges of the project's scope. They translate easily into assumptions to be recorded for the project charter and SPMP. The assumptions then become the first risks of the project because if any of them is violated, the project scope is breached.
Sometimes the scope of work is large enough to warrant its own document, instead of appearing as statements in a charter. However, at this early stage in the life cycle, the scope of work is just a rough planning item. Sometimes, this document is referred to as the statement of work (SOW), statement of requirements (SOR), or software requirements specification (SRS). Often, the SOW/SOR/SRS is subdivided into pieces that fully describe what a subcontractor is expected to do, in relation to the overall requirements. In these cases, the SOW/SOR/SRS may contain nonspec items from the project management plan, such as status reporting protocol, payment schedules, and legal statements. Details and templates for SOW construction vary with industry and domain, but they generally carry the specifications of the product to be built in a format that can be separated from the other processes of the project.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.