Task statements are usually part of the statement of work (SOW) provided by the customer. Thus, these are used interchangeably in this text. These statements are normally accepted and reiterated by the system developer in the program plan. Changing the customer's SOW is not a recommended action because it may turn into a point of contention later in the process. Work breakdown structures (WBSs) may or may not be part of the customer's definition of the work to be performed. When it is provided by the customer, it almost always should be accepted and used by the system developer.
An example of task statements (sometimes also called task areas) is shown in Exhibit 3.4, drawn from a real-world request for proposal from the FAA to industry. Under each of the task areas listed in the Exhibit, there is a short description of the tasks to be performed. Thus, task statements are embedded in the defined task areas.
Exhibit 3.4: Example of Task Statements and Task Areas from the
Task Area 1
Requirements Analysis and Documentation Computer-Human Interface (CHI) Specification Development
Reliability, Maintainability, and Availability (RMA) and Fault Tolerance (FT)
System Modeling and Performance Analysis
Local Communication Network (LCN)
Technical Planning and Risk Analysis Software Engineering
Task Area 2
Advanced Automation System (AAS) Contractor Requirements Trace-
ability and Compliance Tracking Technical Support
Engineering Change Proposals (ECPs) Testing and Evaluation Implementation
3.3 TASK STATEMENTS, STATEMENT OF WORK, AND WORK BREAKDOWN STRUCTURE
Division/Branch Segment Integrated Logistics Management Task Area S
Terminal Automation Program Management
En Route/Traffic Management Systems Automation Program Management
Maintenance Automation Program Management Task Area 4
Planned Product Improvement Design Evaluation Planned Product Improvement Operational Test and Evaluation (OT&E) Operational Test and Evaluation Site Implementation Manufacturing and Production Factory Testing Task Area S
Configuration Management Financial Management Data Management Office Automation Program Control
A similar example for work to be performed under a solicitation from the Defense Systems Management College (DSMC) is provided in Exhibit S.S. Here, again, task areas are defined and elaborated to constitute task statements.
Exhibit 3.5: Example of Task Areas from the Defense Systems Management College [3.6]
Task Area 1: Curriculum Design and Development Task Area 2: Program Management Course Curriculum Material Update Task Area S: Development of Automated DSMC Management and Teaching Tools
Task Area 4: Statistical Analysis Support
Task Area S: Executive Education Curriculum Development
Task Area 6: Quality of Instruction
Task Area 7: Define Teaching Quality
Task Area S: Establishment of Baselines
Task Area 9: Reports
A third illustration of how a statement of work may be formulated is found in Exhibit S.6. This exhibit lists seven ''detailed items of work'' with a breakdown of more specific work under the first item.
Exhibit 3.6: Example of Items of Work from the Department of
Transportation's Volpe Center [3.7]
1. Project Planning and Scheduling Support
1.1 User and System Requirements Analysis
1.2 Technical Meeting Support
1.3 Technology Assessment
1.4 Project Management Support
1.5 Transition Planning
1.6 Environmental Impact Assessments
1.7 Cost Benefit Analyses
2. System Design and Development Support
3. Software Development Support
4. Systems Integration Support
5. Testing and Evaluation Support
6. Training Support
7. Documentation and Configuration Management Support
The work breakdown structure (WBS) is also a formal exposition of work to be performed and is illustrated in Figure 3.1 for a NASA program known as Earth Observing System Data and Information System (EOSDIS) Phase B [3.8]. The most convenient form of a WBS is one in which there is a one-to-one correspondence between the tasks and the WBS. In such a case, the WBS elements can be considered a further breakdown of the major tasks into subtasks and each WBS element is identical to a subtask. If a WBS has not been defined by the customer, it is a recommended procedure to have the WBS correspond directly to the tasks and subtasks. However, if the customer provides a WBS, it may be necessary to develop a ''cross-walk'' between the task statements and the WBS. Such a cross-walk is shown symbolically in Table 3.2. This usually creates a layer of complexity that is not really desirable but may be necessary in order to satisfy the instructions of the customer.
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.