Building the Baseline Project Plan
Building the Baseline Project Plan
All the information collected during project initiation and planning is collected and organized into a document called the baseline project plan. Once the BPP is completed, a formal review of the project can be conducted with customers. This presentation, a walkthrough, is discussed later in the chapter. The focus of the walkthrough is to verify all information and assumptions in the baseline plan before moving ahead with the project. An outline of a baseline project plan, shown in Figure 4-12, contains four major sections:
2. System description
3. Feasibility assessment
4. Management issues
The purpose of the introduction is to provide a brief overview of the entire document and outline a recommended course of action for the project. The introduction is often limited to only a few pages. Although it is sequenced as the first section of the BPP, it is often the final section to be written. It is only after performing most of the project planning activities that a clear overview and recommendation can be created. One initial activity that should be performed is the definition of the project scope, its range, which is an important part of the BPP’s introduction section. When defining the scope for the Customer Tracking System within PVF, Jim Woo first needed to gain a clear understanding of the project’s objectives.
Jim interviewed Jackie Judson and several of her colleagues to gain a good idea of their needs. He also reviewed the existing system’s functionality, processes, and data-use requirements for performing customer tracking activities. These activities provided him with the information needed to define the project scope and to identify possible alternative solutions. Alternative system solutions can relate to different system scopes, platforms for deployment, or approaches to acquiring the system. We elaborate on the idea of alternative solutions, called design strategies, in Chapter 7. During project initiation and planning, the most crucial element of the design strategy is the system’s scope. Scope depends on the answers to these questions:
- Which organizational units (business functions and divisions) might be affected by or use the proposed system or system change?
- With which current systems might the proposed system need to interact or be consistent, or which current systems might be changed because of a replacement system?
FIGURE 4-12: An outline of a baseline project plan contains four major sections: introduction, system description, feasibility assessment, and management issues.
- Who inside and outside the requesting organization (or the organization as a whole) might care about the proposed system?
- What range of potential system capabilities is to be considered?
The statement of project scope for the Customer Tracking System project at PVF is shown in Figure 4-13. A project scope statement is a short document prepared primarily for the customer to clearly describe what the project will deliver and outline generally at a high level all the work required for completing the project. It is therefore a useful communication tool. The project scope statement ensures that both you and your customer gain a common understanding of the project size, duration, and outcomes. The project scope statement is an
FIGURE 4-13 Project scope statement for the Customer Tracking System at Pine Valley Furniture.
easy document to create because it typically consists of a high-level summary of the baseline project plan (BPP) information (described next). Depending upon your relationship with your customer, the role of the project scope statement may vary. At one extreme, the project scope statement can be used as the basis of a formal contractual agreement outlining firm deadlines, costs, and specifications. At the other extreme, the project scope statement can simply be used as a communication vehicle to outline the current best estimates of what the project will deliver, when it will be completed, and the resources it may consume. A contract programming or consulting firm, for example, may establish a formal relationship with a customer and use a project charter that is more extensive and formal. Alternatively, an internal development group may develop a project scope statement that is shorter and less formal, as it will be intended to inform customers rather than to set contractual obligations and deadlines.
For the Customer Tracking System (CTS), project scope was defined using only textual information. It is not uncommon, however, to define project scope using tools such as data-flow diagrams and entity-relationship models. For example, Figure 4-14 shows a context-level data-flow diagram used to define system scope for PVF’s Purchasing Fulfillment System. As shown in Figure 4-14, the Purchasing Fulfillment System interacts with the production schedulers, suppliers, and engineering. You will learn much more about data-flow diagrams in Chapter 6. The other items in the introduction section of the BPP are simply executive summaries of the other sections of the document. The second section of the BPP is the system description, in which you outline possible alternative solutions to the one deemed most appropriate for the given situation. Note that this description is at a high level, mostly narrative in form. Alternatives may be stated as simply as this:
1. Web-based online system
2. Mainframe with central database
3. Local area network with decentralized databases
4. Batch data input with online retrieval
5. Purchasing of a prewritten package
If the project is approved for construction or purchase, you will need to collect and structure information in a more detailed and rigorous manner during the systems analysis phase and evaluate in greater depth these and other alternatives for the system. When Jim and Jackie were considering system alternatives for the CTS, they focused on two primary issues. First, they discussed how the system would be acquired and considered three options: (1) purchase the system if one could be found that met PVF’s needs, (2) outsource the development of the system to an outside organization, or (3) build the system within PVF. Next, Jim and Jackie defined the comprehensiveness of the system’s functionality. To complete this task, Jackie wrote a series of statements listing the types of tasks that she thought marketing personnel would be able to accomplish when using the CTS. This list became the basis of the system description and was instrumental in helping them make the acquisition decision. After considering the unique needs of the marketing group, they decided that the best decision was to build the system within PVF
FIGURE 4-14 Context-level data-flow diagram showing project scope for the purchasing fulfillment system at Pine Valley Furniture.
In the third section of the BPP, feasibility assessment, the systems analyst outlines project costs and benefits and technical difficulties. This section is where high-level project schedules are specified using Network diagrams and Gantt charts. Recall from Chapter 3 that this process is referred to as a work breakdown structure. During project initiation and planning, task and activity estimates are generally not detailed. An accurate work breakdown can be done only for the next one or two life-cycle activities—systems analysis and systems design. After defining the primary tasks for the project, an estimate of the resource requirements can be made. As with defining tasks and activities, this activity involves obtaining estimates of the human resource requirements, because people are typically the most expensive resource element of a project. Once you define the major tasks and resource requirements, a preliminary schedule can be developed. Defining an acceptable schedule may require that you find additional or different resources or that the scope of the project be changed. The greatest amount of project planning effort is typically expended on feasibility assessment activities. The final section of the BPP, management issues, outlines the concerns that management has about the project. It will be a short section if the proposed project is going to be conducted exactly as prescribed by the organization’s standard systems development methodology. Most projects, however, have some unique characteristics that require minor to major deviation from the standard methodology. In the team configuration and management portion, you identify the types of people to work on the project, who will be responsible for which tasks, and how work will be supervised and reviewed (see Figure 4-15). In the communication
FIGURE 4-15 Task-responsibility matrix
FIGURE 4-16 The Project Communication Matrix provides a high-level summary of the communication plan.
plan portion, you explain how the user will be kept informed about project progress, such as periodic review meetings or even a newsletter, and which mechanisms will be used to foster sharing of ideas among team members, such as a computer-based conference facility (see Figure 4-16). An example of the type of information contained in the project standards and procedures portion would be procedures for submitting and approving project change requests and any other issues deemed important for the project’s success. You should now have a feel for how a BPP is constructed and the types of information it contains. Its creation is not meant to be a project in and of itself but rather a step in the overall systems development process. Developing the BPP has two primary objectives. First, it helps to assure that the customer and development group share a common understanding of the project. Second, it helps to provide the sponsoring organization with a clear idea of the scope, benefits, and duration of the project. Meeting these objectives creates the foundation for a successful project.