The SOW describes the project scope, major responsibilities, deliverables and final product description, constraints, and signatures. Below is an outline of an SOW with corresponding examples:
I.
Goal
A.
Obtain ISO 9000 certification of all IS development processes II.
Objectives
A.
Complete ISO certification by August 28
B.
Document 100 percent of the software development processes
III.
Product/Service Description and Deliverables
A.
Develop and publish quality manual
B.
Document all as-is and to-be processes prior to certification C.
Train entire IS development staff on new processes
IV.
Constraints
A.
Training cannot exceed 40 hours per person
B.
Third party registration cannot exceed $50,000
V.
Responsibilities
A.
Implementation team
B.
Executive steering committee
Work Breakdown Structure
The WBS is a top-down, hierarchical list of the deliverables and the steps to produce them. The purpose is to identify the major deliverables and the final product and list the tasks to build them. An effective WBS has a level of granularity that makes
estimating and tracking of tasks meaningful, usually requiring less than two weeks of effort. The WBS is based upon the content in the SOW and the input from the people who perform the work. Once complete, the project manager does estimating, develops schedules, and allocates resources. See Exhibit 1 for an example of a WBS.
Exhibit 1. Work Breakdown Structure
Estimating
With a good draft of the WBS, the project manager estimates the effort required to complete each of the lower level items in the work breakdown structure. Often, estimating is highly subjective, reflecting extreme optimism or pessimism. Rarely do estimates emerge realistic. To overcome the effects of extreme optimism or pessimism, a formula — called the three-point estimate technique — exists to compensate for the tendency towards exaggeration. For each low level item, the project manager looks at three variables: most optimistic, most pessimistic, and most likely. The most pessimistic is the time required to complete a task under the worst conditions. The most optimistic is the time under the best conditions. The most likely is the time under “typical” or “normal” conditions. Next, the variables are plugged into a formula:
Expected Time = Most Pessimistic + 4(Most Likely) + Most Optimistic / 6
Example: 120 hours + 4(80 hours) + 60 / 6 = 83.33 hours
After estimating, the project manager translates the figures into flow, or work, days to develop schedules. The time is typically divided into units of eight hours.
Scheduling
With the SOW, WBS, and estimates complete, the project manager can draft an integrated, or network, schedule for the project. The integrated schedule is based upon the logical relationship among lower level tasks in the WBS and the time estimates; the result is a calculated set of dates for each task. These dates are: early start date, early finish date, late start date, and late finish date. Early start date is the earliest time that a task can start and early finish is the earliest time to finish; late start is the latest that a task can finish and late start is the latest time to finish.
These dates become significant because they determine not only the flexibility in starting and completing tasks but also the critical path. It is the path in the network diagram that is the longest and has the tasks that cannot slide. Sliding these tasks will jeopardize the project completion date. “Float” is the degree that a task can slide past its completion date; tasks on this path have the least float. Exhibit 2 is part of a network diagram for an ISO 9000 project.
Exhibit 2. Network Diagram
Resource Allocation
The initial draft of the network diagram is sufficient, but it is unusable until resources are applied against it. The project manager looks at the available resources and allocates to each task. This allocation is mainly manpower-based for an ISO 9000
project; the project manager assigns people according to their education, knowledge, and experience. The project manager may, in turn, adjust estimates, schedule logic, or dates to reflect the expertise level of those people assigned to a task.
Budgeting
Calculating costs is relatively easy upon completion of resource allocation. The project manager, using the project database, calculates the direct and overhead
costs for each task and the grand total for the entire project. The project manager then has a realistic estimate of the entire cost for the project.
Risk
All projects, even ISO 9000 projects, are not without risks. As with other projects, these risks, or vulnerabilities, can lay waste to the best plans. The project manager who performs a risk assessment can determine where some of the vulnerabilities may occur and adjust the estimates, schedules, and resource allocations accordingly.
Doing a risk assessment enables the project manager to effectively control the project. Some common risks facing an ISO 9000 project include:
§ Failing to agree upon what is an acceptable level of defects
§ Failing to follow a standardized audit process
§ Failing to receive ISO 9000 certification
§ Lacking “buy-in” from key project participants
§ Lacking senior management support or commitment
§ Not agreeing upon a measurement criteria
§ Not identifying a process owner
§ Using an ill-defined criterion for benchmarking
ORGANIZING
Having good plans in place are necessary but have little use if no infrastructure exists to support them. A project manager can put an infrastructure in place by instituting one or more of these elements: team organization, responsibility matrix, project manual, meetings, and software.
Team Organization
Assembling a group of people is not enough to form a project team. Structure is necessary so that the synergy of the group is meaningfully captured and directed. An effective way to capture that synergy is to organize the team into relationships that reflect clear reporting and authorities and reflect that arrangement, as shown in an organization chart (Exhibit 3).
Exhibit 3. Organization Chart
Responsibility Matrix
The work breakdown structure and resource allocation provide the basis for developing a matrix showing responsibilities for tasks. The project manager decides whether to distribute the entire matrix or selected portions. Below is an example of a responsibility matrix:
Exhibit 4. Responsibility Matrix
Name ? Task
Banks
Valdez
Rogers
Franks
1.2.1.1
X
Lead
X
1.2.1.2
X
X
1.2.2.1
Lead
X
1.2.2.2
X
Lead
X
Project Manual
Ideally, team members should have the necessary information to do their work. A project manual is an effective way to provide that information. The manual can be either in hard copy or electronic form. Here is an outline of a typical project manual: I.
Introduction
A.
About this manual
B.
How to keep it current
II.
Plan
A.
Statement of work
B.
Responsibilities
C.
Schedules
III.
Documentation standards
A.
Narrative documentation
B.
Flowcharting
IV.
Procedures and policy statements
V.
ISO 9000 guidelines
VI.
Internal documentation
VII.
Service support functions and responsibilities
VIII.
Documentation
A.
Reports
B.
Forms
IX.
Contact lists
X.
Self-assessment practices
XI.
Appendices
Meetings
In a project environment, the project manager conducts three basic meetings: checkpoint review, status review, and staff. The checkpoint review meeting is held after the occurrence of an important event, such as the completion of a major milestone in the schedule. The focus of this meeting is to learn what has and has not gone well and decide whether to proceed. The status review meeting is held regularly, i.e., weekly. Its purpose is to assess schedule status, cost, and quality.
The staff meeting, to communicate and share information, is held regularly.
Software
The larger the project the more important is the role of software. Because the number of tasks and their interrelationships become more complex, the compilation and analysis of data require speed and reliability. Some popular, reliable project management packages include Microsoft Project and Primavera Project Planner.
Using software requires, however, a caveat. The software does not manage a project
— the project manager does. The software is only a tool, like the project manual or schedule, to attain desired results.
CONTROLLING
A plan lays the basis for good project management but does not guarantee success.
A project manager must still ensure that the plan is being followed — that he is controlling the project. Controlling involves these four elements:
1. Status collection and assessment
2. Tracking and monitoring
3. Contingency planning
4. Replanning
Status Collection and Assessment
To determine how well a project is progressing requires collecting useful data about its overall performance. In other words, status collection. Collecting data is, however, not enough. The project manager must also assess performance vis à vis the plan. In other words, status assessment. Status collection and assessment work together to help the project manager track and monitor project performance.
Because ISO 9000 projects last one to one-and-a-half years on average, a tendency exists to give status collection and assessment a lower priority than “doing the work.” Relegating status collection and assessment to such a level can lead to an illusion of optimism and, subsequently, to grave oversights that require a rush to successfully complete the project. It is best to set a regular time for collection and assessment to constantly review performance.