Project Management

Introduction

The role of the software engineer (SE) differs from the project manager in that the SE provides technical expertise, while the project manager provides organizational expertise. Depending on the size of an organization and project team, one person might perform both roles. Small project teams (Le., less than five people) and organizations with limited software development staff (Le., less than 10 people) expect one person to assume both software engineer and project manager roles. The larger the organization, the more likely the functions are split and the more extensive each person's experience is expected to be. 

The project manager and software engineer are responsible for tasks that include both complementary and supplementary skills. In general, the software engineer is solely responsible for management of the life cycle, including the following areas detailed in Chapters 4 through 14:

• Management and conduct of development process 
• Development of all documentation 
• Selection and use of computer-aided software engineering (CASE) tools 
• Elicitation of user requirements 
• Technical guidance of less skilled staff
• Assurance that representation techniques, such as data flow diagrams, are correct, consistent, and validated 
• Oversight of technical decisions 
• Assurance that constraints (e.g., two-second response time) are identified and planned as part of the application

Complementary activities are activities that are performed jointly but with different emphasis depending on the role. Complementary activities include planning the project, assigning staff to tasks, and selecting from among different application alternatives. 

The project manager (PM) is solely responsible for organization liaison, project staff management, and project monitoring and control. These major responsibilities are discussed in this chapter.

When one person or another is identified as solely responsible for some activity, it does not mean that they alone do the work. The SE and PM are team leaders who work together in all aspects of development. The SE may have project management experience. Sole responsibility means that when a disagreement occurs, responsibility for the final decision rests with the responsible person. Different management styles determine how open a manager is to suggestion and discussion of alternatives. A short discussion of appropriate behaviors for project managers is also included in this section. These behaviors are the project manager's responsibility toward the project. 

FIGURE 3-1 Example of Too General a Plan

First we discuss the joint SE and PM activities. Then we discuss activities for which the project manager is solely responsible. Management styles and a brief discussion of project manager responsibilities to the project team are included in the section on personnel management. The last section lists computer-aided support tools for project management.

Source: Sue Conger, https://resources.saylor.org/CS/CS302/OER/The_New_Software_Engineering.pdf
This work is licensed under a Creative Commons Attribution 3.0 License.

Complementary Activities

Joint activities of the software engineer and project manager include project planning and control, assigning staff to tasks, and selecting from among different alternatives for the application.

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.

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 databases, 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.

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). 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 weighs the most likely, realistic time by a factor of two in relation to the other estimates.

While times are 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

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

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.

Assigning Staff to Tasks

Task assignment is fairly straightforward. The major tasks are to define the tasks and skills needed, list skills and availability of potential project members, and match people to tasks. The project manager and SE actually begin discussing possible project staff when they are planning the project and tentatively assigning people to tasks. Then the project manager's real work begins. 

The hard part of an assignment is the judgment required to match people whose skills are not an exact match for those needed; this is the usual case. For instance, you might want two programmer analysts with the following list of skills:

• design and programming experience on a similar application 
• three to five years experience in the operational environment 
• one to two years of experience with the database software 
• managerial experience for two to four people 
• known for high quality work 
• known as an easy-going personality

Suppose your manager gives you a junior programmer right out of a training program, an analyst who does not program and who has no operational environment, database, or managerial experience, and a senior programmer who does no design, is known to be difficult, and sometimes does high quality work. 

The good news is that you have three people instead of two. The bad news is no one of them has all of the qualifications you want. What do you do? This is what management is all about.

The project manager should get to know the team members well. This means assessing their position with the company, expectations on the project, specific role desired for the person, possible start and end dates for work, and personality or personal issues that might affect their work. Much of this information can be got from previous performance reviews. But nothing substitutes for discussing the information with the person. 

The project manager has responsibilities to his or her manager, the client sponsor, and to the rest of the project team to get the best, most qualified people possible. In these capacities, the project manager honestly discusses previous problems with the person, any personal problems that might detract the person's attention from work, and any outside jobs, school, or other commitments that might also hinder their commitment. The person and the project manager both should be given an opportunity to accept or reject the possibility of work. Even when there is no choice, it is also the responsibility of the project manager to make his or her expectations of quality and quantity of work clear. If the person will not report directly to the project manager, the person she or he will report to should also be at the meeting. In this way, everyone knows exactly what was said and what commitments were (or were not) made. 

The answer to the task assignment problem above is to assign the tasks to best fit the skills. Assign the senior person responsibility for the work of the junior one, and provide motivation and incentives for quality work (see the following section on motivation). You also alter the schedule, if needed, to more closely mirror the actual skills of the team.

The heuristics, or rules of thumb, for personnel assignment are as follows:

1. Assign the best people to the most complex tasks from the critical path. Assign all critical path tasks. As the experience and skill levels of people decrease, assign less complex and smaller tasks. Do not give new, junior, or unqualified staff any tasks on the critical path. Assignment of senior people to critical tasks minimizes the risk of missing the target date. 

2. Define a sequence of work for each person to stay on the project for as long as their skill set is needed. Try to assign tasks that provide each person some skill development. 

3. Do not overcommit any person by assigning more tasks than they have time. Make sure each person will be busy, but allow time to finish one task before beginning another. 

4. Allow some idle time (2-5%) as a contingency for each person. Do not allow more than eight sequential hours (i.e., one day) of idle time for any person. 

5. Do not schedule any overtime. Scheduled overtime places unfair stress on people's professional and personal commitment and is a regular enough occurrence in development that it should not be scheduled at the outset.

The project manager is also responsible for coordinating movement from another assignment to the current development project. This coordination is done with the other project manager(s) involved and possibly the personnel department. New hires should be assigned a 'buddy' to help them get familiar with the company, its facilities, the computer environment, policies, and procedures. Senior staff should be assigned to mentor junior staff, encouraging the learning of new skills on the job. 

Finally, the project manager must ensure that each person understands the expectations and duties assigned to him or her. All staff should have a copy of their job description. They should know the extent of their user interaction, extent of their intraproject responsibility and communication, and policies about chain-of-command on who to go to with problems, project errors found, or problems with work assignments. 

Ideally, the team should be given an overview of the application, a chance to review the schedule, and an opportunity to comment on their ability to meet the deadlines assigned. If they cannot meet the deadlines and have reasonable explanations, the plan, schedule, and budget should be changed. In addition, any training or learning on-the-job that is required should result in a lengthening of the schedule. If the team members agree to the schedule, then they are committed to getting the work done within the time allowed and should be held accountable for that as part of their work assignment.

Selecting from Among Different Alternatives

 Applications all have alternatives for implementation strategy, methodology, life cycle, and implementation environment. The project manager and SE together sort out the options, develop pros and cons, and decide the best strategies for the application.

Implementation Strategy 

Implementation strategy is some mix of batch, on-line, and real-time programming. The decision is based on timing requirements of users for data accuracy, volume of transactions each day, and number of people working on the application at any one time. All of these numbers are estimates at the planning stage of an application, and are subject to change. The strategy decision might also change. In general, though, a decision can be made at the feasibility stage to provide some direction for data gathering.

As Table 3-2 shows, the timing of data accuracy drives the decision between batch and on-line. Keep in mind that these are rules of thumb and need to be used in an organizational context. If data can be accurate as of some prior period, a batch application might be developed. If data must be accurate as of some time of the business day, either on-line or real-time strategies would be successful.

TABLE 3-2 Decision Table for Implementation Strategy Selection

If the volume of transactions divided by the number of people is very high (over 60 per minute), then a high-performance application, with many concurrent processes, that is, a real-time application, might be warranted. 

If the volume of transactions divided by the number of people is low (less than 25 per minute), but the timing requires on-line processing, an on-line application is best.

The gap in transactions per minute from 10 to 60 requires more information, specific to the project, for a decision. Answers to several questions are needed. For instance, how complex is a transaction? How was the number of workers arrived at, and can the number change? Is management willing to fund the difference in cost for a real-time application over an on-line one? Are there other factors (e.g., specific database software to be used) to consider in the decision? These questions are all context specific and the resulting decision would be determined by their answers.

Implementation Environment 

The implementation environment includes the hardware, language, software, and computer-aided support tools to be used in developing and deploying the application. The decision is not final at the feasibility and planning stage, rather the alternatives and a potential decision are identified. The issues to be resolved for a final decision are then identified. 

Frequently there is no choice of implementation environment. The organization has one environment and there are no alternatives; all development uses one mainframe and one language (for instance, COBOL). More often, as personal computers and local area networks become more prevalent, the alternatives are mainframe or network with PCs as the workstation in the chosen environment.

The decision is based frequently on the experience of the project manager, SE, and potential team members. People tend to use what they know and not use what they do not know. Ideally, the implementation environment should be selected to fit the application, not the skills of the developers.

TABLE 3-3 Decision Table for Implementation Environment

For instance, if a real-time application is being built for a Sun workstation environment under Unix operating system, C++ or Ada are probably the languages of choice. Certainly, Cobol is not a choice. 

Guidance in implementation environment selection comes from the user. Do they have equipment they want to use? How is it configured? What other software or applications are on the equipment? How amenable is the user to changing the configuration to fit the new application? 

Then, with this information, the decision table in Table 3-3 can be used as a guideline for selecting the implementation environment.

In general, whenever there is a specific requirement, it tends to drive the remaining decisions. Whenever there are general requirements, the decision can remain open for a longer time. Some direction-either toward a mainframe solution or a PC/LAN solution-should be tentatively decided during feasibility and planning. During this process, the project manager should identify the issues for further information needed in making a final decision.

Methodology and Project Life Cycle 

The final issue to be tentatively decided is which methodology and how streamlined the life cycle will be. Frequently, there is no choice about these decisions, either. The organization supports one methodology and one life cycle and there is no discussion allowed. Enlightened managers know that not all projects are the same, therefore the development of the projects should also not be the same.

TABLE 3-4 Decision Table for Methodology and Life Cycle Selection

Methodology choices are process, data, object, social, semantic, or some hybrid of them (see Chapter 1). Life cycle choices are the sequential waterfall, iterative prototyping, or learn-as-you-go (see Chapter 1). These decisions are not completely separated from those of the implementation environment in the previous section, because any fixed implementation requirements can alter both the methodology and the life cycle choices. 

Assuming no special implementation requirements, the application itself should be the basis for deciding the methodology. In a business environment, the rule of thumb is to choose the methodology that addresses the complexity of the application best. If the complexity is procedural, a process method is best. If the complexity is data related, a data methodology is best. If the problem is easily broken into a series of small problems, an object method might work best. If the project is to automate expert behavior or includes reasoning, a semantic methodology is best. A decision table summarizing heuristics on deciding methodology and life cycle is shown as Table 3-4.

Life cycle choice also requires some decision about what type and how much involvement there is of users. If some intensive, accelerated requirements or analysis technique is used, either a streamlined sequential lifecycle or an iterative approach can be used. Very large, complex applications with known requirements usually follow a sequential waterfall life cycle. If some portion of the application requirements, software, language - is new and untested, prototyping should be used. Object orientation assumes prototyping and iteration. If the problem is a unique, one-of problem that has never been automated before, either a learn-as-you-go prototyping or an iterative life cycle would be appropriate.

In the next sections, the activities for which the project manager has sole responsibility are detailed. These activities include liaison, personnel management, and project monitoring and reporting.

Liaison

The project manager is a buffer between the technical staff and outside organizations. In this liaison role, the project manager communicates and negotiates with agents who are not part of the project team. A liaison is a person who provides communications between two departments. Examples of outside agents include the project sponsor (who mayor may not be the user), IS managers, vendors, operations managers, other project managers, and other departments such as quality assurance (for validation and testing), law (for contracts), and administration (for clerical and secretarial support). 

For each type of liaison, status reports are an important means of communication (see sample in Figure 3-6). Status reports document progress, identify problems and their resolution, and identify changes of plans to all interested parties. In addition, many other communications of different types are described for each type of liaison. The guidelines here are just that - guidelines. They are developed assuming that open communications between concerned parties is desired, but the guidelines require judgment and knowledge of the situation to separate a good action from a less good action.

Project Sponsor

The sponsor pays for the project and acts as its champion. A champion is one who actively supports and sells the goals of the application to others in the organization. A champion is the 'cheerleader' for the project. 

The goals of liaison with the champion are to ensure that he or she knows the status of the project, understands and knows his or her role in dealing with politics relating to the project, and knows the major problems still requiring resolution. 

The major duty of the champion is to deal with the political issues surrounding the project that the project manager cannot deal with. Politics are in every organization, and politics relate to organizational power. Power usually is defined as the ability of a person to influence some outcome. One source of power comes from controlling organizational resources, including money, people, information, manufacturing resources, or computer resources. 

Political issues of application development do not relate to the project, but to what the project represents. Applications represent change. Changes can be to the organization, reporting structure, workflow, information flow, access to data, and extent of organizational understanding of its user constituency. When changes such as these occur, someone's status changes. When status changes, the people who perceive their status as decreasing will rebel.

The rebellion may be in the form of lies told to analysts, refusal to work with project members, complaints about the competence of the project team, or any number of ways that hinder the change. If the person causing trouble is successful, the project will fail and his or her status will, at worst, be unchanged. Politics, left unattended, will lower the chances of meeting the scheduled delivery date and raise the risk of implementing incorrect requirements. The project manager usually tries to deal with the political issues first, keeping the sponsor informed of the situation. If unsuccessful, the sponsor becomes involved to resolve the problem. 

In some organizations, the project manager communicates to the sponsor only through his or her manager. In others, the project manager handles all project communications. In general, treat the sponsor like your boss. Tell him or her anything that will cause a problem, anything they should know, and anything that will cause the project delays.

User

The user is the person(s) responsible for providing the detailed information about procedures, processes, and data that are required during the analysis of the application. They also work with the SE and project manager in performing the feasibility analysis, developing the financial and organizational assessments of user departments for the feasibility study.

FIGURE 3-6 Sample Status Memo and Report

Project manager-user communication includes both planned and unplanned status meetings, written communications for status, analysis, interview results, documentation, and walk-throughs of application requirements as specified by the project team. Timing of user communications differs with the type of communication, but is most often daily until the application begins programming and testing. Then, a minimum of weekly personal contact should maintain the relationship. 

In general, tell the user everything that might affect them, the project, or the schedule negatively; do not tell them anything else.

IS Management

IS managers, like most managers, want to know progress, problems and their solutions, warnings of lateness, and political issues. They do not want to handle all problems for their managers, nor do they appreciate finding out a project will be late the week before it is due. Tell your manager anything that might get him or her in trouble, that they need to know, or that might impact the project negatively. Always expect to propose solutions and argue if you think your solution is better than theirs. Always accept their solution if it is mandated, unless it is unethical or illegal.

Technical Staff

Technical staff here means the project team. Always be open with them. Keep them current on progress, problems and resolutions, and any information that affects their ability to do their job. Praise quality work. Practice team building using common sense, like having small victory parties at the end of phases, sharing birthdays, or announcing promotions.

Operations

Operations affect the project differently depending on the phase. In early phases, word processing and PCs must be available for documentation. Computer-aided software engineering tool access might be required. Timing, type, and needs of access should be planned and negotiated well in advance. The kinds of problems a team might suffer from no access may delay documentation but does not delay the work of analysis. In the worst case, the work can be done manually. 

During design, the database administrator must have access and resources allocated for the definition and population of a test database. This must also be negotiated well in advance.

During implementation, old data must be converted to the new format and environment, programs must be placed in production, and users begin using the application. At this time, the operations department assumes responsibility for running the application. This responsibility must also be planned and negotiated in advance. 

When programming and testing begin, all project members need access to compilers, test database, editors, and, possibly, testing tools to work on their programs. Absence of resources at this time can severely delay project completion. For each day of person-time lost, there can be one day of project delivery time lost. Timing, type, and volume of access are all negotiated items. Advance negotiation should begin at least one month prior to the need. Most operations managers will tell you they want to know about a demand for their resources as soon as you can identify the demand and the date needed. Most operations managers will also tell you they want all requirements at once. So you should be prepared to discuss analysis, design, and implementation needs before much work takes place.

In general, operations managers need to know what the project needs from them and when. They also should be sent progress reports and told of any problems that affect the use of their resources.

Vendors

A vendor is any company, not your own, from which you obtain hardware, software, services, or information. If the application is installed in an existing environment, probably no vendor contacts are needed. If, however, acquisition of software, hardware, or both is planned, there are three types of contact with the vendor that take place. The first is proposal communication, the second is for negotiations, and the last is customer support.

A Request for Proposal (RFP) is a document developed by the PM and SE to solicit bids from potential vendors. Vendors are asked to respond with an estimate of service and price within some number of days (e.g., 30). All bids received by the cut-off date are reviewed. Proposal communications are usually limited to information about the proposal. RFPs are accepted and responded to by vendor marketing staff with some technical assistance. Project manager contact is with the marketer. 

Part of the RFP process is the development of a list of required features for the item being bid upon. This list should have priorities and weights assigned to it during the proposal stage for use during the analysis. Bids are rated on the requirements then compared to see which vendor most closely meets the needs of the application. 

When a vendor is selected, a contract must be negotiated. Negotiation may be with the marketer, but might also be with a financial person or with the marketer's manager. Similarly, the project manager might do all or some of the negotiation with assistance from a financial person or his or her manager. Negotiations deal with price, time period of the contract, number of sites, number of users, type of license, guarantees in case the vendor goes out of business, warrantees, and so on. There is no one way to negotiate, and most often, all negotiations are turned over to legal staff for completion of contract terms. It is important never to commit to any terms until they are seen and approved by some manager in the organization. Frequently, contracts have far-reaching implications that an individual project manager may not know.

Other Project Teams and Departments

Other IS organizations that might need project communications include a database administration group, other project teams, and a quality assurance group. Other departments might include law, or audit. In all cases, the communication is similar. These groups need to know what their relationship to your project is, how soon and what type of support you need, who to contact for questions and information, and project status that might change any of these requirements. 

In addition, you also have the needs of these teams. If any of the organizations is performing work you need to complete your project, then you need the same things from them that they need from you. You need to know exactly what they will do for you and how it will be transmitted to your project, whom to contact, and task status that might affect your schedule. 

To summarize, many other groups and departments in the organization need to have liaison activities with a project. It is the project manager's job to provide that liaison with communications tailored to the needs of the other organization.

Personnel Management

For personnel management, the project manager hires, fires, coaches, motivates, plans, trains, and evaluates project team members.

Hiring

Hiring is usually coordinated through a personnel office that oversees all IS hiring, not just one project. Newspaper advertisements can be more cost-effective, general, and get a better response when coordinated for all projects. The personnel office receives the responses and filters obviously unqualified applications out from the pool of applicants. Then, working with the project manager, the personnel department screens the applicants and arranges project interviews. 

As in most things, timing is important. Ads take from one to two weeks to get approved and placed. Receipt of resumes usually takes the same amount of time. Interviewing is time consuming and can take another one to two weeks for each hire. Then, offers are made and salary negotiations completed. The elapsed time to hire someone might be seven weeks or longer. 

In addition, scheduling interviews may mean early-morning, evening, or lunch-time work. People searching for a job who already have one may not want to take vacation time for an interview. If the person appears qualified, the project manager is expected to shift his or her schedule to fit the needs of the applicant.

Firing

You may not agree, but keeping a person in a job for which they are unsuited does more damage to the manager, the person, and the project than you might think. Project managers are damaged because they think of little else and agonize over the decision much longer than necessary. People usually know if they are going to be terminated because they did not complete their specified tasks. They should have been told, in writing, before the termination date. 

Prolonging a termination is damaging to the person being fired because it gives them a false sense of hope, makes them lose confidence in the person not following through on their described actions, and also allows them to influence other project members negatively.

Finally, procrastination on firing is damaging to the project because the longer the termination is delayed, the more likely the person being terminated will begin talking of his or her situation to other project members and disrupting work. As more people find out, more time is spent speculating on the situation. Less work gets done and the staff eventually loses confidence in the project manager. 

No one gets into trouble overnight. Usually there is a period during which a problem is known, but it might be corrected before any real problems arise. It is at this time that the project manager should sit down with the person and talk about the situation. Legally, everyone in this situation is entitled to at least one warning letter which is also placed in their personnel file. This is followed by a letter of reprimand stating that performance is substandard with reasons for that judgment. The letter also states that the person is on probation and will be terminated by a specified date unless some actions are taken. The actions are then listed. If the person does the assigned work satisfactorily, they are off probation. All of these communications are in writing, monitored, and approved by personnel and the IS manager, and are the basis for any future legal action by the employee. 

If the work is performed satisfactorily, probation ends. If not, the person is terminated. Termination from a project does not necessarily require termination from a company. If a person is ill-suited to a particular project, she or he might still be a valuable employee. A good project manager will first try to place the person somewhere else in the organization. If the person is terminated from the company, the company can try to help them find another job through an out-placement service or by providing company resources (a desk and phone away from the project) until a job is found. If the person is terminated for antisocial behavior, an addiction, or for some other nontechnical problem, the project manager might help them seek professional help.

Motivating

Motivation has personal and professional aspects. Professional motivation arises from a desire to do a good job. People are motivated to do a good job when they are treated like a professional and given meaningful, interesting work that includes some discretionary decision making and some creative design. 

Personal motivation arises from a desire to improve one's position in life. Position in life is defined individually and may mean earning more money, buying a bigger house, becoming an analyst, or becoming a manager, and so on. 

Project management style is the determining factor of personal motivation. A project manager who facilitates participation, fosters controlled risk-taking, and allows people to grow as individuals will gain undying loyalty from his or her staff. A project manager who treats the staff as stupid, lazy, and unmotivated might obtain desired behaviors from them, but it will be through intimidation and coercion. 

The project manager needs to know the project team members individually in order to tailor reward systems and assignments to help them reach their goals. Project manager commitment to helping team members reach personal goals determines how professionally motivated the team members will be. 

There are three aspects to motivation. First, the project work itself can be used to further professional goals that include doing novel work and advancing to new levels of seniority, experience, or responsibility. Second, the project manager must be careful to tailor reward and punishment systems to fit the tasks, being unbiased in terms of importance of individual contributions to the work. Third, the individual professional must make a commitment to doing something extra to gain the reward, either on-the-job or on his or her own time. 

Take, for instance, a mainframe Cobol programmer who wants to move to a personal computer LAN environment using C++. The project has relaxed deadlines and the project manager might be able to help the person, but some commitment from the programmer is needed. The project manager recommends that the person find, attend, and pass a C++ course for which the company will pay. Then, the person will be assigned a task in the desired environment. If the task is successful, more tasks will follow. If the task is not successful, the situation will be reassessed.

Professional motivation might also come from fostering development of association ties outside of work. Meetings or user groups of vendors, professional associations,2 or other professional groups related to work duties might be paid for by the company to foster professional motivation. 

Motivation also has a negative side. The actions that would be taken should the person fail to do their job competently must also be known. There should be company policies about quality and quantity of work that are also included as part of job descriptions. In the absence of company policy, the project manager should adopt rules, with the knowledge and consent of their manager, about punishments for failure to meet work requirements. These should also be made known to everyone on the project.

Career Path Planning

Motivating is an immediate activity of the project manager, but all employees and managers should be encouraged to develop longer range aspirations, as well. The project manager should help plan, with each individual, the tasks from this project that can be used to further his or her career. 

The project manager should discuss goals and career paths at the beginning of the project and at least annually during performance reviews after that. The discussion should include a frank assessment of current perceptions of the individual's verbal, organizational, and professional skills, as well as helping the person plan courses, assignments, or opportunities to improve his or her performance. There should be direct ties from performance to rewards. Any time an individual does something significant enough to be mentioned on an appraisal, he or she should be told and either praised or counseled to change.

Training

The purpose of project training is to specifically address weaknesses of staff in techniques, technology, or tools used on the project. The SE and any project leaders are directly responsible for identifying training needs. The project manager is responsible for obtaining the training for the individual(s) who need it. A senior mentor for the trained skill should be assigned to monitor progress in the development of the skill, once training is complete. 

Additional unrelated training, as discussed above, may also be authorized by the project manager depending on employee needs, rewards, and fit with employee goals.

Evaluating

Evaluations are annual assessments of the person from both professional and organizational perspectives. Evaluations are written and usually are signed by the reviewed person and the reviewer. Quality and quantity of work assignment are the professional assessments and are the most important aspects of junior level work. Junior staff, having no business experience, are monitored most closely for their ability to do their work. Competence for the assigned jobs is determined, and the more competent, the faster the person is promoted. 

As people become more senior, quality and quantity of assigned work becomes assumed and organizing, motivating, communications, and interpersonal skills become more important. The non task specific skills are viewed from an organizational perspective. More emphasis is placed on the ability to persuade, manage, motivate, and communicate with others, thus describing a good manager.

Promotion for most senior people is to the managerial ranks. In some companies, the importance of very senior technical experts is recognized. In those companies, equal emphasis is placed on the professional and organizational assessments. Technical staff can aspire to the senior technical positions without having to sacrifice their technical expertise in the bargain. 

The usual performance evaluation contains sections for assignments, communications and interpersonal relations, absences, planning and organization, supervision, delegation, motivation, training, and special considerations. Each of these is described briefly.

The assignments section contains a brief description of four or five major assignments with expectations on quality and quantity of work for each as well as a brief paragraph assessing the extent to which the assignment was met. Quality and quantity of work are intangible and frequently subjective assessments, but there are always expectations of the amount of work a person should do, and of the extent to which reworking is needed. In addition, the individual's job description should give guidance on expectations for work quality and quantity. Finally, the extent to which the person needs to be monitored and assisted is an indicator of the extent to which they can work independently and competently at their job. The discussion of quality and quantity should be presented in terms of job description, manager expectations, and extent to which expectations are met. Specific examples are required to demonstrate very high and very low quality work.

Project managers evaluate communications and human relations. Assessments of both relating verbal and written communication skills are developed. Communication skills are related to specific project assignments and to other project activities, such as walk-throughs, that are not major assignments. Communication evaluation includes grammar, speed, persuasiveness, clarity, and brevity. The person's ability to develop and deliver a presentation, and actual experiences doing these are described. 

Another area of assessment is interpersonal relationships with project managers, senior staff members, peers, others in the department, and users. Additional comments might discuss specific incidents that vary from the general assessment and that might highlight a need for improvement, or identify a particular skill. For instance, a person with good negotiating skills might be identified by their arbitration of a disagreement between two other project members.

Work absences are mentioned in terms of total days missed, number of absences, and type of absence. If there are company policies about absences and they are exceeded, a comment about the extent to which absences affected work might be added. The ability of the person to meet deadlines, maintain an accurate status of the project, and need special communications due to absences are all described. Extraordinary situations causing a long absence, such as emergency surgery, are included. 

For planning and organization, accuracy, detail, independence of work, and cooperation with other affected groups are all assessed. In addition, the person's adherence to their own plans is discussed. Do they use it properly as a road map, or is it a rigid rule from which no straying is allowed, or is it ignored and treated as a task done for management?

Delegation is the extent to which the work is shifted from the manager to subordinates. Issues rated are how well work assignments match people's skills, allow monitoring to ensure completion, provide for personal and career improvement of subordinates. 

Managerial style is assessed in terms of group motivation. Does the project manager obtain commitment from staff with enthusiasm, discomfort, unhappiness, or anger? Does the manager ask or command? How successful is the strategy and what must the manager do to change unsuccessful strategies? Are tactics altered to fit the person being managed, or is everyone treated the same way? Are people treated fairly or is favoritism prevalent? 

Can the manager motivate others to learn new skills? To what extent does the manager provide needy staff with training, either formal or informal, on techniques, technology, and tools? If formal training is given by the person being rated, summaries of student ratings of quality and quantity of training should be presented. The person's ability to provide mentoring and quality of mentoring might be addressed.

Finally, there is usually a section for the project manager to recommend future assignments, training, or other professional activities for further development of the individual.

Monitor and Control

Status Monitoring and Reporting

Status Monitoring and Reporting 

The rationale of the planned application development is that you monitor the plan to communicate activity status and interim checkpoints to clients. The overall goal-meeting the project installation date-is the end point of a lengthy complex set of processes. Without the plan, knowing whether or not the installation date will be met is difficult. Status monitoring is the comparison of planned and actual work to identify problems. Project control is the decisions and actions taken based on the project's status. 

In a planned approach, project team members report time spent on each activity for some period. The sample timesheet (see Figure 3-7), allows breakdowns for several tasks listed across the top of the form and hours worked on the task reported by day of the month. Totals by day of the month and by task over the period are tallied by row and column totals. This type of reporting allows the project manager to easily see for each person weekend work, how many hours are spent on each activity over a period, and how many effective work hours there are per day. 

In addition, each person should write a short progress report. The report summarizes progress in qualitative terms, identifies problems, issues, errors, or other conflicts that might delay the work. If a task will be completed later than its scheduled date, the reason for lateness must be explained. The project manager and SE both review the reports and time sheets to decide if problems need further action. A sample progress memo is shown as Figure 3-8.

The SE and project manager map actual progress of each person against the planned times. When progress looks slow, the project manager asks the person specifically if there are problems, if there are enough resources, for example, test shots, and if the person thinks they can meet the deadline. If the task appears to have been underestimated, the schedule is checked to see if changing the time allotted will cause completion delays. Similar tasks are checked to see if they are also underestimated. The cumulative effect of changes is checked to see if completion is in jeopardy. If it is, the project manager discusses the problem with his or her manager and they decide on the proper course of action. 

The best policy is to address potential problems early, before they become big problems. If a person cannot finish work because of too many assignments, then reassign some of the work to another person. If they have not got enough testing time, arrange for more time. Active management prevents many problems.

Problem follow-up includes determining the severity and impact, planning an alternative course of action, modifying the plan as required, and continuing to monitor the problem until it is resolved or no longer has an impact on the delivery date. 

Tell the client about problems that may not be solved so they are prepared for delays if they become inevitable. When changes become needed, tell the client about changes to planned dates even when they do not change the completion date.

FIGURE 3-7 Time Sheet

FIGURE 3-8 Sample Progress Report

The kinds of problems that occur and the activities the project manager monitors change over the course of the development. For instance, during the definition of the project scope, the project manager monitors the following:

• Is the client cooperative? 
• Are all the stockholders identified and involved?
• Are users being interviewed giving accurate, complete information? 
• Are users participating as expected? 
• Are there any apparent political issues to be addressed? 
• Does the scope look right? That is, does the current definition appear to include relevant activities?

By analysis, the project manager knows most users and how they work, should have identified potential political problems and dealt with them, and should be comfortable that the project scope is correct. The activities monitored turn toward the project team, and include the following:

• Do all analysts know the scope of activity and work within it?
• Is the analysts' work emphasis on what and not how?
• Are users participating as expected?
• Are all project members pulling their weight?
• Is everyone interested and happy in their job?
• Is there any friction between team members, or between team members and users?
• Does everyone know what they and all others are doing?
• Is there constant feedback-correction with users on interview results?
• Are team members beginning to understand the users' business and situation? Are the team members objective and not trying to force their own ideas on the users?
• Are walk-throughs finding errors and are they getting resolved?
• Are documents created looking complete? Does the user agree?
• Is the analysis accurately addressing the problems of the user? Are team members analyzing and describing exactly what is needed without embellishment?
• Is typing turnaround, printing of word-processed documents, copying, or other clerical support acceptable?
• Does communication between teams and between teams and users appear to be satisfactory?
• Is the project on time? What is the status of critical path tasks? Has the critical path changed because of tasks that finished early?
• Where are the biggest problems right now? How can we alleviate the problems?
• What do we not know that might hurt us in design?

The functional requirements that result from analysis should describe what the application will do. The project manager is constantly vigilant that the requirements are the users. One problem many projects have is that the user wants a plain functional application but the analysts design a high-priced application with the user functions, but with many unnecessary features, or 'bells and whistles,' as well. This problem, if it occurs, must be dealt with before analysis ends or extraneous functions will be in the resulting application. When over-design problems surface, it is important to try to trace them to specific analysts for retraining in providing their services. 

In design, the emphasis shifts to monitoring the rate, type, and scope of changes from the users. If the business is volatile, requirements change may become a constant problem. Change management procedures should be developed and used. At this point, the project manager's worries include the following:

• Do the analysts know the application?
• Is the transition to an operational environment correct and complete?
• Are walk-throughs finding errors? Are errors being resolved?
• Are users participating as expected? Are users properly involved with screen design, test
• design, acceptance criteria definition?
• Are all project members pulling their weight?
• Is everyone interested and happy in their job?
• Is there any friction between team members, or between team members and users?
• Does everyone know what they and all others are doing?
• Are all team members aware of their changing responsibilities, and are they comfortable
• with and able to do design tasks?
• Does communication between teams and between teams and users appear to be satisfactory?
• Is the project on time? What is the status of critical path tasks? Has the critical path
• changed because of tasks that finished early?
• Where are the biggest problems right now?
• How can we alleviate the problems?
• What do we not know that might hurt us in programming? Is the implementation environment suitable for this application? 
• Can the database management software accommodate this application?
  

The number of project team members usually increases for programming to do parallel development as much as possible. The communication overhead necessary to know everyone's status and for them to know the project status increases. The problems in the programming and unit testing stage tend to focus on communications and programmer performance.

• Does everyone understand how their work fits into the project? 
• Does everyone know their critical-path status? 
• Are all current project members pulling their weight? 
• Does everyone know what they and all others are doing?
• Is testing time sufficient? Is terminal access sufficient?
• Does everyone know the technologies they are using sufficiently to perform independently?
• Are junior staff paired with senior mentors?
• Are users requesting further changes?
• Are users participating as expected in test design, user documentation development, conversion, and training?
• Is there constant feedback-correction with users on suspected errors?
• Are prototypes being used as much as possible to demonstrate how the application will work?
• Are walk-throughs productive, finding errors? Are errors getting resolved?

While programming and unit testing are proceeding, tests for integration and system level concerns are being developed. The database is being established and checked out. The operational environment is being prepared. Concern shifts from getting the application expressed in code to getting it working correctly. The kinds of questions a project manager might have are the following:

• Are all current project members pulling their weight? 
• Does everyone know what they and all others are doing?
• Is testing time sufficient? Is terminal access sufficient?
• Are users requesting further changes? Are users participating as expected in testing? 
• Is there constant feedback-correction with users on suspected errors?
• Are walk-throughs productive, finding errors?
• Are errors getting resolved?
• Does the system level test really prove that the functions are all accounted for?
• Does the integration test verify all interconnections? How can it be leveraged to prove the reliability of the interconnections during the system test?
• What do we not know about the operational environment that might hurt the project?
• Is the database software working properly? Are back-up and recovery procedures adequate for testing?
• How can we use the integration and system tests to develop a regression test package?
• Is documentation being finalized? Is everyone working to capacity? Should we start letting programmers go to other projects? If we let a key person go, who can take their place when a problem occurs? 

Finally, testing is complete, the application appears ready, and the user is ready to work. There should have been a plan for actually implementing the operational application that eases the user into use without too much trauma. The easing-in period gives the project team some time to fix errors found in production without excessive pressure. The issues now center on getting the application to work in its intended environment for its intended users. The questions include the following:

• Is the site prepared adequately? Is air conditioning sufficient? Are lighting and ergonomic design sufficient? 
• Are users properly trained and ready to do work? 
• Are work cycles and evaluation of results identified sufficiently to allow implementation and verification of results? 
• When errors are found, are they getting resolved? 
• Are users taking charge as expected? 
• Are all current project members pulling their weight? Does everyone have enough work to do? Can people be freed to other projects?
• Is communication between teams and between teams and users appearing satisfactory? Are users told whenever major problems occur? Are they participating in the decision making about error resolution?

Many of the questions above are technical in nature and would be referred to the SE to monitor. The project manager is like a mother hen and is supposed to worry about everything. Obviously, if the plan addresses the activities as it should, many of the answers to the above sets of questions are found in weekly progress reports of team members. Compiling the individual progress reports and project progress reports in a project log allows the manager and any of the staff to review decisions, problems and their resolutions, and other issues as they occur during the development.

Automated Support Tools for Project Management

Project management support tools have increased in sophistication and performance since the mid-1980s when the first PC-based tools arrived. The tools in this section support project planning, task assignment and monitoring, estimation tools, and scheduling tools (see Table 3-5). Key tool capabilities not considered here include word processing, spreadsheets, calendars, or interfaces to electronic mail (these are considered useful for all organization members). Other tools that are used by a project manager but are discussed in other sections of the text are for configuration management, quality control, and metrics.

TABLE 3-5 Automated Support Tools for Project Management

Summary

The project manager role is frequently separate and distinct from that of the software engineer. The software engineer is generally responsible for technical aspects of project work. Some tasks are joint, complementary activities shared by project managers and software engineers. For these joint activities, the software engineer contributes technical skills, and the project manager contributes organizational skills.

The project manager is solely responsible for most people-related aspects of projects. The three main tasks of the project manager are organizational liaison, employee management, and project monitoring and control. Organizational liaison includes creating working relationships with other organizations and departments, resolving project-related problems regardless of their nature, and reconciling the project design with expectations of others. Employee management includes working with Personnel to hire, fire, and staff the project. Employee management also includes individual employee monitoring to help them evaluate, set, and attain career goals. Project monitoring and control is the other major project management activity. Monitoring means to trace the progress of project work and compare it to budgeted time and resources to maintain progress. Control includes deciding and implementing project changes when progress is not satisfactory. Project changes might include change of job assignments, introduction of training, or change to schedules, and plans.