Planning the Project-Managing the Information Systems Project
Planning the Project
The next step in the project management process is project planning. Project planning involves defining clear, discrete activities and the work needed to complete each activity within a single project. It often requires you to make numerous assumptions about the availability of resources such as hardware, software, and personnel. It is much easier to plan nearer-term activities than those occurring in the longer term. In actual fact, you often have to construct longer-term plans that are more general in scope and nearer-term plans that are more detailed. The repetitive nature of the project management process requires that plans be constantly monitored throughout the project and periodically updated (usually after each phase) based upon the most recent information.
illustrates the principle that nearer-term plans are typically more specific and firmer than longer-term plans. For example, it is virtually impossible to rigorously plan activities late in the project without first completing earlier activities. Also, the outcome of activities performed earlier in the project are likely to affect later activities. In other words, it is difficult, and likely inefficient, to try to plan detailed solutions for activities that will occur far in the future.
As with the project initiation process, varied and numerous activities must be performed during project planning. For example, during the Purchasing Fulfillment System project, Chris and Juanita developed a ten-page plan. However, project plans for large systems may be several hundred pages in length. The types of activities that you can perform during project planning are summarized in Figure 3-10 and are described in the following list:
1. Describing project scope, alternatives, and feasibility. The purpose of this activity is to understand the content and complexity of the project. Within PVF’s system development methodology, one of the first meetings must focus on defining a project’s scope. Although project scope information was not included in the SSR developed by Chris and Juanita, it is important that both share the same vision for the project before moving too far along. During this activity, you should reach agreement on the following questions:
- What problem or opportunity does the project address?
- What are the quantifiable results to be achieved?
FIGURE 3-9 Level of project planning detail should be high in the short term, with less detail as time goes on.
Foundations for Systems Development
FIGURE 3-10 Ten project planning activities.
- What needs to be done?
- How will success be measured?
- How will we know when we are finished?
After defining the scope of the project, your next objective is to identify and document general alternative solutions for the current business problem or opportunity. You must then assess the feasibility of each alternative solution and choose which to consider during subsequent SDLC phases. In some instances, off-the-shelf software can be found. It is also important that any unique problems, constraints, and assumptions about the project be clearly stated
2. Dividing the project into manageable tasks. This activity is critical during the project planning process. Here, you must divide the entire project into manageable tasks and then logically order them to ensure a smooth evolution between tasks. The definition of tasks and their sequence is referred to as the work breakdown structure (WBS). Some tasks may be performed in parallel, whereas others must follow one another sequentially. Task sequence depends on which tasks produce deliverables needed in other tasks, when critical resources are available, the constraints placed on the project by the client, and the process outlined in the SDLC
For example, suppose that you are working on a new development project and need to collect system requirements by interviewing users of the new system and reviewing reports they currently use to do their job. A work breakdown for these activities is represented in a Gantt chart in Figure 3-11. A Gantt chart is a graphical representation of a project that shows each task as a horizontal bar whose length is proportional to its time for completion. Different colors, shades, or shapes can be used to highlight each kind of task. For example, those activities on the critical path (defined later in this chapter) may be in red, and a summary task could have a special bar. Note that the black horizontal bars—rows 1, 2, and 6 in Figure 3-11—represent summary tasks. Planned versus actual times or progress for an activity can be compared by parallel bars of different colors, shades, or shapes. Gantt charts do not show how tasks must be ordered (precedence) but simply show when an activity should begin
FIGURE 3-11 Gantt chart showing project tasks, duration times for those tasks, and predecessors.
and end. In Figure 3-11, the task duration is shown in the second column, in days, and necessary prior tasks are noted in the third column as predecessors. Most project management software tools support a broad range of task durations, including minutes, hours, days, weeks, and months. As you will learn in later chapters, the SDLC consists of several phases, which you need to break down into activities. Creating a work breakdown structure requires that you decompose phases into activities— summary tasks—and activities into specific tasks. For example, Figure 3-11 shows that the activity Interviewing consists of three tasks: design interview form, schedule appointments, and conduct interviews. Defining tasks in too much detail will make the management of the project unnecessarily complex.
What are the characteristics of a task? A task:
- Can be done by one person or a well-defined group
- Has a single and identifiable deliverable (the task, however, is the process of creating the deliverable)
- Has a known method or technique
- Has well-accepted predecessor and successor steps
- Is measurable so that percent completed can be determined
Through experience, you will develop the skill of discovering the optimal level of detail for representing tasks. For example, it may be difficult to list tasks that require less than one hour of time to complete in a final work breakdown structure. Alternatively, choosing tasks that are too large in scope (e.g., several weeks long) will not provide you with a clear sense of the status of the project or of the interdependencies between tasks.
3. Estimating resources and creating a resource plan. The goal of this activity is to estimate resource requirements for each project activity and use this information to create a project resource plan. The resource plan helps assemble and deploy resources in the most effective manner. For example, you would not want to bring additional programmers onto the project at a rate faster than you could prepare work for them. Project managers use a variety of tools to assist in making estimates of project size and costs. The most widely used method is called COCOMO (COnstructive COst MOdel), which uses parameters that were derived from prior projects of differing
FIGURE 3-12 COCOMO is used by many project managers to estimate project resources.
complexity. COCOMO uses these different parameters to predict human resource requirements for basic, intermediate, and complex systems (see Figure 3-12). People are the most important and expensive part of project resource planning. Project time estimates for task completion and overall system quality are significantly influenced by the assignment of people to tasks. It is important to give people tasks that allow them to learn new skills. It is equally important to make sure that project members are not in “over their heads” or working on a task that is not well suited to their skills. Resource estimates may need to be revised based upon the skills of the actual person (or people) assigned to a particular activity. Figure 3-13 indicates the relative programming speed versus the relative programming quality of three programmers. The figure suggests that Carl should not be assigned tasks in which completion time is critical and that Brenda should be assigned to tasks in which high quality is most vital.
FIGURE 3-13 Trade-offs between the quality of the program code versus the speed of programming.
One approach to assigning tasks is to assign a single task type (or only a few task types) to each worker for the duration of the project. For example, you could assign one worker to create all computer displays and another to create all system reports. Such specialization ensures that both workers become efficient at their own particular tasks. A worker may become bored if the task is too specialized or is long in duration, so you could assign workers to a wider variety of tasks. However, this approach may lead to lowered task efficiency. A middle ground would be to make assignments with a balance of both specialization and task variety. Assignments depend upon the size of the development project and the skills of the project team. Regardless of the manner in which you assign tasks, make sure that each team member works only on one task at a time. Exceptions to this rule can occur when a task occupies only a small portion of a team member’s time (e.g., testing the programs developed by another team member) or during an emergency.
4. Developing a preliminary schedule. During this activity, you use the information on tasks and resource availability to assign time estimates to each activity in the work breakdown structure. These time estimates will allow you to create target starting and ending dates for the project. Target dates can be revisited and modified until a schedule produced is acceptable to the customer. Determining an acceptable schedule may require that you find additional or different resources or that the scope of the project be changed. The schedule may be represented as a Gantt chart, as illustrated in Figure 3-11, or as a Network diagram, as illustrated in Figure 3-14. A Network diagram is a graphical depiction of project tasks and their interrelationships. As with a Gantt chart, each type of task can be highlighted by different features on the Network diagram. The distinguishing feature of a Network diagram is that the ordering of tasks is shown by connecting tasks—depicted as rectangles or ovals—with its predecessor and successor tasks. However, the relative size of a node (representing a task) or a gap between nodes does not imply the task’s duration. We describe both of these charts later in this chapter
5. Developing a communication plan. The goal of this activity is to outline the communication procedures among management, project team members, and the customer. The communication plan includes when and how written and oral reports will be provided by the team, how team members will coordinate work, what messages will be sent to announce
FIGURE 3-14 A Network diagram illustrates tasks with rectangles (or ovals) and the relationships and sequences of those activities with arrows.
Foundations for Systems Development
the project to interested parties, and what kinds of information will be shared with vendors and external contractors involved with the project. It is important that free and open communication occurs among all parties, with respect for proprietary information and confidentiality with the customer. When developing a communication plan, numerous questions must be answered in order to ensure that the plan is comprehensive and complete, including:
- Who are the stakeholders for this project?
- What information does each stakeholder need?
- When, and at what interval, does this information need to be produced?
- What sources will be used to gather and generate this information?
- Who will collect, store, and verify the accuracy of this information?
- Who will organize and package this information into a document?
- Who will be the contact person for each stakeholder, should any questions arise?
- What format will be used to package this information?
- What communication medium will be most effective for delivering this information to the stakeholder?
Once these questions are answered for each stakeholder, a comprehensive communication plan can be developed. In this plan, a summary of communication documents, work assignments, schedules, and distribution methods will be outlined. Additionally, a project communication matrix that provides a summary of the overall communication plan can be developed (see Figure 3-15). This matrix
FIGURE 3-15 The project communication matrix provides a high-level summary of the communication plan.
can be easily shared among team members, and verified by stakeholders outside the project team, so that the right people are getting the right information at the right time, and in the right format.
6. Determining project standards and procedures. During this activity, you specify how various deliverables are produced and tested by you and your project team. For example, the team must decide on which tools to use, how the standard SDLC might be modified, which SDLC methods will be used, documentation styles (e.g., type fonts and margins for user manuals), how team members will report the status of their assigned activities, and terminology. Setting project standards and procedures for work acceptance is a way to ensure the development of a high-quality system. Also, it is much easier to train new team members when clear standards are in place. Organizational standards for project management and conduct make the determination of individual project standards easier and the interchange or sharing of personnel among different projects feasible.
7. Identifying and assessing risk. The goal of this activity is to identify sources of project risk and to estimate the consequences of those risks. Risks might arise from the use of new technology, prospective users’ resistance to change, availability of critical resources, competitive reactions or changes in regulatory actions due to the construction of a system, or team member inexperience with technology or the business area. You should continually try to identify and assess project risk. The identification of project risks is required to develop PVF’s new Purchasing Fulfillment System. Chris and Juanita met to identify and describe possible negative outcomes of the project and their probabilities of occurrence. Although we list the identification of risks and the outline of project scope as two discrete activities, they are highly related and often concurrently discussed.
8. Creating a preliminary budget. During this phase, you need to create a preliminary budget that outlines the planned expenses and revenues associated with your project. The project justification will demonstrate that the benefits are worth these costs. Figure 3-16 shows a cost-benefit analysis for a new development project. This analysis shows net present value calculations of the project’s benefits and costs, as well as a return on investment and cash flow analysis. We discuss project budgets fully in Chapter 4.
9. Developing a project scope statement. An important activity that occurs near the end of the project planning phase is the development of the project scope statement. Developed primarily for the customer, this document outlines work that will be done and clearly describes what the project will deliver. The project scope statement is useful to make sure that you, the customer, and other project team members have a clear understanding of the intended project size, duration, and outcomes.
10. Setting a baseline project plan. Once all of the prior project planning activities have been completed, you will be able to develop a baseline project plan. This baseline plan provides an estimate of the project’s tasks and resource requirements and is used to guide the next project phase— execution. As new information is acquired during project execution, the baseline plan will continue to be updated.
At the end of the project planning phase, a review of the baseline project plan is conducted to double-check all the information in the plan. As with the project initiation phase, it may be necessary to modify the plan, which means returning to prior project planning activities before proceeding. As with the Purchasing Fulfillment System project, you may
FIGURE 3-16 A financial cost-benefit analysis for a systems development project.
submit the plan and make a brief presentation to the project steering committee at this time. The committee can endorse the plan, ask for modifications, or determine that it is not wise to continue the project as currently outlined.