Project Management
The software engineer and the project manager provide complementary skills and work collaboratively on shared activities. The three main activities of the project manager are organizational liaison, personnel management, and project monitoring and control. The "Liaison" section discusses the project manager's role as a go-between for the technical team and agents who are not members of the technical team (such as project sponsors, users, IS management, vendors, and so on).
In the "Personnel Management" section, you will learn that this job entails working with personnel and human resources to hire, fire, and provide employees with professional development.
The "Monitor and Control" section explains that project monitoring involves tracking project progress relative to budget. Project control means implementing changes when progress is not satisfactory (such as training or revising project plans).
Complementary Activities
Project Planning
To plan the project, the project manager works with the SE to determine human, computer, and organizational resources required to develop the application. While a detailed discussion of planning is included in Chapter 6, the aspects of special interest to the project manager are in this section.
A project plan is a map of tasks, times, and their interrelationships. It can be very general (see Figure 3-1) or very specific (see Figure 3-2). Neither extreme of plan is very useful although some plan is better than none. A rule of thumb for level of detail is to define activities for which a weekly review of progress allows the SE and project manager to know whether the schedule is being met. Figure 3-3 shows an example of a well-defined plan.
The general methodology of planning is as follows:
1. List tasks. Include application development tasks, project specific tasks, interface organization tasks, and review and approval tasks.
2. Identify dependencies between tasks.
3. Assign personnel either by name or by skill and experience level.
4. Assign completion times to tasks; compute the most likely time for each.
5. Identify the critical path.
FIGURE 3-2 Example of Too Detailed a Plan
The project manager and SE share responsibility for developing the plan. The SE's responsibility is to know all of the tasks relating to the application being developed; the project manager's responsibility is to ensure that all organizationally related
tasks are included in the list. (The application tasks are discussed in Chapter 6.) Organization tasks include the following:
1. Review documents for completeness, content, consistency, and accuracy. Complementary Activities 59
2. Negotiate, agree, and commit to start and end dates for work.
3. Define necessary application interfaces; plan for detailed interface design work.
FIGURE 3-3 Example of Acceptable Level of Detail
All documentation, plans, and design work of the project team is subject to review by at least the user/sponsor. Many other departments or organizations might also be required to review some or all of the work. These organizations might include managers of IS, users, quality assurance, legal, audit, operations, other application groups, government regulators, industry regulators, or others. Each organization applies its specialized knowledge to the application documents to assess their adequacy.
The second task is to obtain agreement and commitments from outside agencies or departments. Frequently, resources and work are provided by other departments. Clerical support, for example, might be from an Administrative Services Department. Operations
departments supply support in terms of computer time, memory, disk space, terminals, logon IDs, access to software environments, access to data bases, and so on as necessary to develop and test the application. Auditors frequently want to comment
on auditing plans and change the design based on their findings. Quality assurance departments might review documents to find inconsistencies and errors that" require correction. Vendors might need to install hardware, software, or related applications
that need liaison from the project team and testing once installed. All of these activities need to be scheduled and planned. Since dates for commitments might not be known when the plan IS developed, the plan contains the dates at which contact should
be initiated and dates by which the commitment must be made in order not to impact the delivery date.
Third, the project manager obtains requirements for application interfaces from other application areas. An interface is data that is sent or received between applications. The interface application areas might be in the same company, but might also be an industry group or a government organization. The plan reflects dates by which contact should be initiated and by which the information is required.
If a make-or-buy decision will be made, the project manager and SE work together to develop the subplan for this decision. Sub activities relating to acquisitions include creating and submitting requests for a proposal (RFP), obtaining vendor quotes, evaluating vendor quotes, selecting and obtaining management approval for a vendor, negotiating contract and delivery dates, and planning and testing of the acquired item.
When all of the items are identified, they are related to each other. Tasks that are related are drawn on a task dependency diagram showing the sequences of dependencies. Sequences may be interdependent (see Figure 3-4). When all sequences of tasks are on the diagram, independent tasks are added. Milestones, such as the completion of a feasibility analysis document, are shown and are visually obvious because the preceding" sets of tasks all feed into that task. Task sequencing can vary depending on the methodology used. (See Chapter 6 for more on this topic.)
Sequencing tasks is the first step to identifying the critical path of tasks for the application's development. The critical path is the sequence of dependent tasks that together take the most development time. If any of the tasks in the critical path are delayed, the project is also delayed. So, the critical path tasks are the greatest source of risk for project completion.
The next step is to estimate the amount of work. For this discussion, we assume the project manager and SE assign times to tasks based on their experience (i.e., reasoning by analogy). Other methods are discussed in Chapter 6. Times are assigned to each task based on its complexity and amount of work. Three times should be estimated: an optimistic time, a realistic time, and a pessimistic time. The formula used to compute the most likely time is shown in Figure 3-5. The figure weights the most likely,
realistic time by a factor of two in relation to the other estimates.
While times ate being assigned, the skill sets and experience levels of a person to do this task should be defined. The list of skill sets and experience levels is used to determine how many people and what type of people are required on the project for each phase. Other assumptions will surface, and a list of them should be kept, as shown in Table 3-1. The assumptions become part of the planning document.
When resource requirements and timing are complete, several activities take place. The SE develops a schedule; the project manager develops a budget. They both identify the critical path and discuss it in terms of potential problems and how to minimize their likelihood. Task definitions are made more detailed for critical tasks, to allow more control and monitoring.
FIGURE 3-4 Example of Interdependent Sequences of Tasks
(O + 2R + P) / 4 = Most Likely Time Estimate Legend: O-Optimistic Time Estimate R-Realistic Time Estimate P-Pessimistic Time Estimate |
FIGURE 3-5 Formula for Determining Schedule Time
When complete, the plan, schedule and budget are submitted to the user and IS managers for comment and approval. Work begins, if it hasn't already, with the plan used to guide project work. The plan is used by the project team to see where their work fits
in the whole project, and it is used to monitor progress toward project completion.
TABLE 3-1 Project Assumptions
Type Assumption |
Example |
Availability of configuration, component of mainframe, special hardware, programmer support equipment, tools, |
Programmers will gain access to IEW by September 10, 1994. |
User time involvement. This may be expressed in time per day for a number of days, or may be in number of days. |
A middle manager representative from Accounts Payable will be available in a Joint Application Design session scheduled for June 1-5,1994. |
Need for services from audit, law, vendors, quality |
The Audit Department will be able to review and comment on the adequacy of audit controls within 7 business days of receiving the review document. |
Software performance |
The Database Management Software will be able to process 10,000 transactions per day. |
Test time, terminal time, or test shot availability |
Batch programs can be tested simultaneously with on-line programs. |
|
Batch programs will be able to average three test runs per day with an average turnaround of less than 2.5 hours. |
|
Batch programs will be less than 160K and will require no more than two tape mounts each. |
Disk space |
Operations will make available 100 cylinders of IBM 3390 disk space for the project beginning 9/10/94. An additional 50 cyl. will be added for test databases by 10/30/94. An additional 250 cyl. will be added for production database conversion by 11/30/94. |
Memory, CPU time, tape mounts, imaging access, or other mainframe resources |
For testing, 30 CPU minutes per day plus 75 hours of terminal access time will be required beginning 10/30/94. |
Personnel |
Two senior programmer/analysts with 2-3 years of Focus experience and 2-3 years of on-line, multiuser, application development experience is required by 6/30/94. |
|
Four programmers with 1-2 years of Focus experience and one year of VM/CMS experience is required by 7/15/94. |
Hardware/software availability |
Imaging equipment will be available for application testing no later than 9/10/94. |
|
15 PCs or IBM 3279 terminals will be available for access and testing use no later than 9/10/94. |
The plan should never be cast in concrete. Plans should change when the tasks are wrong, times are underestimated, or there are changes in project scope that alter the activities performed in some way.