Assignment Case- Workshop: Project Definition by Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon
With expertise in project management, Konrad Cerni was a senior consultant at Ball, Inc., a very well-known company in the region. He graduated a Ph.D. in Engineering Management from one of the leading universities on the East Coast, and turned himself to a practitioner role since. Konrad, who preferred not to be addressed as "Dr.", had worked in the field of project management at a wide range of companies in different industries from a traditional manufacturing firm to a very complex aerospace operation.
His recent client requested Konrad conduct a workshop specifically designed for project management tools, for about 30+ project and program managers in the company. Because of the participants' busy schedules, the workshop was requested to be one eight-hour session. With a variety of project management tools (generally speaking 50+ tools are available in the practice and literature of project manage- ment), Konrad had to pick only those important ones, and cover them in as many areas as possible. One of the tools he included was called a Scope Statement.
WHAT IS A SCOPE STATEMENT?
Typically, a scope statement is a document succinctly describing the project objectives, scope, summarized costs, and resource requirements. The details of the document may vary from one company to another. Fundamentally, how- ever, the document answers the crucial question of "What do we produce in this project?" The answer thus creates a big-picture view of what the project is all about, setting the scope baseline to follow in whatever is done during the project.
A PICTURE IS WORTH A THOUSAND WORDS
Konrad presented an example of the scope statement in practice. The particular company discussed has the project definition that captures six major items: stra- tegic goals, tactical goals, milestones, constraints, assumptions, and specifically excluded scope.
1. Strategic Goals: This element acquaints you with the business end to be attained; the origin of the task; the owner or customer; and the type of product fixture, structure, assembly, or study, etc. In this section, state the overall pur- pose of the job and include any meaningful background that aids in describing the purpose. For example, the overall purpose of this project is to develop a project management software that will capture 40 percent of the market share in two years. The project is originated in the corporate strategic plan.
The goals should also include major commitments established with the customer, a subsection called the project goals. This section is written to clearly delineate goals for schedule, cost, and technical performance. An example would be: "This effort will be completed within one calendar year, will cost no more than $500,000, and will result in a report per World Bank guidelines." Make sure that you prioritize the objectives. These priorities will serve as decision-making criteria in the trade-off situations.
2. Tactical Goals: This element should describe the major tasks of the project, for example, conceptual development, detailed design, delivery of a complete and tested steam system; preparation of operating manuals; training of the owner's crew, etc. An example would be: "We will design, procure, install, and com- mission the manufacturing plant." This section may have four to six major deliverables such as detailed design, prototype, and training. These deliv- erables become level one in the WBS and will be further broken down into more detailed WBS elements/deliverables such as documentation, installed facilities, services, contractual end products, etc.
They should be described in terms of how much, how complete, and in what condition they will be delivered. The work scope and the WBS can be worked in an iterative manner to assure that the WBS displays the scope in its entirety, and to provide direct reference from any WBS element back to the work scope narrative.
3. Milestones: Identify and define key milestones, including required completion dates and completion criteria. Key events such as fab completion (a manufac- turing plant which fabricates items), assembly completion, test completion, document package sign-off, or customer acceptance may be included. List all contractually fixed events and any other major schedule milestones that are critical to completion of the work. Often these milestones are dates related to deliverables/end products from the previous section.
4. Constraints: List special technical requirements, codes, and standards such as ASME or ISO. Describe facility requirements for fabrication, assembly, test- ing, or other facilities to accommodate the work. Define functional/operational requirements, data requirements, and special instructions. Identify design cri- teria. Describe technical constraints, if they exist. Schedule constraints may include interface with progress or completion of other work. In some cases, scheduled delivery may be contractually very rigid. Financial constraints are often related to funding and should be identified. Facility requirements may be better planned when the financial constraints are known.
Figure 5.1 Project Definition Form (Scope Statement)
Project Definition Form (Scope Statement)
Strategic Goals: Improve customer service for our products and services by 5 percent via deployment of a new customer relationship management software.
Time: Finish by September 15, 2010 Cost: $150,000 Quality: Per service level agreement
Tactical Goals: Analyze workflow, configure software, develop prototype, and release software.
Major Deliverables: Workflow analysis, configure settings, prototype, training, release
Key Milestones
- Workflow analyzed by March 15, 2010
- Configure complete by April 15, 2010
- Prototype complete by August 15, 2010
- Training complete by August 15, 2010
- Release by September 15, 2010
Major Constraints
Our key developers will not be available in June because of their visit to our European ally.
Major Assumptions
Configure software to meet our workflow; we will not change our workflow to meet software.
Specifically Excluded Scope
This project does not include training on customer service skills.
5. Key Assumptions: With every task comes a set of assumptions and frequently unresolved uncertainties. Identify and list those assumptions. If some needed information is not yet available when the work scope is being prepared, use your experience and best judgment, or ask others who have been involved in related work. For instance, assumptions may be that a software testing will be done by the external resources, or that design activities take place in accordance with a design manual. If assumptions are made with reasonable judgment, the work scope can be sufficiently complete to develop the other elements of the project plan.
6. Specifically Excluded Scope: Describe what is not to be included in the task, what is contractually excluded, or not included for other reasons. If the cus- tomer waives the need for operational testing, for instance, that should be stated. There are many examples. State specifically what is sometimes related to a similar task, but at this time is not included. This will help planners, engi- neers, management, and customers better understand the scope of work.
Konrad provided another example as presented in Figure 5.1.
Discussion items
1. What are the pros and cons of the project definition?
2. When should the project definition be used?
3. Should small projects bother using it? Why/why not?