Project Management

"Poor management can increase software costs more than any other factor." --Barry Boehm [1981, p 486]

Objectives

 

At the end of this lesson you should be able to answer the following questions:  

1. What are the main responsibilities of the project manager?
2. What are the main elements of a project plan?
3. What are the relationships between the following project dimensions: features, staff, cost, schedule quality?
4. What are the main elements of the work breakdown structure?
5. Why aren't people and time interchangeable?
6. What is the difference between time and effort?
7. How are Gantt and Pert charts used in project scheduling?
8. What is risk management? What are the key elements of a risk management plan?            

Programming practices and their corresponding domain of application

 

Knowledge of a technical process is enough to write software systems of arbitrarily size and complexity but not necessarily in the way most software systems are written. Most software systems are written by a team of individuals according to specifications provided by an external customer. Working in teams and having an external customer adds project complexities. Working in teams requires planning and organizing the work of multiple individuals. Having an external customer requires better control over development processes. Customers understandably want to know before work begins how much the system will cost and how soon it can be done. In order to provide these estimates and then deliver on them the team needs effective project management.

Introduction

This lesson describes the basic principles and techniques of software engineering project management. The emphasis is on the unique challenges of managing software engineering projects as opposed to project management in general. The content is organized in three parts. (See figure x.)

Organization of content in this chapter

The first part explores the background and context for software engineering project management. This includes: 

• how software engineering project management is different from other types of management
• how the managerial process of software development compares and relates to the technical process of software development (requirements, design, implementation, testing, etc.)
• a discussion of the four variables of a project which are: cost, time, features, and quality. These are the fundamental constraints on a project that have to be managed.

The second part presents the main activities of project management organized around the 5 standard functions of project management:

• Planning - deciding in advance what to do.  
• Organizing - defining roles and responsibilities for the project team.  
• Staffing - filling and keeping filled roles defined by the organization structure. This includes selecting, training and developing staff as well as performance planning, appraisal, and compensation.  
• Directing - motivating individuals to achieve their potential.  
• Tracking and Controlling - tracking progress and making changes when actual results don't match what was planned.

The third and final part explains the process of risk management. Risk management is a proven technique for avoiding problems and minimizing consequences when risks do become problems.

Software Engineering Project Management

The Project Management Institute (PMI) defines a project as "a temporary endeavor undertaken to create a unique product or service." [PMI 2000] In most organizations projects are the preferred way of organizing work that is unique and different from ongoing operations.

Projects are characterized by:

1. Specific objective. Once the objective is accomplished the project is complete and the project team disbands.  
2. Schedule. Projects have a definite start and end date. This is one of the ways projects are different from ongoing operations.  
3. Budget. Like most endeavors, projects have budgetary constraints.  
4. Team of individuals working together. Teams bring together individuals with unique skills to accomplish goals that couldn't be accomplished by a single person in the same amount of time.  
5. Production of a unique product or service. Projects are set up to produce unique products or services which can't be created using existing organizational structures and ongoing operations.

Project management is a special form of management. Project management is concerned with the application of general management practices to project management. Software engineering project management is a further refinement of project management practices to deal with the special challenges of managing a software engineering project.

Relationship between Management, Project Management, and Software Engineering Project Management

Project management is different from general management in that general management is concerned with managing ongoing repetitive operations. Project management is concerned with managing temporary unique operations. Management includes long-term human resource issues such as career development, performance reviews and disciplinary actions. Project management certainly includes people issues but they are related more to the specific objectives of the project rather than the ongoing concerns of the individuals.

Much of what applies to general project management also applies to software engineering project management. However, the special characteristics of software create some unique management challenges not found with other types of projects.

First, software is intangible and largely invisible. In lesson 1 this fact is noted as one of the reasons software--the product--is complex. Software is intangible and, according to Fred Brooks, is not far removed from pure thought stuff. The problem for project management is that processes for producing pure thought-like products aren't easily measured or observed. The general contractor of a construction project can visit the job site and observe the process and see the progress being made with the product. Construction workers not wearing safety glasses, an excessive amount of scrap lumber, uneven floor joists, these are all visible signs of problems with the construction process. In construction because progress with the product is readily observable, it's unlikely a foreman will ever surprise the general contractor with news that what looked like an almost complete building yesterday is really just a hole in the ground. Both the process and product of software development is largely invisible. In order to effectively manage a software development project, both the process and product of software development have to be made more visible.

Second, the result of any project is a unique product or service but the activities of the project may be more or less routine. A contractor building homes in a new neighborhood will repeat many of the same activities of home construction for each home built. Although each home may be unique, most of the work is routine. Software development has few routine activities and includes a significant design component which requires creativity and innovation. Together these characteristics make software projects risky and less predictable than other types of projects.

And finally, software is a complex and evolving product. The technological and business environment where software is produced and used changes quickly. Because software is relatively easy to change, the software can evolve along with its environment. Software engineering project management must include explicit practices for dealing with requests for changes.

The Project Management Process

Large scale software development requires both a technical process and a management process. The technical process is a product-oriented process. It defines the activities and methods for creating the product. It includes a life cycle model and methods for performing the activities of each phase. The management process is a project-oriented process. It defines the activities and methods for planning the work, organizing and motivating those who will do the work, and tracking progress to insure the project is completed on time within budget and at an acceptable level of quality. In practice it's difficult to separate one process from the other. Their activities overlap and interact throughout the project. For example, the management process is responsible for planning and tracking activities but the activities are defined by the technical process. During a project the technical process and management process tend to amalgamate into one project process.

Even though in practice there may be one project process, this class describes the management process separate from the technical process. The reason for describing them separately is that it helps organize a sizable amount of material, and allows a presentation that caters to readers with different interests. Usually project managers and team leaders are responsible for the activities of the management process and developers the activities of the technical process. This lesson describes management aspects of the software development process that are of particular interest to project managers. Lesson 2 describes process models or life cycle models and performance of life cycle activities (analysis, design, implementation, etc) is the subject of the whole class.

Because of the tight integration between the management process and activities of the technical process, there are several dependencies between the topics of this lesson and the topics of other lessons in this class. The image below shows the main interactions between topics in this lesson and the rest of the class.

Topic Interdependencies

In general, when the performance of a project management activity relies on an activity from the technical process, the role of the technical activity in project management is described in this lesson and the performance of the technical activity is described in its own lesson. For example, quality assurance is a management function responsible for insuring that the products and processes of the project meet quality standards. Quality assurance is implemented though testing and inspections. This lesson describes quality assurance from the manager's perspective including the principles of quality assurance and how to plan and control quality assurance activities. How to perform software testing and inspections is described in lesson 17.

Project Constraints

All projects operate within the constraints of time, cost, features and quality. Just as volts, current and resistance must be balanced in an electrical circuit (Ohm's law: V=I*R), time, cost, features and quality must be balanced during a project.

Figure x. Cost, schedule, features and quality must be held in balance

In general, providing more features and/or better quality will increase costs and/or schedule. Reducing costs and or schedule will require a reduction in features and/or quality. The real challenge for a project manager is (1) being able to find a balance among these four variables, and (2) understanding the complex relationships among the constraints so that once a balance is found among the variables the customer can be provided/presented with options for making tradeoffs among the variables. For example, will twice as many features double the cost and schedule? Are there economies of scale that would make it less than twice the cost and schedule? Diseconomies of scale that would make it more than twice the cost and schedule?

Typically at the start of a project one or more of these constraints will be fixed:

• "We have to have to have it by July 1st for a conference."  
• "We have only $20K to spend."  
• "If we don't have these 15 features we can't be competitive in the marketplace."  
• "The system is life-critical so it has to be error-free."

At the start of a project it's important to understand the degree of freedom there is with each variable and what the priorities are. There is an old adage that describes the customer's options at the beginning of a project after a feature set has been decided:

You can have it fast; you can have it cheap; or you can have it good. Pick two.

This short witty saying makes two important points: (1) it's impossible to maximize all constraints, and (2) the customer can't control all of the constraints. If the customer can't or is unwilling to specify the priority among the constraints, it's up to the developers to decide what is compromised. Electrical engineers can't violate ohm's law and software engineers can't perform a project with these constraints out of balance.

These four variables and their relationships form a model for understanding the constraints on a project. Sometime the model is presented as three variables, also called the project triple constraint (see figure x.a). When presented as three variables the variable "performance" represents both features and quality. Which model you decide to apply in your project depends on your tracking and control needs. Is quality important? If you track just "performance" will there be confusion or misunderstandings about what is expected in terms of features and quality? When quality is specified and tracked as a distinct goal, quality goals are well-understood by all and there is less chance/danger that quality will be inadvertently or conveniently compromised for the sake of the more visible easier-to-measure goals of cost and schedule?

Figure x.a Project Triple Constraint

Figure x.b Four Variables of a Project

Here is a more detailed looks at the scope of each constraint.

Cost is the amount of money available to do the project. For a software development project most of the cost goes toward staff salaries. For this reason cost and effort (usually expressed in person/months) are sometimes used interchangeably. (This is especially true when salary costs are loaded or burdened with overhead costs such as facilities, equipment, etc.)  Cost may also include expenses for equipment, travel, office space, etc.

Time is the amount of calendar time available to complete the project.

Performance describes expectations for the product of the project. Performance covers both features and quality (usability, maintainability, etc). (The standard term for performance is technical performance [Cleland, PM]. Tech performance and quality are defined in req doc; cost and time in project plan. ) In the context of a project, cost is a constraint on inputs, performance is a constraint on expected results, and schedule is a constraint on the amount of time available to complete the project.

Relationship between a project and its constraints

Other engineering disciplines have mathematical formulas that model the real-world entities of interest to engineers working in that discipline. A good candidate for the fundamental "formula" of software engineering is the relationship between the four variables of a project.

The following equation expresses the general relationship between the four variables of a project:

Features * Quality = Cost * Time

The equation lacks the rigor of a mathematical formula because it omits important attributes that influence the relationship between these four constraints. For example, the equation doesn't take into consideration the motivation of the staff, the maturity of the process, or technologies employed. Another obvious problem is quantitatively measuring attributes of performance such as functionality and quality. (And, measuring in units that are compatible.)

Even though the equation doesn't have the accuracy and precision of say Ohm's Law, it does express the general balance that must be maintained between these three constraints. The equation says that a certain level of performance requires a certain combination of cost and time. When one of the parameters changes, one or both of the others needs to change with it. Here are two scenarios predicted by the equation. (1) If the time allocated for a project decreases, then performance needs to decrease, cost needs to increase, or both. (2) If the performance expectations of a project increase, then the cost and/or time must increase too.

The equation shows the relationships between these parameters as linear, but in practice their relationship is nonlinear. The figure below illustrates more accurately the relationship between time and cost assuming performance is held constant.

The image above suggests that the cost of shortening the schedule escalates quickly, and there is a point beyond which no project of a certain size has ever been completed. Schedule compression requires an increase in staff to perform more work in parallel. The extra effort for communication and coordination increases more than linearly with the increase in staff size. Also, certain tasks have to be performed in sequence (you can't design a program until you have its requirements) which is another reason there is a lower bound on time.

It's important to know where the impossible region is so you can avoid it. That is, not sign up for any projects with values for cost, time, and performance that are impossible. The best way to know what's impossible for the specific types of projects in your environment is by keeping historical measurement data on completed projects.

The relationship between performance and the other two parameters also tends to be nonlinear. The figure below shows the relationship between performance and time assuming cost is held constant.

The figure above is somewhat unrealistic because in practice increasing performance requirements tends to increase both time and cost. It's difficult to compensate for performance increases with time along. Increasing schedule alone does allow staff to work more efficiently, but it's usually not enough to balance more than small increases in performance.

The image does accurately reflect the relationship between performance and schedule. As performance requirements grow, the amount of extra time needed grows more than linearly (even when costs are allowed to rise). This is true whether the increase in performance is an increase in features or an increase in quality. As features are added to a specification the complexity of the overall system, and consequently the time required to implement it, grow more than linearly with the number of features added. Quality performance increases don't fair much better. Removing the last few bugs of any system is extremely expensive. NASA spends about $3.5 million a year just for testing the approximately 476KLOC that make up the primary flight control software for the Space Shuttle. [Zelkowitz 2001]

It's important for customers to be aware of the tradeoffs between cost, time and performance. There is an old adage that describes a customer's options at the beginning of a project:

"You can have it fast; you can have it cheap; or you can have it good. Pick two."

This proposition suggests that customers can control at most two parameters of the triple constraint. Steve McConnell suggests visualizing a cardboard triangle with the corners labeled cost, time, performance [McConnell 1996]. The customer can hold at most two corners. The development team has control over what's left. This visual exercise is a good way to introduce the idea of tradeoffs with the customer. Some constraints on the project will be fixed by the customer. They may have an upcoming conference where they intend to demonstrate the product. Other constraints may be important to the customer but have a degree of freedom. The customer would probably much rather have 80% of the planned functionality a day before the conference, than 100% of the planned functionality a day after the conference. When attributes of the triangle are out of balance someone has to decide how to bring them back into balance. If the customer doesn't set the priorities the development team will ultimately decide. Without input from the customer, the development team will have to guess the priorities of the customer or make decisions according to their own priorities.

 

It's important to make explicit the priorities of each variable. The variables have to be balanced but you can optimize whatever variable you want [Weinberg 74, Goals and performance in computer programming, 70-77]. Cost, schedule, and scope are easy (easier) to articulate and are usually expressed clearly. This leaves quality to convenient interpretation. It's important to state what attributes of quality are important (maintainability, usability, performance, etc). (See chapter x.)

Planning

Planning is one of the most important functions of project management. The result of planning is a project plan which drives other management functions such as tracking and controlling.

 

The level of detail should be appropriate for size and complexity of the project and level of experience of participants. The more detail the more options and opportunity for control but the more overhead and work for planning and monitoring.

Need to plan s/w dev so you can control it and report its status. Plans are the basis of control. Report status and track progress. Assessment, tracking and control are based on plans. Control tool. Plans give visibility and control. What needs to be done, when and by whom? Schedule = delivery timetable. 

Planning is especially important when having a shorter schedule is a high priority. Detailed planning is needed to identify maximum parallelism among tasks.

Be sure to stake the business value of the project. When the going gets tough, it will be helpful to have a clear understanding of the business value to justify continued expenditures on the project. "Solutions must provide tangible business value." [MSF]

Two-phase planning. First plan to capture the requirements of the project. Next, plan to deliver a product to the requirements. You can't plan the development project until you have the product requirements. Gathering requirements is not small task and the task of requirements gathering requires planning.

At least two go/no-go decision points at the start of a project. After the conception phase there is a go/no-go decision. Is the project feasible? Are there available, adequate and appropriate resources (money, people, technology etc) to deliver the desired product? Is there enough time? These questions should be answered after the initial conception phase and after the requirements phase.

Planning = establish project goals and then activities and tasks (selecting a course of action) that will lead to their accomplishment. "Planning thus involves specifying the goals and objectives for a project and the strategies, policies, plans and procedures for achieving them." [Thayer 2002, p. 231]

The reasons for planning a software development project are a lot like the reasons for planning a vacation. When you go on vacation it's usually for a limited period of time, with a limited amount of money and an itinerary of things you want to do. Unless you have unlimited wealth and leisure time, you plan ahead to get the most out of your vacation for the time and money you do have. The same goes for software development projects. Typically there isn't enough time or money to do everything the customer wants so you plan ahead in order to deliver the most functionality for the time and money that is available.

More specifically, the benefits of planning are:

1. It provides a better understanding of the problem and potential solutions. Thinking through the project reduces risks and reveals opportunities. Planning makes more efficient use of resources.  
2. It's much less expensive to make mistakes on paper, while planning, than while doing the real thing.

Output of the planning process is a project plan. The project plan is a:

1. Script for doing the work.  
2. Basis for project control. How do you know if you are on track while executing the project plan? Track progress and compare current status to project plan. If you are on track, relax. If not, make changes to bring performance in line with plans (or change the plans).  
3. Communication tool for keeping everyone informed.

A project plan is an important output of the planning process. The project plan, at a minimum, should include previsions for managing a project's triple constraint. Most project plans include a schedule to manage the time constraint, a budget to manage the cost constraint, and a work breakdown structure to manage the performance constraint (quality plan for quality constraint and wbs or req doc for features):

      Basic Elements of a Project Plan

These are the basic elements of a project plan but a plan may contain many other elements. You can compare a project plan to a pizza.

Basic and Supplemental Elements of a Project Plan

The basic ingredients in all pizzas are dough, tomato sauce and cheese. The basic elements that should be in all project plans are a WBS, a schedule and a budget. Just as some people wouldn't think of having a pizza without other ingredients, some project managers wouldn't think of running a project without other project plan elements such as: a risk list, a quality assurance plan, a configuration management plan, etc.

This section breaks down the planning process into 9 steps. The output of the process is a project plan with a WBS, schedule, and budget. Steps 5-7 are shown together in the image below because these steps are typically performed together with iteration.

Project Planning Process

Planning is an iterative process. Initial course-grain plans should be refined as addition information about the project becomes known. All 9 steps describe here are important only for the first version of the project plan. Subsequent refinements can skip the steps with outputs that haven't changed since the last iteration.

Step 1: Project Definition

According to the old adage, "if you don't know where you are going, any road will get you there." Therefore, the first step of the planning process is to define where you are going. The definition should include high-level product requirements as well as project requirements. For example, a product requirement might be software with a certain set of features. A project requirement might be that the software be delivered by a certain date. The project definition should state clearly the purpose, scope and objectives of the project. The project definition should address the following elements:

Elements of a Project Definition

Soft requirements such as project vision and business goals are important because they guide decision making. (Vision sets the direction of the project.) During the course of the project the development team makes hundreds of tiny decisions that affect the shape of the product. Understanding the larger vision of the project helps them to make these decisions in a way that is optimal for the project. It's important that there is a common project vision and all team members share the project vision. Otherwise team members may be pulling in different directions.

The desired outcomes of the project should be stated in terms of goals and objectives. Objectives should be clear and measurable. Goals may be more general. Objectives determine the scope of the project and criteria for success.

A deliverable is a tangible result. During development there will be a deliverable for every task in the work breakdown structure (described in step 3 below). At the project definition level, it's sufficient to list only external deliverables. These are tangible results of interest to the customer. The customer may request certain deliverables or they may be derived from the project objectives. Either way they should be well-defined and measurable.

A milestone is a significant accomplishment during the project. (Milestones = significant events in the life of a project. They represent that a certain condition exists in the project.) Milestones are used to measure progress toward project objectives.  Milestones are usually scheduled events that have with significant deliverables, but they don't have to be. For example, a milestone might be going a week without finding a severe error. Customers may request certain milestones or they may be derived from project objectives. Typical project-level milestones and deliverables are listed in table x below.

Table x. Common Project-Level Milestones

Constraints are certain restrictions on the product or process. The project triple constraint describes the most important project constraints. The project definition should identify which of the parameters of the project triple constraint are fixed and which have a degree of freedom. Other possible constraints include technology, staff, and process reporting requirements.

The output of planning step 1 is a list of project deliverables and milestones.

Step 2: Select Technical Development Process

The technical development process should be identified early in the planning process because it will dictate certain activities that need to be planned. It will also dictate certain internal deliverables and milestones.

Because of the overlap and interaction between the technical development process and management process, your choice of technical development process can have a significant impact on the management process. Choose the waterfall model and planning is fairly simple but tracking and control may be more difficult. Choose the iterative model and more planning is necessary (for each iteration) but tracking and control are easier. Choose code-and-fix and you are a hero for the first few months because of the quick visible progress but the pendulum will quickly swing back the other way when rework starts piling up.

Lesson 2 discusses criteria for selecting a technical development process.

Step 3: Create Work Breakdown Structure

The work breakdown structure (WBS) is a popular planning tool regularly used in engineering [Tausworthe 80] and general project management [PMBOK 2000]. It provides a top-down hierarchical decomposition of project activities and project products. As an analogy, when you are designing a program you can use top-down step-wise decomposition to identify all the components of the program. When you are planning a project you can use a WBS to produce a top-down step-wise decomposition of project activities and project products. A WBS manages project complexities the way a structure chart manages programming design complexities.

There are three types of WBS's: process, product, and hybrid. A process WBS decomposes a process into smaller more manageable tasks.  Figure x below shows an example of a process WBS that decomposes the software development process into smaller more focused activities.

Process WBS

Each element of the process WBS represent an activity or process at some level of detail. Elements at the lowest layers in the WBS represent tasks or work packages. A work package is a small task that can be completed in 1-2 weeks by 1-2 individuals. This is only a guideline. The level of decomposition in your WBS's should be driven by project needs, principally project control needs. A process WBS is a tool project managers can use to better understand and manage the activities of a project. 

Figure x below shows a product WBS. A product WBS decomposes a product or entity into its constituent parts. A product WBS is a tool engineers can use to better understand a product or deliverable.

               

Product WBS

A hybrid WBS is one that contains process and product elements. A hybrid WBS should start with a process, alternate between process and product at each layer, and end with products. The rational for this guideline is that processes produce products.

The WBS is the basis for planning and controlling activities of the software development process. The output from a process WBS is a list of activities that are the basis for estimating project costs and schedule. You could start with a laundry list of activities but identifying activities with a WBS helps to insure that a complete list of tasks are identified.

To develop a WBS the best place to start is with the deliverables identified in step #1. Another good starting point is with the life cycle model you chose in step #2. The life cycle model prescribes specific activities and intermediate products that can both be better understood with a WBS. Other tasks and deliverables may be suggested by the milestones, performance specifications and acceptance criteria. Decomposing activities may lead to more products and decomposing products may lead to more activities.

The specific steps for creating a WBS are:   

Depending on how you plan to use the WBS, you may want to record some or all of the following items for each task:   

1. Description of the task    
2. The task owner (this is accomplished by step #5 below)    
3. An estimate of the effort and duration required to complete the task (this is accomplished by step #6 below)    
4. Predecessor (or preconditions for starting) [and successor tasks (this is accomplished by step #4 below)]    
5. Staff and material resources required to complete the task. If applicable, the timing of resources should be specified. Timing identifies when resources are needed during performance of the task. For example, the task of establishing system architecture may require staff resources to perform an inspect at the end of the task. These resources would be needed only at the end of the task. This information may be helpful later if the schedule needs to be compressed.    
6. The outputs or task deliverables (work products).    
7. Completion criteria. How will you know when the task is complete?    
8. Acceptance criteria. If the outputs of the process are subject to quality assurance reviews, what is the criteria and procedure for verifying the quality of the outputs?  

The results of creating a WBS is a list of schedulable activities.

A work package should have: "(1) (The work package) represents units of work at levels where work is performed.
    (2) It is clearly distinguished from all other work packages.
    (3) It is assignable to a single organizational element.
    (4) It has scheduled start and completion dates and, as applicable, interim milestones, all of
    which are representative of physical accomplishment.
    (5) It has a budget or assigned value expressed in terms of dollars, man-hours, or other
    measurable units.
    (6) Its duration is limited to a relatively short span of time or it is subdivided by discrete
    value milestones to facilitate the objective measurement of work performed.
    (7) It is integrated with detailed engineering, manufacturing, or other schedules."

Tasks are elements of planning, progress tracking and status reporting. Too small and timing is wasted on planning and reporting. Too large and there is insufficient tracking and monitoring.

Step 4: Identify Dependencies Between Tasks

I don't know anything about your next project, but I'll make a prediction: you will face schedule pressure. Late delivery and the desire to have software solutions faster are persistent problems in the software industry. The most straightforward way to reduce the time it takes to deliver a software system is to perform some of the activities in parallel. In order to schedule tasks in parallel you need to know the dependencies between tasks. The best way to represent dependencies between tasks is with a network diagram.

The image below shows the network diagram for a portion of the process WBS above in figure x.

 

Task Dependencies

 

The standard dependency between nodes in a network diagram is finish-to-start. That is, if there is a finish-to-start dependency from A to B, A must finish before B starts. For example, in figure x above the Requirements task must finish before the Architecture task can begin. Other types of dependencies are described below.

When creating a network diagram beware of nodes with high fan-in or fan-out. Both create bottlenecks in the schedule and increase the risk that there will be a delay in the schedule.

Once task durations are added in step #6 below the network diagram can be extended to provide more scheduling information.

Step 5: Assign Resources

Each task in the work breakdown structure requires certain personnel and material resources. During this step the required personnel and other resources are assigned to each task.

Allocate people to tasks.

Steps 5,6 and 7 are shown together in figure x above for two reasons. First, it's sometimes necessary to iterate or cycle through the steps. And second, there is more than one way to start the cycle.

 

.

 

Starting and Iterating Planning Steps

 

Iteration is sometimes necessary because a decision in one step may cause a problem with or invalidate a decision in an earlier step. For example, if you assign resources (staff) to tasks before scheduling, the resulting schedule may create uneven workloads among staff which would make it necessary to repeat the assign resources step.

The image above shows two entrances to the planning cycle. When you start by assigning resources to tasks the second step, estimate effort, can be performed by the people who will actually perform the task. This leads to better estimates and more buy-in from the people that will perform the tasks. The disadvantage of assigning resources first is that people may end up over- or under-committed after the scheduling phase. The benefit of starting with effort estimates is that there is more flexibility during scheduling. Assigning people early puts additional constraints on the schedule. For maximum schedule flexibility, assign people last.

Usually there are enough constraints that the number of options/iterations are limited.

Steps 6: Estimate Effort and Duration     

"An estimate is the most optimistic prediction that has a non-zero probability of coming true. Accepting this definition leads irrevocably toward a method called what's-the-earliest-date-by-which-you-can't-prove-you-won't-be-finished estimating." --Tom DeMarc

Effort and duration are two different concepts used for two different purposes. Effort is a measure of labor and duration is a measure of business days spent working on a task. You may have heard time periods quoted in terms of business days as in "The package will arrive in 5 business days." This is what duration measures: business days, business hours, etc. 

Effort is used to measure resource usage and duration is used in scheduling.

Here are a few examples to clarify the distinction. The effort and duration required to iron a shirt are both about 10 minutes because ironing is an activity that requires one person with 100% of their attention focused on the task. Alternately, cooking a turkey takes about 1 hour of effort but the duration is about 3 hours because most of the time is spent waiting for the turkey to bake.

 

Effort, Duration and Elapsed Time

 

For most tasks it's necessary to track both effort and duration. If both effort and duration are being tracked for the tasks of ironing a shirt and cooking a turkey you can conclude that it's possible to cook a turkey and iron a dozen shirts in 3 hours. If you track only duration you would have to allow 5 hours to complete both tasks. If you track only effort, you might erroneously schedule the task of cooking a turkey an hour before dinner.

The effort for a task may also be greater than the duration of the task. For example, the effort required to cut down a tree with a two-person saw is twice the duration of the task. If two people working together cut down a tree in 15 minutes, the duration of the task is 15 minutes but the effort of the task is 30 minutes.

Duration is a measure of time that facilitates scheduling, but sometime it's necessary to track a certain number of days on the calendar, not just business days. This leads to a distinction between duration and elapsed time. Duration is a measure of work time available for scheduling tasks and elapsed time is the actual calendar time taken by the task. For example, the effort and duration for constructing a concrete patio are both about 1 day. However, because it takes about 28 days for the concrete to cure, the elapsed time for the task is 28 days. Using just the concept of duration isn't enough to plan the task of constructing a concrete patio because it doesn't take 28 business days for the concrete to cure, it takes a period of 28 days.

Effort is the amount of labor required to complete a task. People will eventually be assigned to perform the labor so it's important to use the same standards of measurement for both estimating effort and specifying the hours a person is available. For example, if you are going to assume that people are available 40 hours a week, effort estimates must include time for interruptions, socializing, routine meetings, etc. If you estimate effort in terms of the amount of concentrated work effort needed, you should assume people are available less than 40 hours a week.

As an example, consider the task of making 160 3-minute phone calls. Effort for this task can be estimated in terms of "working hours" or "hours at work". Whatever measure is used, resource availability should be specified using the same units. If effort is specified in working hours and resource availability is specified in hours at work, the plan will have the person making the calls working productively 8 hours a day without any allowances for breaks, interruptions, etc.

 

 

Units of Measure for Effort Estimation and Resource Availability Should be Consistent

 

Estimates for effort and duration are based on estimates of the product size. You can't estimate the effort and duration required to design, code and test a module without having some idea of the size of the module. Therefore, the natural order of events is:   

1. Estimate product size    
2. Estimate effort and duration based on estimates of product size    
3. Create project plans based on estimates of effort and duration  

 

 

Dependencies Between Work-Products

 

The necessity of having to create estimates based on estimates is one of the reasons it's hard to predict the cost and schedule of a software development project. It's rather like asking a contractor to predict the cost and schedule for constructing a building before the size of the building is known.

Early estimates are generally not very precise. The lack of precision is due to the many unknowns at the beginning of the project. Are the requirements complete and accurate? How will the requirements change during the project? What technologies will be needed? What problems will there be with the technologies that are used? Estimates should be stated in the form of a range. Assumptions no which the estimates are based should be attached to the estimates. Plans should be made to refine estimates and the plans which are based on them as more information about the project is discovered. Stakeholders should be made aware of this. Lack of precision in estimates isn't a failure of the estimation process but a consequence of not having complete knowledge of the requirements upfront. It is possible to produce precise plans given stable, accurate and complete requirements.

There are several techniques for estimating size, effort and duration [Boehm 81]:

Analogy.  If the scope, complexity and technology of the current project is similar to that used on past projects, experience with those projects can be used to predict size, effort and duration of activities on the current project. Once the current project is underway, estimates for future activity can be based on experiences with recent past activities. Because effort doesn't scale linearly with size and complexity, extrapolating from past experience works best when the old and new systems are based on the same technology and are of similar size and complexity.

Algorithmic Models. COCOMO II. Algorithmic models are formulas that compute effort and duration based on system size and other cost drivers such as capability of developers, effectiveness of development process, and schedule constraints (amount of schedule compression). Most models are derived using regression analysis techniques from large databases of completed projects. In general the accuracy of their predictions depends on the similarity between the projects in the database and the project to which they are applied. If the models can be calibrated for a particular environment if data is available for past projects in that environment.

Expert Opinion.  Have domain experts estimate project costs possibly with the use of expert consensus techniques such as Delphi.

Parkinson. Parkinson's "law" is that work expands to consume available time and resources. Therefore, the cost of the project is the same as the resources available.

Price to Win. The cost of the project is estimated to be whatever is perceived as necessary to win the contract.

Top-Down Decomposition. Costs are estimated for the project as a whole and then divided among the phases and components of the project.

Bottom-Up Composition. Costs are estimated for work products at the lowest-levels of the work breakdown structure and then aggregated into estimates for the overall project.

You may want to include some contingency or padding in your schedule. Because of Parkinson's law you shouldn't pad at the activity level, but it is good practice to pad at the project level.

Principles and techniques for estimating are described in more detail in lesson 4. 

[Add: "Nothing demotivates a team as much as someone else making commitments for it. Nothing motivates a team as much as accepting the responsibility for fulfilling commitments that it made itself." ref

Bottom-up scheduling: better estimates and increased accountability. let the individuals doing the work make commitments as to when it will be completed. Team is more willing to support the schedule because they helped create it. Programmers are eternal optimists so the schedules they set on their own are likely to be over aggressive rather than padded.]

Step 6: Schedule

"More software projects have gone awry for lack of calendar time than for any other causes combined." - [Brooks 95]

The purpose of the scheduling activity of project management is to determine optimum start and stop times for tasks and milestones. Precise times may be specified or for more flexibility, a window of time may be specified for each task. The schedule is also a basis for tracking progress and controlling the project.

Create a Pert chart to show interdependencies among tasks and to identify critical path. Create a Gantt chart to show when each task is scheduled. Tools like MS Project allow you to capture data and then look at it with different views (Pert/Gantt). 

The two main tools for creating a project schedule are: Gantt chart and network diagram.

The Gantt chart is probably the most common tool for presenting schedule information. It portrays activities against a horizontal time scale which has the familiarity of a calendar.

 

 

Gantt Chart

 

A Gantt shows the time and duration tasks are scheduled. It also shows timing of milestones.

Gantt charts don't show interrelationships among tasks well. A Gantt chart may show parallel activity but if sequential activity is shown you can't conclude there is a dependency that requires the sequential activity. For example, just looking at the Gantt chart above it's impossible to tell if the User Guide could be moved up in the schedule.

Gantt charts are good for reporting status but not so good at managing a project.

To capture scheduling dependencies between tasks you need a network diagram. A network diagram was used above to specify dependencies between tasks. Add dates and the network diagram becomes a scheduling tool.

The first step to creating a network diagram is to add duration estimates from step 6 above to each node in the network diagram.

This allows you to compute the critical path in the project. The critical path is the longest sequence of activities in the network diagram. A delay for any activity on the critical path will delay the project completion date. The critical path determines the project's schedule. In the image above the critical path is in bold and is 5+3+3+8+5=24 units long.

With a network diagram you can also calculate slack/float times.

Free slack - the amount of time a task can slip without delaying another task.

Total slack -the amount of time a task can slip without delaying the project completion date. If the user guide was scheduled for day 6 it could slip until day 16 without causing a slip in the scheduled completion date of the project.

Note, the critical path is the sequence of activities with zero slack or float.

With network diagram different types of dependencies can be expressed.

 

 

Finish-to-Start - Task A must finish before task B can start. This is the most common type of dependency.

Finish-to-Finish - Task A must finish before task B finishes. This is probably close to the true relationship between Requirements and Architecture above.

Start-to-Start - Task A can not start until task B starts. 

Start-to-Finish - Task A must start before task B finishes. This dependency is rarely used.

May have to introduce more complex dependencies to achieve desired schedule. Could also define tasks at finer levels of granularity so more parallel activity is possible.

Performing work in parallel complicates project management because you have the additional burden of managing staff buildup. 

 

 

Schedule

 

      Staffing plan or staff buildup curve

 

The image above shows a typical staff buildup curve.

Staffing plan - timing of adding and removing individuals from project. May be expressed with a resource histogram.

[If you do decide to achieve schedule compression by scheduling tasks in parallel don't forget that people and time are not interchangeable. ie Brooks and mythical man-month.]

Step 8: Create Budget

 

The resource assignments and schedule above determine the cost of the project as a function of time. The budget is a baseline for tracking progress and controlling project expenditures.

Step 9: Document the Plan

 

Physically the output of the planning process may be documented with separate documents:

 

 

 

Here is a sample project plan template [derived from IEEE Std 1058-1998]:   

           

Overview                                      Project definition: purpose, scope, goals, objectives.                     Assumptions and constraints                     Deliverables and milestones                     Schedule and budget summary                                           References             Definitions             Project organization                                  Organization of project environment                 Internal organization                 Roles and responsibilities                                       Metrics collection plan             Management Process                                      Start-up plan                                                  Effort and schedule estimation method                           Staffing plan                           Resource acquisition plan                           Staff training plan                                                                 Work plan                                                  Work breakdown structure                           Schedule                           Budget                           Resource allocation plan                                                                 Control plan                                                  Schedule control plan                           Budget control plan                           Quality control plan                           Reporting plan                                                                                       Technical process             Supporting processes                                      Quality assurance plan                     Configuration management plan                     Risk management plan                     Test plan                     Process improvement plan

Organizing

One of the first steps during project formation, usually performed concurrently with planning, is organizing. Individuals working together on a shared activity are more efficient and effective when they are organized. To appreciate why, just compare organized baseball, organized unions, and organized crime with their non-organized counterparts.

Organizing for a project means establishing roles, responsibilities, lines of authority, and reporting relationships between the individuals--and groups of individuals--working on a project. The resulting organizational structure determines how these individuals and groups will communicate, interact and make decisions during the course of the project.

A good organizational structure maximizes collaboration within groups and minimizes interaction between groups. To use a programming analogy, a good organizational structure is one that creates strongly cohesive groups with minimal coupling between groups¹. (See figure x.) A cohesive group is one with a narrow focus and mutually supportive responsibilities. Coupling between groups is a measure of communication and interaction required between groups during routine work activities. High cohesion within groups tends to result in low coupling between groups.

------------------------------------
          ¹Coupling and cohesion are principle criteria for evaluating the effectiveness of a software design. A good software design is characterized by strong cohesion within modules and weak coupling between modules. See chapter x for more information on coupling and cohesion in software design.
       ------------------------------------

 

         

A good organization structure has strong cohesion within groups and weak coupling between groups

 

Organization occurs at multiple levels. The two primary levels of organization considered in this section are enterprise-level organizational structures and team-level ones. Most projects are performed in the context of a larger enterprise. The enterprise-level organizational structure determines how the project interfaces with the larger enterprise. Even though most project managers won't have control over the larger enterprise-level organizational structure--it is usually set by policy or tradition--it is important to understand common variations in order to avoid problems and take advantage of opportunities. This section describes the three most common enterprise-level organizational structures for organizations engaged in project work: functional, project, and matrix.   

Organization is also needed within a project. A project is performed by one or more groups of individuals working together. A group of individuals working together in harmony is considered a team. Teams have their own structure that shapes how they communicate, interact, make decisions, and distribute work. In contrast to the enterprise-level organizational structure, the project manager most likely will have influence on the team-level organization structure, and in many cases will be responsible for establishing it. This section presents two classical team-level organizational structures: chief programmer teams, and egoless programming teams. It concludes with guidelines and considerations for creating a bespoke team-level organization structure tailored to the unique needs of the environment, project and personalities of the individuals on the team.

Before discussing enterprise-level and team-level organization structures the fundamental organization concepts of authority, responsibility and accountability are defined.

Authority Responsibility and Accountability

 

The project manager is usually responsible for assigning responsibilities, delegating authority and holding people accountable for results. Authority, responsibility and accountability are the key principles on which all organizational structures are based. It's important to understand these concepts and the relationships between them in order to create a fair and effective organizational structure.

Authority is the power to make decisions, use resources and influence people. There are two main types of authority: (1) assigned authority granted from a higher authority, and (2) de facto authority acquired from knowledge, expertise and interpersonal skill. For example, the project manager is usually granted authority to spend money from the budget. The senior architect might have the authority to select the programming language.

Responsibility is the obligation to fulfill commitments. For example, the project manager has overall responsibility for the success of the project. Programmers are responsible for delivering quality code.

Accountability is the existence of consequences for accomplishing or not accomplishing assigned responsibilities. For example, a project team that shares responsibility for on time delivery might earn a bonus for finishing ahead of schedule. A programmer may have a promotion delayed for causing too many field defects. Accountability is the obligation or willingness to accept the consequences for one's actions. Note that the consequences may be positive or negative.

Typically at the beginning of a project the project manager is granted complete authority and responsibility for the project. He or she may then delegate some authority and assign some responsibility to other project members (see figure x). For example, the project manager might assign a senior engineer the responsibility for establishing the architecture of the system. The manager should also delegate the authority the senior engineer needs to accomplish the assigned responsibility. It's important to note that responsibility can't be completely delegated, it can only be shared. The project manager might share with quality assurance some of the responsibility for insuring the quality of the product, but the manager is still at least partially responsible for the overall quality of the product.

 

 

Hierarchical delegation of authority and sharing of responsibility

 

There is a close relationship between authority, responsibility and accountability. According to classical management theory, authority should be commensurate with responsibility and those with responsibility should be held accountable (see figure x). No one would complain about having more authority than responsibility but the reverse would set unreasonable expectations. Authority commensurate with responsibility doesn't, however, mean having complete control over the means of accomplishing the desired results. Managers and even technical people often have to rely on people outside of their control.

Making those responsible accountable just closes the loop. Having responsibility without accountability doesn't imply any real obligation. On the other hand, someone shouldn't be held accountable unless they are also responsible. Holding someone who isn't responsible accountable is scapegoating.

 

 

Figure x. Relationship between authority, responsibility and accountability

 

Authority and responsibility are usually assigned to an individual but they can also be shared among members of a team. For example, a R&D center may be given the responsibility for producing a certain number of patents or breakthrough products in a year. In an innovative environment such as R&D it's difficult to assign an individual the responsibility for coming up with a winning idea. The collective creativity of a group is more predictable. A group may also decide to share authority and responsibility if it is impossible to reach consensus on the assignment of authority and responsibility within the group.

Enterprise-Level Organizational Structures

 

This section describes the three most common organizational structures for managing temporary projects: functional, project, and matrix. The advantages and disadvantages of each are considered along with the locus of project coordination.

Functional

The functional organization structure is the most common type of organizational structure for ongoing operations and repetitive work. In a functional organization staff members are grouped by specialty or discipline (i.e. marketing, engineering, research, etc). Lines of authority and reporting relationships are hierarchical. Each functional unit has a manager and upper-level management has authority over functional unit managers.

 

 

Functional Organizational Structure

 

Although best suited to ongoing operations the functional organization structure may also be used to perform project work. Because functional units are groups of specialists, most projects will require the expertise of multiple functional units. When a project does cross function lines it is divided and assigned to the appropriate functional areas. For example, a software project might be divided into requirements, design, development, and testing. Each functional unit would be assigned responsibility for a different part of the overall project. The popular way of depicting this process is that work during one stage is performed and the results are then "thrown over the wall" to the next stage. "The wall" here symbolizes the detached nature of functional units and their narrow focus of concern. There is better communication and collaboration within units than between units. Also, function units aren't focused on the project as a whole but rather, fulfilling their obligations and having a result that can be legitimately passed on to the next stage.

A major disadvantage of performing project work with a functional organization structure is that there is no focal point of project control. Project coordination is shared between functional unit managers and upper-level management. (See figure x.) Functional unit managers coordinate project work performed within a functional unit and upper-level management deals with project issues that cross functional boundaries. The result is that no one really owns the project and no one is concerned with the overall health of the project. Technically upper-level management is the focal point of the project, but managing projects is only a small part of their overall responsibilities. They don't have time for more than superficial involvement in any one project.

Another disadvantage of performing project work with a functional organizational structure is that whenever there is a conflict between the goals of the project (such as completing on schedule) and the goals of a functional unit (such as professional development), the needs of the functional unit often win out. Members of a functional unit view a project as a temporary assignment and their function unit as a permanent home.

The principle advantage of the functional organizational structure is that it serves the long term interests of staff and the organization. Specialization allows individuals to develop professionally and excel in their discipline. Working in close physical proximity of others working in the same discipline facilitates the sharing of expertise and knowledge within a discipline. The permanence of functional groups provides for the accumulation and continuous development of institutional knowledge. Specifically, standards and technical methods can be incrementally improved over time.

Table x summarizes the advantages and disadvantages of performing project work with a functional organizational structure.                                                       

Advantages

Disadvantages

Close physical proximity of specialists promotes sharing of expertise and knowledge within a discipline. This improves individual as well as institutional capability.           Promotes continuous process improvement, specifically the control and evolution of standards and methods.           Offers staff a stable work environment with improved career opportunities for specialists.           Specialized skills can be leveraged across multiple projects. This results in economies of scale and more efficient use of critical resources.

There is no central point of authority and control for the project. Project coordination is distributed.           The loyalty of staff is with their functional unit rather than the project.           When there are multiple projects there may be competition for resources and arguments over priorities.

Table x. Advantages and disadvantages of functional organizational structures

Project

In direct contrast to the functional organization structure is the project-based structure. (See figure x.) With the project-based structure the resources necessary to perform the project are centralized and put under the control of the project manager. The project manager has complete authority and control over project resources including personnel. Project personnel are assigned full-time to the project and take on roles that mirror functional specialties. For example, a well-balanced software development project will have a requirements analyst, an architect, one or more developers, etc.

   

 

Project-Based Organizational Structure

 

The principle advantage of the project-based organizational structure is that personnel feel a greater sense of loyalty to the project and its goals. This improves motivation and morale during the development phase of the project. In addition, because most of the work is performed within the same group, interfacing between groups is reduced. Interfacing here refers to the additional overhead required when contracting for services outside of a group. Within the same group work agreements can be informal because project members share the same goals. (requires more formal project planning and control techniques because of subcontracting)

The principle disadvantage of the project-based organizational structure is inefficient use of critical resources (human and material). For example, most projects will require individuals with specialized skills (architect, database designer, etc.). The first problem is finding specialists that are willing to work full-time on a single project that may last only a short duration. When they can be found and hired they may not be fully utilized. The result is inefficient use of critical resources and an environment that might not attract the best specialists. When repeated across multiple projects costs are increased because of duplication of effort.

Another disadvantage of the project-based organizational structure is that project personnel may become anxious towards the end of a project as they contemplate their future. For project personnel there may be a loss of identify at the end of a project and uncertainty about their next assignment. They may wonder, will there be a next assignment? Will it be as rewarding as the current assignment?

Table x summarizes the advantages and disadvantages of performing project work with a project-based organizational structure.                                                                              

Advantages

Disadvantages

Project manager has complete authority and control over the project and project resources. This provides a single source for decisions and project control.             Project personnel identify with the project which results in improved motivation and morale during the active phase of the project.             Interfaces between organizational units are minimized because most work is performed within a single group.

Inefficient use of critical resources (human and material).             Increased cost because of duplication of effort.             Difficult to have all required resources assigned to the project. When the resources are assigned it creates the other problem of making efficient use of them.             Increased anxiety for project members towards the end of a project as they contemplate their future.             Inhibits the development and transfer of expertise from one project to the next.

    Table x. Advantages and disadvantages of the project-based organizational structures

Matrix

The matrix organizational structure combines elements from both the project and functional structures. It is an attempt to maximize the strengths and minimize the weaknesses of both. Specifically, it adds a project coordination role to the functional organization structure. As figure x shows project management becomes another function staffed with project managers. A project manager takes ownership of a project and guides it through the other functional departments.

The principle advantage of the matrix structure is that it balances the long-term objectives of the organization with the short-term objectives of specific projects. The long-term health of an organization depends on: staff development, the efficient use of specialized resources, and improved technical capabilities. Short-term project goals are simply to deliver a quality product according to the agreed upon schedule and budget.

One of the disadvantages of the matrix structure is that it divides authority and responsibility for a project between the project manager and the managers of the functional units. In general the project manager is responsible for deciding what to do and the functional managers are responsible for deciding how to do it. In order for this arrangement to work the authority and responsibility of project managers and functional managers must be clearly defined.

A common division of authority and responsibility is to have the project manager control the project budget and contract for services from functional units. Key to making this arrangement work is careful specification of work packages. (See figure x.) A work package defines the interface between project staff and functional units. A work package contains a detailed description of the task to be performed along with a budget and schedule for performing the task. The project manager should work with functional managers to create work packages that are mutually agreeable. It's interesting to note that contracted work becomes a mini-project for a functional unit.

 

 

Work Packages define interface between project staff and functional units

        Table x summarizes the advantages and disadvantages of the matrix organization structure.

                                                             

Advantages	Disadvantages
Because the matrix structure combines elements of the functional and project structures it retains most of their advantages:               There is a project champion--someone with authority and responsibility for the project as a whole.               Critical resources can be shared between projects resulting in improved economy of scale.               Provides for continuity and stability between projects.               Provides for improved technical expertise and standards.	However, it does create some new disadvantages:                           It is a two-boss system. When the project manager contracts for services from a functional unit, the staff in the functional unit working on the project will have two bosses. This is a source of conflict when project goals interfere with the goals of the function unit. For example, on time delivery may conflict with the goal of continuing education and staying current with technology.               It requires additional overhead for creating work packages. The work performed by functional units must be fully specified in work packages and tracked. This creates an additional external interface that has to be tracked and managed.               Divided authority and responsibility between project managers and function managers creates a potential for conflict.

   

Table x. Advantages and disadvantages of the matrix organizational structure

Team-Level Organization Structures

 

Organization structures occur at various levels. The previous section described the three most common ways projects interface with and are staffed from the larger enterprise within which they are performed. This section considers organization at a lower lever--at the level of a team. A team is a group of 3-12 individuals working together in harmony towards a common goal.

Most software that matters is developed by individuals working together as a team. Teams are necessary when either (1) the quantity of work is more than what a few individuals working independently could complete in the desired timeframe, or (2) the diversity of skills required to perform the work necessitates a team of individuals. Even when teams aren't strictly necessary, they are often preferred because teams tend to produce more effective solutions of higher quality. This is especially true when the work is intellectual.

A team-level organizational structure determines how the members of a team will interact and share authority and responsibility. Does one person hold sway and set the direction for the group, or does the team function as a democracy with consensus decision making?

The team-level organizational structure can be left to evolve on its own but project progress will be much more efficient and orderly if the team structure is established during the early phases of the project life cycle. Because project requirements may influence the eventual team structure, it may not be possible to establish the final form of the team until after project requirements are established.

There is no single team-level organizational structure that is best for all projects. The best team-level organization structure for a group of individuals depends on the unique characteristics of the environment, people and goals of the project.

This section presents three team-level organization styles and then discusses general considerations for organizing a team. The three team-level organization styles are: Chief Programmer Team, Egoless Programming Team, and hierarchical.

Chief Programmer Teams

Smaller teams are preferable to larger teams because as team size increases a greater percentage of time is spent on communication and coordination than on productive work.

 

 

Figure x.a. Team of two

 

 

Figure x.b. Team of four                         Figure x.c. Team of eight

 

However, the quantity of work and diversity of skills needed to complete a project often necessitate a larger team size. The best way to deal with these forces from an organizational perspective is to staff a team with top talent and organize the team in a way that minimizes communication and coordination. The chief programmer team is one such team-level organizational structure that leverages the abilities of top talent and makes efficient use of staff resources.

The chief programmer team addresses some of the shortcomings with the conventional approach to large system development. The conventional approach to large system development is to partition the system into chunks and then assign each chunk to an individual. (See figure x.)

 

 

Figure x. Large System divided evenly among a group of programmers

With this arrangement each programmer has complete responsibility for a portion of the system. This includes design, code, test, documentation, integration, etc. There are three potential shortcomings with this approach to dividing the work:   

1. The system tends to loose its conceptual integrity [Brooks 1995]. When the design work is partitioned and then integrated, the system architecture becomes an amalgamation of independent uncoordinated ideas rather than a coherent model that reflects a single design strategy. The best architectures tend to be those that originate from one mind. Good architecture doesn't have to originate from one mind, but it's probably the easiest road to conceptual integrity.    
2. The intellectual challenge of the work may vary significantly. Some of the work such as early design and coding requires considerable skill and experience. Other activities are more routine. The range of activities creates an opportunity for a division of labor and specialization. More generally, overall efficiency of a group is improved when group members specialize and focus on tasks for which they have a comparative advantage. (See related sidebar--comparative advantage.)    
3. When work is divided among individuals and performed in parallel, additional effort is needed to coordinate activities and integrate results. Additional effort may also be needed to deal with the problems related to integration and coordination.    
                                                      

   Comparative Advantage                                               Comparative advantage is a fundamental concept in international trade theory. It shows that when certain simplifying assumptions hold, maximum overall wealth for all countries is achieved with free trade and specialization among countries. The concept can also be applied to individuals working in a group.               Group productivity is maximized when individuals specialize. It doesn't matter how productive each individual is, overall group productivity increases when individuals concentrate on tasks for which they have a comparative advantage.               For example, assume there are two analysts, Larry and Mindy. Table 1 shows the productivity of each individual. Larry can complete one unit of design in 20 hours and one unit of coding in 10 hours. Mindy is more productive than Larry at both design and coding. She can complete one unit of design in 15 hours and one unit of coding in 5.                             Table 1. Analyst Productivity               Assuming that both Larry and Mindy are working on the project full-time, what is the optimal division of labor? At first it might seem like Mindy should do all the work since she is more productive than Larry at both design and coding. However, the determining factor is not absolute advantage of one individual over another, but comparative advantage or how much each individual gives up (i.e. opportunity costs) by focusing on a particular task. For example, table 2 shows that for each unit of design that Larry does he gives up the opportunity to do 2 units of coding. Mary gives up 3 units of coding for each unit of design she does. Larry has the comparative advantage with design because he gives up less when he focuses on design. For maximum group productivity Larry should devote as much of his time as possible to design. If Larry has comparative advantage with design it follows that Mindy will have comparative advantage with coding (since there are only two tasks). Table 2 shows that Mindy does in fact have a comparative advantage with coding. She gives up only 1/3 of a unit of design for each unit of coding she does, whereas Larry gives up 1/2 a unit of design for each unit of coding he does.                             Table 2. Analyst Comparative Advantage               To see precisely why comparative advantage makes a difference, consider different ways of dividing the work during a 40-hour workweek. Table 3 shows Larry and Mindy sharing responsibility for design and coding one week. The total productivity for the week is 2 units of design and 7 units of coding.                             Table 3. Shared responsibility--non optimal task assignment               Table 4 shows a division of labor with Larry focusing on design and Mindy focusing in coding--each focusing on tasks for which they have a comparative advantage. This is the optimal division of labor with maximum group productivity. The total productivity with this division of labor is 2 units of design and 8 units of coding--one additional unit of coding over the previous division of labor without any additional effort. This example shows that organization and division of labor can have a measurable effect on productivity.                             Table 4. Tasks assigned according to comparative advantage--optimal task assignment               Table 5 shows the least productive division of labor. Each analyst is focusing on the task for which he or she has a comparative disadvantage. The resulting group productivity is the worst it can be.                             Figure x. Least productive task assignment               For maximum group productivity work should be divided by function and individuals should focus first on tasks for which they have a comparative advantage. Estimating opportunity costs which goes into the calculation of comparative advantage may include hard-to-calculate aspects such as training, morale, benefits of continuity, etc.

      
      

   The chief programmer team (CPT) takes a different approach to large system development. Rather than divide the system among team members, complete authority and responsibility for the system rests with one individual--the chief programmer. (See figure x) The chief programmer performs all of the design and most of the coding. The balance of the work is performed by a small group of skilled specialists who support the chief programmer. Dividing the work by function results in efficiency through specialization. Having one person responsible for design and critical portions of the code improves system integrity and minimizes extra effort related to integration and coordination.

      

   

      

   Chief Programmer Team

   The original definition of the CPT defined three key roles: chief programmer, backup programmer, and librarian. Since its introduction other supporting roles have been proposed: project administrator, auxiliary programmer, technical writer, tester, and toolsmith. Here is a short description of these roles:

   Chief Programmer. For maximum conceptual integrity the chief programmer has broad and deep responsibilities. The chief programmer makes most of the technical and project-related decisions. He or she is responsible for requirements, system specification, the complete system design, implementation of critical modules, and the first draft of system documentation. The chief programmer is supported by a small group of functional specialists. Subtasks are assigned to these specialists and the chief programmer integrates their results. The CP relies on good tools and a skilled support staff in order to manage the workload.

   Backup Programmer. The backup programmer is the alter ego of the chief programmer. He or she is a senior-level engineer, but probably has less experience than the chief programmer. The backup programmer is there to provide a second opinion on items requiring professional judgment and to fill-in for the chief programmer as needed.

   The backup programmer not only assists the chief programmer, but also learns from him or her. Software development is often characterized as part science and engineering, part art, and part craft. To the extent that software development is a craft, the organizational structure should support some type of apprenticeship training. The relationship between chief programmer and backup programmer is an excellent example of how apprenticeship training can be instituted.

   Librarian. Although an important role in the 1970's when the chief programmer team concept was first introduced, the role of of librarian is an anachronism today. During the 1970's the librarian was responsible for managing the artifacts of the software development process including punch cards, source code listings, test results, and documentation. Today many of the functions of the librarian have been superceded by powerful interactive work stations and automated configuration management systems.

   Project Administrator. The chief programmer should have the last word on all project decisions but may not have time for day-to-day project management responsibilities. For larger projects it may be necessary to add a part-time or even full time project administrator who can take responsibility for budgets, scheduling tasks and managing the day-to-day administrative details of the project.

   This is one role that might be hard for the larger organization to accept. Many organizations are not accustom to having administrator roles subordinate to technical ones.

   Auxiliary Programmer. Auxiliary programmers may be added to the project when the volume of code is more than what the chief programmer and backup programmer can manage within the allotted time. Auxiliary programmers may also be added to perform specialized coding. For example, if the project is to write a compiler, auxiliary programmers may be added to write code optimizing routines. The chief programmer directs and integrates the results of auxiliary programmers. This reduces communication and coordination and helps ensure the conceptual integrity of the final product.

   Technical Writer. The chief programmer writes the first draft of most documentation because he or she is most familiar with the product. The technical writer is responsible for polishing it and filing in the missing details such as table of contents, references, appendices, etc.

   Tester. It's generally accepted that programmers shouldn't system test their own code. The chief programmer and auxiliary programmers will most likely write some unit test cases but a tester is needed to write and maintain a complete set of test cases. The tester may also be responsible for running test cases and planning the different testing phases (unit, integration, system, acceptance).

   Toolsmith. Small teams rely on good tools to maximize productivity. The toolsmith is responsible for assessing tool needs and then either acquiring or creating the tools to meet those needs. Creating custom tools can be seductive. A good toolsmith can accurately assess the value of potential tools and has the discipline to pursue only those tools that will improve the overall productivity of the team.

   Beyond immediate project benefits, use of the chief programmer team structure may also make it easier to attract, motivate and retain top technical talent. Technical employees with higher career aspirations often feel compelled to go into management in order to obtain higher compensation and status. The skills it takes to be a good programmer are different from those required to be a good manager, so when technical people do make the transition to management it is rarely a good thing for either the company or the individual. In most cases it's a double whammy--the company looses a good programmer and gains a bad manager. The individual may achieve higher compensation and status but overall job satisfaction for the individual is likely to be lower.

   To meet the career development needs of technical employees most organizations offer some form of a dual career ladder where employees can pursue either a technical or managerial career path. It's not enough to create a technical career path and declare it equal to the managerial path though. To be credible, top technical employees should have the same opportunities to contribute value to the organization as upper-level management. The value an individual is able to contribute is greatly influenced by the role or roles that individual performs. Research shows that top technical people are capable of being 4 times as productive as their colleagues with average abilities. However, they can't be 4 times as productive unless their role supports it. The chief programmer team structure defines a technical role that leverages the abilities of top technical talent and allows them to contribute at their potential.

   Despite the many benefits of the chief programmer team there are a couple of obstacles to its implementation. First, the position of chief programmer may be difficult to staff. Finding top technical talent alone is hard enough. The position of chief programmer requires a highly talented and motivated programmer that also has exceptional administrative skills as well. Second, an organization chart that has a technical position above an administrative position may make some individuals uneasy. As mentioned earlier, most organizations aren't comfortable with technical positions that have authority over administrative positions. For these reasons the chief programmer team structure is not widely used in its entirety. However, it can be used opportunistically when the right people, project and environment come together. In addition, elements of the chief programmer team structure may be used with more traditional structures. For example, making one person responsible for the conceptual integrity of the system is a good practice that can benefit any organizational structure.

   Egoless Programming Teams

   Gerald Weinberg proposed the idea of the egoless programming team during the early 70's in his classic text The Psychology of Computer Programming [Weinberg 1971]. He offered the structure as a solution to the general problem of ego in programming.

   During the late 60's and early 70's programming was just starting to emerge as a discipline. At the time programming was regarded as more of an art than a science because there was very little experience on which to develop best practices. It is in this environment that Weinberg observed the tendency for programmers to personally identified with their work the way artists might personally identify with their creations. 

   Programmers that view their work as an extension of themselves interpret any deficiencies in their work as deficiencies in themselves. While interest is better than apathy, over identification can interfere with development and testing. To protect their ego and preserve their self-image programmers may consciously or subconsciously adapt practices that are less effective. For example, during development they may avoid peer reviews or be less receptive to constructive criticism. During testing they may avoid rigorous testing that would expose deficiencies in their work.

   Weinberg recognized this approach to programming as ineffective and coined the term Egoless Programming to refer to the preferred alternative. Programmers that practice egoless programming don't personally identify with their code. Code and other work products are considered products of the team. Programmers feel free to seek out others to review their code and freely offer to review the work of others [s/w psychology: human factors]. Testing is more rigorous because the goal is to improve the work of the group and not preserve the self-image of the author.

   It's very difficult to practice egoless programming in an environment that doesn't support it. For example, in an environment with hierarchical authority structures and senior and junior programmers, senior programmers my be reluctant to ask junior programmers to review their work out of fear that it would erode their authority and status. For this reason, Weinberg goes on to propose the egoless programming team structure as a solution or means of restructuring the social environment and value system in order to create an environment where egoless programming can flourish [Weinberg].

    

      

   Figure x. The egoless programming team is a means of institutionalizing egoless programming

   The egoless programming team is decidedly democratic and egalitarian. It has no formal structure, roles or reporting relationships. There is no permanent central authority. Authority and responsibility are shared among all group members. Group decisions, including goals, project direction, and task assignments are made by group consensus. Just because there is no permanent central authority doesn't mean there is no leadership though. Leadership is an important function that is rotated and shared among project members. Project members take a leadership role during the tasks and phases for which they are best qualified.

      

   

      

   Figure x. Lines of communication in egoless programming team structure

   The egoless programming team structure works best when project members are equally capable. The expected benefits of the egoless programming team are increased team spirit, job satisfaction and morale. The opportunity to perform a variety of job roles may also provide the opportunity for professional growth. One disadvantage with this method of organization is that it may take longer to solve simple problems because decision making and problem solving by group consensus takes more time than it takes for an autocratic leader to make a decision by fiat. On the other hand, the discussion and debate that is part of the group decision process makes the egoless programming team structure well-suited to difficult problems that require creativity and innovation [Mantei 81].

   Hierarchical

   The hierarchical approach to team organization offers a compromise between the centralized nature of the chief programmer team and the decentralized nature of the egoless programming team. As figure x illustrates, the CPT and EPT structures represent options at opposite ends of the spectrum with respect to the distribution of authority and communication. Decision making authority is centralized in the chief programmer team (CPT). The chief programmer has the last word on all technical and administrative issues. Decision making authority is decentralized in the egoless programming team (EPT). Each team member has an equal say in all decisions. The CPT has a centralized communication network with all communication going through the chief programmer. The EPT has a decentralized communication network with information flowing freely among all team members [Curtis].

      

   

      

   Figure x. The hierarchical team structure represents a middle ground between the CPT and EPT structures

   The hierarchical team structure is shaped like a pyramid. Authority and responsibility flow from the top down and status reporting is directed upward. The hierarchical structure is also referred to as controlled decentralized because it adds a layer of control and coordination over decentralized subgroups [Mantei 81]. (See figure x.) Strategic decision making is centralized at the top of the hierarchy. The project leader and group leaders are responsible for strategic decision making, setting goals, and partitioning the work among subgroups. Most of the production work is performed in decentralized subgroups at the bottom of the hierarchy. These subgroups function as small egoless programming teams where authority and communication are decentralized.

      

   

      

   Figure x. Hierarchical Team Structure

      

   Because it offers a wide range of options between the completely centralized and completely decentralized approaches to organization, the hierarchical structure is the most common.

   Organizing a Team

   Three different team-level organization styles are presented above. Each takes a different approach to roles, responsibilities, reporting relationships, and lines of communication and authority. One structure isn't necessarily better than another, each structure is more or less appropriate for a given environment, team and project. In practice the right structure for a team depends on the environment, project objectives, stakeholder preferences, and the personality and experience of team members. This section presents a 4-step process for creating a custom team-level organization structure tailored to the unique needs of a project [Thayer, S/W Eng. PM, p. 79] [PMBOK Guide 2000 ed].

   Step 1. Identify logical groups of activities

   The first step is to identify logical and cohesive groups of expected project activities and deliverables. Each logical group suggests a project role. The early work in this step overlaps with work performed during project planning. Figure x shows that both planning and organization start with an understanding of the major activities and deliverables needed to complete the project. This information is used during project planning to identify the detailed tasks needed to create the project's schedule and budget. During organization the information is used to identify logical and cohesive groups of activities that will suggest project roles.

      

   

      

   Figure x. Early analysis drives project planning and organization

      

   The work breakdown structure, the software process being followed, and experience with similar types of projects are all good sources of inspiration when trying to anticipate activities and deliverables.

   Step 2. Define project roles

   Each logical cluster of activities and deliverables uncovered in the previous step suggests a potential role in the current project. (See figure x.) A role represents a cohesive set of behaviors and responsibilities that will be assigned to an individual or group [Kruchten, The RUP an Introduction]. Informally, a role is a "hat" that an individual wears during a project. For example, one person might wear the database administrator hat during most of the week, but on Friday put on the build coordinator hat and take responsibility for creating the weakly product build¹. Assigning roles to individuals allows them to specialize and work more effectively and efficiently.

   Figure x shows how a logical group of activities can be used to suggest project roles.

      

   

      

   Figure x. Each logical group of activities suggests a project role

   ----------------------
             ¹ There is a distinction between a role and the individual who performs the role but in practice the distinction is sometimes lost. For example, it's common to refer to the person in charge of a project as "the project leader" when technically it should be "the person performing the role of project leader".
         ----------------------

   Figure x shows the relationship between deliverables, activities, roles and individuals. Deliverables are the expected results of the project. Activities produce deliverables. A logical cohesive group of activities map to a role. Individuals take on roles. Notice that there isn't necessarily a one-to-one mapping between roles and individuals. A role may be performed by more than one individual and one individual may perform multiple roles.

      

   

      

   Figure x. Relationship between individuals, roles, activities and deliverables.

      

   In the software management process, organization precedes staffing. During organization roles are defined. During staffing individuals are recruited to fill identified roles. In theory roles should be defined independent of the person or persons who will be assigned to them since a role may exist longer than an individual's tenure. In practice this isn't always possible or practical because staffing options are often limited. Individuals have different strengths and weaknesses. Many times it will be more practical to design roles around available individuals. Available staff may even dictate organization opportunities. For example, if an individual with strong technical and administrative skills is available, the chief programmer team structure becomes an option.

   Expected project activities and deliverables determine what roles are needed for a particular project. Here is a comprehensive list of potential roles during a software development project:

   Project Leader (also known as team leader or project manager) - The project leader is mainly responsible for performing the project management process as described in this chapter including the functions of planning, organizing, staffing, directing, controlling and risk management. The main deliverable of the project leader is a project plan which includes a schedule, budget, and risk management plan.

   Some groups may be reluctant to appoint a project leader because they are uncomfortable with one member having authority over the others. However, the project leader doesn't have to have direct control or authority over the other team members. The project leader may simply be responsible for maintaining the project plan, tracking progress and reporting status to upper-level management. Groups that are highly democratic and egalitarian still need someone responsible for basic project management functions like planning, tracking, and coordinating. Of course if the project leader doesn't have authority to make decisions and direct people, he or she shouldn't be held responsible for project progress or success. This would be the case with the leadership role in an egoless programming team.

   The project leader may have technical as well as administrative responsibilities. Figure x illustrates the full range of possibilities and typical role names. Team leaders with little or no technical responsibilities are usually called project managers. Toward the other end of the spectrum are project leaders, usually called team leaders, that are regular team members with significant technical responsibilities. In this case the project leader serves principally as a link to management or single point of contact for project information and project status. Expectations regarding the balance of time the project leader will spend on administrative and technical matters should be clear to everyone including team members, upper-level management, and most importantly--the project leader.

   

      

   Figure x. Project leader may have technical as well as administrative responsibilities

   Product manager (also known as end user liaison) - The product manager is responsible for the definition and evolution of the product concept. Any questions about what to build or what features to include in the product are decided by the product manager. Ultimately customers and end users determine what is built, but customers and end users aren't always available, don't necessarily speak with one voice, and usually have a perspective that is different from the technical development staff. In programming terms, the product manager encapsulates or provides a clean interface onto the wants and needs of customers and end users. (See figure x.)

   

      

   Figure x. Product manager encapsulates wants and needs of customers and end users

   Communication through the product manager is two-way. The product manager understands the concerns and constraints of both developers and customers and facilitates communication between the two.

   Current or former users with some technical capability often make great product managers.

   Requirements Analyst - The requirements analyst leads and coordinates the effort to establish project requirements. The product manager ultimately decides what goes into the product, but the requirements analyst does the work of eliciting and documenting the requirements.

   Database Designer/Developer - Projects that have a separate database will most likely need a database designer role. The database designer is responsible for planning, designing, developing and maintaining the database. A key deliverable of the database designer is the database scheme. For relational databases this can be expressed as an entity relationship diagram that shows tables, main fields (primary, secondary, and foreign keys), and relationships between tables.

   Architect - The architect is responsible for creating and documenting the high level system design or architecture. The resulting architecture should provide a framework for more detailed design, provide the foundation for satisfying non-functional quality requirements, and minimize the complexity of the system implementation. The architect works with the requirements analyst and product manager to understand the non-functional requirements, the business environment, and system constraints. These are all inputs to the architecture process that will shape the resulting architecture.

   User Interface Designer - The user interface (UI) designer works with the product manager and requirements analyst to define an appropriate user interface. The user interface designer is responsible for the detailed implementation of the UI and ensuring a consistent style is used throughout the system.

   Programmer/Developer - Programmers are responsible for detailed design, development, and unit testing of software. Because programmers have intimate knowledge of implementation options and opportunities for reuse, they may also be asked to estimate feasibility or cost of implementing different features.

   Testers - Testers are responsible for planning activities such as writing test plans and devising testing procedures and the detailed work of designing, writing, and executing test cases. They may also be responsible for evaluating test coverage.

   Build Coordinator -  Frequent builds and testing are software engineering best practices. Regular builds and testing ensures that errors are found early and the overall quality of the system remains high. The build coordinator is responsible for integrating the work of developers, building a driver and running integration tests. Builds are performed according to a regular schedule, usually daily or weekly.

   Quality Assurance Analyst - The quality assurance function is different from testing. The quality assurance analyst assures management and other project stakeholders that software products have their planned levels of quality. The quality assurance analyst makes sure the development team has access to agreed upon standards and procedures for software development and that the produces they produce conform to these standards.

   Writer or Editor - The writer is responsible for authoring or editing system documentation including user guides, system help text, release notes, etc.

   Step 3. Define organization structure and assign authority and responsibility

   The output of the first two steps are roles unique to the project at hand. In this step authority and responsibility are assigned to each role and the relationships between roles are established. An organization structure is defined by roles, authority, responsibility, and the lines of communication and status reporting. You have an organization structure when you can answer the following questions:   

• What are the responsibilities for each role? What authority is assigned to each role to accomplish its associated responsibilities?    
• What decisions need to be made during the course of the project? How will these decisions be made?    
• What communications are needed between roles to perform the work of the project?    
• How will status be reported for the work performed?   

The three team-level organization models presented earlier provide three different options for structuring a team. They may be adapted as is or tailored for a particular project.

Whatever the final structure each team member should have clearly defined role responsibilities but also share with other team members responsibility for overall project success. (See figure x.) For example, individuals should be responsible for creating the work products associated with their roles, but they should also be responsible for participating in reviews, formal inspections, and other collaborative and opportunistic activities that help to insure overall project success. It's difficult to completely prescribe a complete set of role responsibilities that will ensure project success. Sharing responsibility for overall project success encourages individuals to contribute outside of their direct areas of responsibility and take initiative whenever they see an opportunity to make a positive contribution. One way to encourage shared responsibility and implement accountability is to offer team awards or incentives based on overall project success.

1.    

   Each individual has role responsibilities and shares with other team members responsibility for overall project success.

   Step 4. Document the results

   The team-level organization structure should be documented in the project plan. This clarifies each individual's role, responsibility and authority. An org chart is an effective means of depicting organization structure and relationships between roles. (See figure x.) If one is used it should be clear what the lines in the org chart represent. Are they lines of authority? Lines of communication? Lines that represent reporting relationships.  

Staffing

 

"The single most important determinant of a project's success is the quality, experience, and motivation of its people." [Brown96]

Some important staffing principles that underlie the staffing function are:   

1. People and time are not interchangeable [Brooks 95].    
2. There are wide variations in productivity among individuals with the same education and experience.    
3. A few good people are preferable to many less skilled people.  

People and time are not interchangeable

When planning a project, or more importantly when replanning a project after a schedule slip, it's incorrect to assume that people and time are interchangeable. For example, if an initial project plan calls for 2 people to work together full time for 6 months the total effort for the project is 12 person-months. If the plan is presented to upper management for approval and they agree with the effort estimate but ask that additional staff be added so it can be completed in half the time (3 months), it's incorrect to automatically assume that it can be done in half the planned time by doubling the planned staff. Mathematically it's reasonable, and it might even work for some projects, but for most projects it's unrealistic to assume that people can be evenly traded for time.

The basic problem with trading people for time is that it's difficult to divide the work of software development into manageable pieces that can be worked on individually (isn't easily partitioned into independent units of work that can be completed in parallel.) If the job is to paint a picket fence, 10 people can complete the work in 1/10th the time it would take one person to do the job (assuming the fence is long enough and there is no contention for supplies), but a software development project isn't so easily divided. First there is the problem of sequential dependencies. The software development process is fundamentally sequential. The requirements phase creates input for the architecture phase; which creates input for the detail design phase; which creates input for the coding phase; which creates input for the testing phase. It's possible for phases to overlap some, but for the most part one phase has to be completed before the next can begin. Work can of course be divided into iterations (see chapter x) but that will likely create another form of dependencies--logical dependencies. When one module is logically dependent on another, additional effort is needed for coordination and communication among the individuals that are working on each module. This additional effort for communication and coordination adds to the overall project effort. Another problem with shrinking a schedule by adding more people is that software development is intellectually challenging with a significant design component. Design required creativity and innovation. It's hard to schedule, let alone compress the time required to perform design. Design solutions require time to evolve over time based on experience and feedback.

Figure x illustrates the effect on the schedule when adding more people to a task that is perfectly partitionable (the solid line) and one that incurs additional overhead for communication, coordination and training as additional people are added (the dashed line). The additional overhead caused by adding people adds to the overall task effort which has to be divided among the number of people working on the task. In the worst case this overhead is quadratic and a significant addition to overall project effort. As figure y shows, it's possible that adding people can actually increase the amount of time it takes to complete a project. This happens when the additional overhead of adding people to a project is greater than the contributions of the people added. The people added may in fact be very talented but their talent can't make up for the additional time other project members will spend on training the new members on the problem domain, project goals, technology, development environment, etc.

 

 

Figure x. The relationship between number of people working on a project and time to complete

 

 

Figure y. For some tasks adding people may even increase the schedule

Adding another person-month of labor doesn't necessarily reduce the overall project effort by 1 person-month.

 

 

 

Figure x. People and time are interchangeable if the task is perfectly partitionable

 

 

Figure x. For most tasks people and time are not interchangeable

When a project falls behind schedule the natural inclination is to added people in order to catch up. However, people and time aren't interchangeable. The additional effort to bring new project members up to speed will likely cancel out any additional additional effort they can provide. In some cases adding people may slow a project down.

There are wide variations in productivity among individuals with the same education and experience.

A few good people are preferable to many less skilled people.

The interests of individuals should be aligned with those of the project.

Directing

Directing involves motivating and leading people to achieve their potential/best.

Tracking and Controlling

"Basically, all spacecraft go off course because our understanding of the universe is not complete or detailed enough to perfectly plan a spacecraft's flight. Also, there are many factors that influence space flight, and we don't have the ability to account for all of them in space at once." - http://www.qrg.northwestern.edu/projects/vss/docs/index.html 

Closed loop feedback control system.

Metrics to be used for tracking are selected based on the questions stakeholders need answered in order to make decisions that affect the project. It's the GQM approach. (Use GQM to select metrics for tracking and control.

"Tracking and Control is the dual process of detecting when a project is drifting off-plan and taking corrective action to bring the project back on track. It also encompasses detecting when the plan itself becomes faulty and re-planning the project and its goals."

Software development projects rarely go according to plan. Plans are based on estimates and assumptions which may not be accurate. The environment is constantly changing and project goals and objectives may change as the customer comes to better understand the application and opportunities. Developers also come to understand the technology and implementation better. Software development isn't deterministic. It can't be completely planned a priori. The consequence is that during project execution actual progress must be measured and reported to decision makers, those responsible for controlling the project. They will use this information to control the project, that is make adjustments along the way as risks and problems arise.

System control process: 

 

The control process should occur within a project and between the project and its environment.

Planning and metrics or measurement are an important part of control. Control is easier with planning and you can't control what you can't measure.

Step 1: Plan and Establish Performance Standards

Create a plan that includes a budget, schedule, and technical performance (planned features and quality). May want to schedule periodic check points.

Step 2: Evaluate Performance

Goal: track status and measure progress. Need visibility into project.

How:

Status meetings, reviews
Other metrics and measures of progress

What:

Assess status, progress and forecast for: budget, schedule, technical performance (features and quality).
    Assess status, progress and forecast for: risks

Variance analysis: compare planned progress to actual progress.

Step 3: Analysis

Does the data suggest a problem? If there is a problem, is there anything that can be done about it?

Step 4: Corrective Action

If actual progress doesn't equal planned progress or performance evaluation suggest there is a potential problem if things continue, what actions do you plan to take?

Earned Value Management

 

Earned value management (EVM) is an advanced method for tracking and measuring project performance. Specifically, it compares work scheduled with work performed in order to determine cost and schedule performance. It requires a little more effort than other methods of tracking and control but delivers a lot more accuracy and predictability. After just 30% of a project is complete EVM can effectively predict the final cost and delivery date for the project. [Fleming 98] [Cleland 02]

What is unique about EVM is that it integrates budget and schedule measures. When budget and schedule measures are reported separately with different metrics (usually tasks completed for schedule and money spent for budget) true project status may be obscured. Earned value management reports schedule and budget performance at the same time using a common metric in order to provide a more accurate portrayal/depiction of project status.

Figure x shows conceptually how earned value management integrates budget and schedule measures. Figure x.a and figure x.b represent the schedule and budget status for a project over time. According to figure x.a the project is behind schedule because the work performed is less than the work scheduled. On the other hand, budget performance represented in figure x.b looks good. It shows actual expenses running less than planned expenses. Considering each performance measure individually one might reasonably conclude that the overall project status is a good news / bad news story. However, when the same data are analyzed in figure x.c using EV techniques the news is all bad--the project is both behind schedule and over budget. When a common metric of schedule and budget performance is used it's easy to see that the amount of work performed (BCWP) is less than actual expenses (ACWP).¹ This example illustrates the importance of (1) reporting schedule and budget performance at the same time, and (2) using a common metric of schedule and budget performance so that the two can be compared.

-----------------------
        ¹ The amount of work performed in figure x.a looks less than the actual expenses in figure x.b. However, unless a common metric is used for schedule and budget performance it's impossible to conclude that work performed in the schedule is strictly less than actual expenses in the budget.
     -----------------------

 

Figure x. Earned Value Management Integrates Budget and Schedule Measures

The example in figure x introduces the three fundamental parameters of EVM:   

• Budgeted Cost of Work Scheduled (BCWS). This is the planned budget--the expected amount of resources (usually money) needed to complete a group of tasks scheduled during a given time period.    
• Actual Cost of Work Performed (ACWP). This is the actual amount of resources spent during the same time period for whatever work was accomplished.    
• Budgeted Cost of Work Performed (BCWP). This is the value of the work performed during the time period. It is the project's earned value. Note, the cost estimate assigned to a task (the planned value of the task) becomes earned value after the task has been completed.  

Figure x illustrates these key measurements in the context of a simple example. The example shows a schedule and time-phased budget for a sequence of activities. Earned value analysis is always performed for a given time period. The status date marks the end of the time period during which EVA is being performed. The status date in the example is week 3. The schedule shows that during this time period three tasks were planned: requirements, design, and coding. The expected cost of performing these tasks--the budgeted cost of work scheduled (BCWS)--is $400. The diagram also shows that only the first two tasks, requirements and design, were completed during the time period. This makes the earned value or budgeted cost of work performed (BCWP) equal to $200. The diagram also indicates that actual spending or actual cost of work performed (ACWP) was $300. 

 

 

Figure x. Earned Value Analysis Example

From the data given in figure x we can conclude that the project is over budget and behind schedule. It's over budget because the ACWP is greater than the BCWP. It's behind schedule because the BCWS is greater than the BCWP.

A common way of presenting earned value analysis (EVA) results is with a graph that shows cumulative values for EVA parameters over time. For example, figure x shows EVA data for three different status dates (week 1, 2 and 3). Graphs like this make it easy to identify trends in project performance. The difference between BCWS and BCWP represents schedule variance. The difference between ACWP and BCWP represents budget variance. The graph in figure x shows a gradual trend towards deterioration in schedule and budget performance.

 

 

EVM parameters as a function of time

In order to integrate schedule and budget measures a uniform metric is needed that allows comparison of schedule and budget measures. In earned value management this metric is the cost or resources assigned to a task. For scheduled tasks the cost is planned value or scheduled work. Once a task has been completed it becomes earned value which is a measure of work performed. Both are measure of work that can be compared to planned and actual budget expenditures to determine schedule and budget performance. Figure x illustrates these ideas.

 

Earned Value Management Has a Uniform Metric for Measuring Work and Expenses

The three main EVM parameters introduced above are the basis of other EVM measures of schedule and budget performance:

Cost variance (CV) = BCWP - ACWP. This is the difference between planned expenditures and actual expenditures. It quantifies budget performance in absolute terms. A number less than zero indicates the amount the project is over budget for the work performed and a number greater than zero the amount the project is under budget for the work performed.

Cost performance index (CPI) = BCWP  / ACWP. This measure quantifies budget performance relative to the size of the budget. Cost variance alone is a poor measure of efficiency. For example, a cost variance of $100 is excellent relative to a budget of $10,000 (the cost variance is just 1% of the total budget), but not so good if the budget is $200 (50% of the total budget). The CPI is a measure of budget efficiency. It can also be used to calculate the expected cost of completing a project. (See the estimate to completion parameter below.)

Schedule variance (SV) = BCWP - BCWS. This is the difference between the amount of work performed and the amount of work planned. It quantifies schedule performance in absolute terms. A number less than zero indicates the degree to which the project is behind schedule. A number greater than zero indicates that the project is ahead of schedule. In both cases the work is measured in terms of the budgeted cost of the work. This budgeted cost is the planned value before a task is performed and earned value after it is performed.

Schedule performance index (SPI) = BCWP / BCWS. The SPI is a measure of schedule efficiency. It quantifies schedule performance relative to the magnitude of the schedule.

Budget at completion (BAC). This is the total planned cost of the project.

Estimate to complete (ETC) = (BAC - BCWP) / CPI. This is the expected cost to complete the remaining work on the project at the current rate of productivity. This parameter answers the question, "How much will it cost to complete the project." The accuracy of this parameter depends on past productivity being a good predictor of future productivity as well as the consistency of cost estimates between past and future activities.

Estimated at completion (EAC) = ACWP + ETC. This is just the total estimated cost of completing the project based on the project performance to date. The value is the amount spent as of the status date plus the estimated cost of completing the remaining work at the current rate of productivity.

The total estimated time to complete the project can also be calculated using a formula similar to that used for EAC. The total expected time to complete a project = (total project schedule) / SPI. The result may not be as reliable as that for ETC because the components of SPI are both cost estimates. Neither is a direct measure of schedule performance.

Table x shows a summary of EVA measures with example values from the example in figure x.

 

Accurate EV measures depend on thorough and complete project planning. The total work of the project must be planned, scheduled and budgeted in time-phased increments before the project begins. This creates a cost and schedule baseline (the BCWS) for measuring project performance. The resources assigned to each task in the schedule are the basis of EV calculations. If unplanned work is discovered or performed during an increment, EV calculations will be less accurate.

Section x.y describes how to use a work breakdown structure to completely define the scope of a project in terms of discrete tasks or work packages. Recall that a work package is a larger unit of scheduling and control that includes a group of related tasks. Whatever the unit of scheduling and control it should be short in duration or be defined in terms of discrete checkpoints or milestones for objectively measuring intermediate progress. Tasks or work packages may span a status date by design (scheduled that way) or by chance. When this happens there should be some way of objectively measuring progress as of the status date. Subjective measures of percent complete are unreliable and should be avoided.

EVA is only one component of project tracking and control. EVA can identify schedule and budget deviations. Once identified, it's up to the project manager to investigate the root causes of the deviations and take corrective action.

Closure

Risk Management

"If you don't actively attack the risks, they will actively attack you."  --Tom Gilb

"Risk Management is not the same as worrying about your project." -- Tom DeMarco, in Waltzing with Bears: Managing Risk on Software Projects. 

Your project is days away from shipping. A developer you trust says he just discovered a shortcut that will allow him to include in the current release a new feature that was planned for the next release. It's a feature your customers want badly, but you're concerned about the possibility of introducing regression errors. What do you do? It's not an easy decision because there are potential gains and losses no mater what you decide. This is the type of problem for which risk management is ideally suited. Risk management is a discipline for dealing with uncertainty.

Risks management is a regular practice in finance, politics, environmental planning, medicine, etc. Risk management is a integral part of software engineering project management because so much of what goes on during software development is uncertain and non-deterministic.

A risk is a potential problem. A risk may materialize into a real problem. If it does, it is no longer a risk but a problem that should be dealt with using traditional problem solving techniques. The purpose of risk management is to identify risks early while there is still time to take some action before they become problems. Preventing a risk from become a problem is usually easier and less expensive than waiting for the risk to become a problem and then dealing with the problem.

As an analogy, risk management is like a beacon of light illuminating risks in the misty air surrounding the project boat. Whenever possible the project boat will steer clear of the risks identified by risk management. For risks that can't be completely avoided, risk management offers tactics for minimizing the potential damaged caused by risks should they become problems. The last line of defense are contingency plans. Contingency plans are plans for dealing with the risks that become problems. In this analogy, a risk becomes a problem when it strikes the project boat. If it is a risk for which a contingency plan has been prepared, the problem can be dealt with swiftly and effectively.

Risk management is not the same as risk aversion. Risks are an inevitable part of software development. Some risk is necessary for potential reward. What's important is to take the right risks. The right risks are the ones you understand and the ones with the maximum risk/reward tradeoff. You can avoid risks by investing your money in a bank savings account, but you won't get rich that way.

Risk Management verses Project Management

 

Many of the project management activities described earlier treat risks. Creating a schedule reduces the risk of not finishing on time. Testing and quality assurance reduce the risk of delivering an error-prone product. The organization and staffing functions of project management reduce the risk of not having adequate resources to complete the project. With project management already concerned with minimizing risks, why is it necessary to have a separate discipline of risk management? What is the difference between risk management and good old fashion project management?

 

Figure x. Distinguishing between risk management and project management

The difference is, project management isn't looking for any new problems. Project management is concerned with preventing the common well-known problems that all projects face. Risk management, on the other hand, has as its first step: identify project-specific risks. Risk management is concerned with identifying, understanding and abating unique project risks. There are many potential problems that can derail a software project. The software development process needs to address every one. Project management covers the common risks all projects face, and risk management covers the other unique project-specific risks.

Concepts and Principles

 

A risk is a potential problem. More formally, a risk is the possibility of an unsatisfactory outcome [Boehm 89]. There are two important components of risk:   

• the probability of the unsatisfactory outcome    
• the magnitude of the loss associated with the unsatisfactory outcome (the impact)  

For example, 50% of small businesses fail during their first year of operation. Business failure during the first year is the risk. The probability of this risk is 50% and the magnitude of the loss associated with the risk is the amount of capital invested in the business.

This definition of risk leads to the fundamental concept of risk management which is risk exposure. Risk exposure is defined as:

 

RE = Pr(Uo) * Loss(Uo)

 

Pr(Uo) is the probability of an unsatisfactory outcome and Loss(Uo) is a measure of the loss associated with the unsatisfactory outcome.

 

The probability-loss graph in figure y below shows the relationship between Pr(Uo), Loss(Uo) and risk exposure. Notice that risks (such as risk A) with moderate values for both loss and probability have a greater risk exposure than risks (such as risk B) with high values for either probability or loss alone. Also notice how the contours for constant values of risk exposure (10 and 60) divide the graph into different regions for high, medium and low risks. The specific risk exposure thresholds for classifying a risk as high, medium or low will be project-specific.

 

 

Figure y. Probability-Loss Graph

Here is an example of the practical application of risk exposure. Assume there are two companies that provide satellite launch services. Company A has had 12 catastrophic failures in the last 100 launches and company B has had only 10 similar failures in the last 100 launches. One advantage of company A is that it can carry larger less expensive satellites. If the cost of a satellite to be carried by company A is $200 million and the cost of a satellite for company B is $250 million, which launch carries the most risk?

Using the concept of risk exposure we can calculate the risk of launching with each company:                                                                                                                                                                                 

Risk	Probability of loss	Size of loss	Risk Exposure
Lose a satellite with company A	12%	$200,000,000	$24,000,000
Lose a satellite with company B	10%	$250,000,000	$25,000,000

The risk exposure of launching with company A is less then the risk exposure of launching with company B, so there is less risk associated with launching with company A even though there is a greater probability a satellite will be lost.

Risk Management Process

 

The flow chart in figure x below illustrates the risk management process. The risk management process incorporates the familiar control cycle:   

1. Plan - determine what to do and how to do it    
2. Execute - do it    
3. Monitor - compare actual performance with planned performance    
4. Take Corrective Action - when actual performance deviates from planned performance take necessary actions to bring performance back in line with plans.  

The goal of the control cycle during risk management is to identify and minimize project risks.

 

 

Figure x. Risk Management Process

Here the risk management process is described as if it were a standalone process. In practice risk management should be integrated in with project management. This is desirable because (1) risk management requires resources that need to be planned and scheduled along with other project activities, and (2) risks may be identified opportunistically during project management activities. For example, a project not meeting a milestone might suggest a new risk.

The numbered activities in figure x are described in more detail now.

Identify Risks

The risk management process starts with risk identification. The goal of risk identification is to simply identify risks. At this stage it's not necessary to analyze the risk to estimate likelihood, consequences or potential responses. However, this information will be needed in a later step, so if ideas do materialize they should be noted for use later.

Risks should be specific to the project and precise. Whenever possible state the cause of the risk rather than its effect. Knowing the cause will make it easier to mitigate the risk later. For example, "the project might not finish on time" is a risk but it is a risk that virtually all projects face and it doesn't indicate why it is a special concern on this project. To correct the problem, ask why the project might not finish on time and restate the risk so that the cause of the risk is clear. For example, the risk might be restated as: "the schedule is compressed more than 75% of what is considered normal for this type of project". 

Risks are events or conditions that threaten the success of the project. It's easy to brainstorm several of the more obvious risks, but a more systematic approach will yield a more complete list. When looking for risks a good place to start is with the three critical dimensions of a project: schedule, cost and performance. There are risks that threaten the schedule, risks that threaten the cost or resources needed to complete the project, and risks that threaten the product including features and quality attributes. The management and technical processes are also vulnerable to risks. They both define procedures and intermediate work products that lead to the final product. Risks to these processes and work products are risks to the final product. And finally, there are risks that threaten the interest of the various stakeholders. The best way to identify risks to a stakeholder's interest is to invite all stakeholders to participate in risk identification. When stakeholder interests are considered, don't neglect un-represented or under-represented stakeholders, such as the programmers who will maintain the system after it is delivered. You can be sure that someone somewhere cares very much about the quality attribute "ease of maintenance".

Here are some specific techniques for identifying risks:   

1. Check lists. Table x below provides a general checklist of common project risks organized by type. More useful are specific check lists developed from prior experience with projects similar to the one about to be started.    
2. Requirements document and project plan reviews. The project plan and requirements document contain assumptions and other details about the project and product, and as such are good sources for risks.    
3. Decomposition of tasks. Vague tasks in the work breakdown structure are a rich source of project risks. At the very least they add uncertainty which is a source of risk. More likely their solution is difficult with more than a few hidden risks.    
4. Group consensus techniques such as Delphi. Delphi is an effective technique for reaching consensus, and for risk identification has the added benefit of being anonymous. In some project environments project members may be reluctant to mention certain risks. Delphi provides a way for risks to be raised anonymously and debated publicly.  

Here is a list of common project risks grouped by type: 

 

Table x. Checklist of General Project Risks Adopted from [McConnell 96] [Boehm89] [Gilb 88] [Jones 94]:

Output of the identify risks step is an unordered list of potential project risks. For example:

                                                                                                                                      

Risks

Plan abandoned under pressure and project reverts to code-and-fix

Cost estimates not increased after schedule compression

Poorly defined requirements

Supporting technologies don't work as expected

    Table x. Example List of Identified Risks 

Analyze Risks

Once risks have been identified the next step is to analyze each risk to understand its potential impact on project objectives. The results of this analysis will be used in the next step which is to prioritize risks for risk treatment actions.

The impact of a risk on project objectives is determined by the probability of the risk becoming a problem and the expected loss if the risk does become a problem. The risk exposure equation defined above provides a quantitative assessment of risk impact. Recall that risk exposure is:

Risk exposure = (probability of risk becoming a problem) * (expected loss)

 

Risk analysis can be quantitative or qualitative. Table x below shows the quantitative analysis and prioritization of two risks according to their risk exposure value. Comparing the risk exposure for these two risks, you can see the risk of poorly defined requirements represents a much greater threat to project objectives than poor team organization.                                                                                                                                                                                           

Risk	Probability of loss	Size of loss	Risk Exposure
Poorly defined requirements	50%	2 weeks of extra effort	1 week
Poor team organization leads to disagreements which slows progress	20%	3 weeks of extra effort	1.5 days

Risk impact may also be assessed using qualitative analysis techniques. With qualitative analysis the probabilities and expected losses are described with qualitative terms such as high, medium and low. Figure y below shows an example of a qualitative probability-loss matrix.   

        Figure y. Example qualitative probability-loss matrix

If you compare the qualitative probability-loss matrix in figure y with the quantitative matrix above in figure z, you will notice that the qualitative matrix is a bit skewed towards higher risk exposure values for catastrophic losses with low probability. The axis scales on a qualitative probability-loss matrix don't have to be linear. What's more important is that they reflect how stakeholders think about the risks. For example, most people would rate the risk exposure of an event with low probability and catastrophic consequences as a high risk.

Table z below shows the qualitative analysis and prioritization of two risks using qualitative values from figure y above.

The advantage of qualitative analysis is that the people doing the estimating may relate better to qualitative adjectives as opposed to precise numbers. Quantitative analysis is potentially more precise, but because most estimates are based on human judgment, it may be a false sense of precision. When estimates are derived from human judgment, qualitative techniques offer about as much accuracy as quantitative techniques.

Whether you are performing quantitative or qualitative risk analysis, one challenge to comparing and prioritizing risks is that of finding a common measure of loss. For example, the loss associated with an unrealistic schedule is naturally expressed in weeks. The loss associated with the risk of an unrealistic budget is naturally estimated in dollars (or the local currency). How can you compare the severity of these two risks? In the table below, is the risk exposure "2 weeks" greater than, less than, or equal to the risk exposure "$6000"?

One solution is to normalize all losses to a standard unit of measure. Another solution is to define separate categories of risks based on the type of loss they represent, and then only compare risks within the same category. The most common categories of risks are schedule, cost, and performance (features and quality). Whatever method is used, you should analyze all risks together at the same time to insure the same relative measures are used.

The most difficult part of risk analysis is estimating the probability and potential loss of a risk. Some techniques for making these estimates are:     

Output of the analyze risks step is a list of risks together with estimates for the probability and potential loss of each risk. These values are used to compute the risk exposure of each risk. During risk analysis you should document the rational behind these estimates for use later when planning risk response actions.

Prioritize Risks

Risks should be prioritized to avoid analysis paralysis. Analysis paralysis is characterized by spending more time analyzing risks than addressing risks. The results of this step determine the order in which risks will be addressed.

Given the output of the previous step, which includes risks and their risk exposure values, prioritizing risks may at first seem trivial--just sort by risk exposure. Table x below shows a list of risks from the previous step sorted by their risk exposure values. 

   

   

Sorting by risk exposure is a good first approximation for the order in which risks should be addressed, but risk exposure alone shouldn't be the only consideration when prioritizing risks. Other considerations that might affect the priority for dealing with risks include:

• Catastrophic events. You may want to give higher priority to catastrophic events. Because of the way risk exposure is calculated, a very serious risk may have a lower priority (risk exposure value) than a risk with moderate values of probability and loss. This is statistically correct because over time the risk with moderate probability and moderate loss will occur more often than one with low probability and high loss. However, this is of little consequence if the serious risk occurs early and wipes out the project. Some risks are so damaging it may make sense to give them priority over other risks that may cause a greater aggregate loss but aren't so destructive in one incident. For example, considering the risks in table x above, the project manager may want to raise the priority of the 5th risk, "Forget to remove seeded bugs from final product." It is very unlikely to occur but the damage to the product and the reputation of the team would be so devastating it probably warrants a higher ranking.
• Compound risks. Sorting risks by risk exposure assumes risks are independent events when they may in fact be related. Talking on a cell phone while driving increases your risk of having an accident as does eating while driving. Individually the risks for each of these activities might be acceptable, but if you don't recognize that the risk of doing both at the same time is greater than the sum of each individual risk, you might feel it's OK to talk on a cell phone, eat and drive all at the same time.
• Risks 2 and 3 in table x above are compound risks. A compressed schedule makes it more difficult to deal with expanding requirements and expanding requirements makes it more difficult to deal with a compressed schedule. These risks should be combined into a risk with a larger risk exposure or reevaluated considering the increased risk of dependent events.
• Confidence in estimates. The analysis techniques recommended in the previous step are meant to support informed decision making not replace it. If the priorities from risk analysis don't match your intuition it's reasonable to question the analysis as much as your own intuition. The results of risk analysis are based on estimates for probability and loss. Inaccurate estimates will lead to inaccurate analysis results.
•  In the list of risks in table x above, "Poor work environment" is ranked 4th. An experienced project manager may question this result and decide it deserves a higher priority.          

Output of the prioritize risks step is a prioritized list of risks in the order they should be considered for treatment.

Plan Risk Response

Once you have a prioritized list of risks, the next step is to create plans for managing these risks.

The flow chart for the risk management process in figure x above shows the output for this step:     

• Action plans - plans for avoiding or reducing identified risks.
• Contingency plans - plans for responding to identified risks that become problems.          

In general, risks that can be avoided are avoided; risks that can't be avoided are mitigated; risks that can't be avoided or mitigated have contingency plans prepared for them in case they do become problems.

Risk response plans may employ one or more of the following strategies:

• Risk Avoidance. Risk avoidance is changing behavior or project requirements to avoid a risk. This usually has the effect of trading one risk for another with lower risk exposure. For example, if using a new programming language on a project is perceived as a risk, the risk can be avoided simply by using a more familiar language. This may introduce additional risks such as reduced portability or longevity for the application.            
• Risk Transfer. Risk transfer is getting someone else to assume the consequences of the risk. When using risk transfer make sure both authority over the risk and responsibility for the risk are transferred together. You can lock valuables in a hotel safe but it's not risk transfer if there is a sign above the safe that reads, "not responsible for lost or stolen items." Most forms of risk transfer require the payment of a risk premium. Insurance is the most common form of risk transfer.            
• Risk Mitigation. Risk mitigation seeks to reduce the probability and/or impact of a risk. Risk mitigation results in action plans that will be implemented and tracked.            
• Risk Acceptance. When a risk can't be avoided, transferred, or mitigated, risk acceptance may be the only other alternative. Risk acceptance is the best option when treating the risk isn't cost effective. Risk acceptance may include the development of a contingency plan to be used if the risk does become a problem. A contingency plan should include a tracking plan and specific quantitative measures or thresholds for detecting when the contingency plan is needed.         
• Buy information. Buying information is a way of reducing risk by reducing uncertainty. When risk is caused by a lack of information, there may be an opportunity to reduce the risk by gathering more information about the risk. For example, if the risk is vague requirements, investing time and money in creating a prototype may be the best way to reduce the uncertainty inherent in the risk. Creating a prototype may also reduce the probability of the risk becoming a problem.

Table x below shows an example of each of these 5 strategies being applied to the risk of misunderstanding user requirements.

   

   

Table y below lists potential responses to other common project risks.

   

   

As mentioned earlier, risk treatment options may also emerge from the risk identification and risk analysis steps. It's hard to think about risks and their causes without generating some ideas or thoughts about how to respond to them.

   

For each risk there may be multiple treatment options. A tool for deciding among the various treatment options is the risk reduction leverage (RRL) equation. Risk reduction leverage provides a cost benefit analysis of treatment options. Specifically,

   

Risk Reduction Leverage = (RE_Before - RE_After) / Risk Reduction Cost

   

Where RE_Before is the risk exposure before the risk reduction activity, and RE_After is the risk exposure after the risk reduction activity. The numerator of the RRL equation is the benefit of the risk reduction activity and the denominator of the RRL equation is the cost of the risk reduction activity. Risks treatment options with the highest RRL should be implemented first. Treatment options with a RRL of less than 1 shouldn't be implemented at all--the cost of the treatment doesn't justify the expected benefits.

   

When using the RRL equation to evaluate a treatment option be sure the benefit portion of the equation reflects the benefit to all risks. Sometimes two or more risks have a common cause. When there is a common cause, a single risk response may mitigate multiple risks. This makes calculating risk reduction leverage a little more complicated. When a risk response does affect more than one risk, Risk Exposure_Before and Risk Exposure_After should represent the total project risk exposure before and after the risk reduction activity.

   

Output of the plan risk response step are actions plans and contingency plans. Action plans include a schedule for their completion and are executed according to this schedule. Contingency plans are stored and used later when measurement activities detect that the risk is a problem or about to become a problem.

   

Monitor Risks and Mitigation Plans

   

Risk management is an ongoing and continuous process. The risk profile of the project is constantly changing. Risk mitigation plans are hopefully reducing some risks, new risks are likely emerging, and the risk exposure of others are changing. During this step project risks and mitigation plans are monitored in order to:

   

•      
• Assess progress of risk mitigation plans. Things don't always go according to plan. Progress tracking provides an opportunity to assess progress and take whatever corrective action is needed to keep plans on track.      
• Identify new risks early. In general, the earlier risks are identified the easier and less expensive they are to manage.      
• Monitor existing risks. The estimated risk exposure of known risks should be kept current. Changes in risk exposure levels may call for changes to existing risk response plans. Also, risks with contingency plans will need to be monitored in order to initiate contingency plans when measurements cross certain threshold values.    

   

The conventional technique for tracking progress according to a plan is to review project status at scheduled milestones. Risk management activities can be monitored by tracking milestones, but a more common technique for monitoring risk management activities is the top-10 risk list.

   

Table x shows an example of a top-10 risk list. It's called a top-10 list but in practice doesn't have to have exactly 10 items. It should list all of the serious risks but not so many that they can't all be effectively managed.

   

The data recorded for each risk includes: current ranking, ranking during the last review, number of review periods the risk has been on the list, a short description of the risk, and progress toward resolving the risk. Depending on what other types of documents are kept, the actions for responding to the risk may or may not be included in the list. The top-10 risk list in table x assumes a separate document, like that show in figure z below, is being used to record risk resolution actions.

   

   

The purpose for recording historical data about a risk's position on the list is to understand the trajectory of the risk. Is the risk moving up or down on the list? If it's moving up, it deserves special attention. If it's moving down, it may not warrant as much attention as other risks of similar priority.

A regular review schedule should be established for reviewing the risks on the top-10 list. Weekly review meetings at the team or project level are most common but longer review cycles can be justified during quiet periods of the project. Each review should start with a current assessment of each item on the list. What is the progress of risk resolution actions since the last review meeting? Is any corrective action needed to bring progress in line with plans? Should risk items be moved up, down or off the list? Notice, that in table x items that are no longer ranked in the top-10 list are retained for at least one review period.

Several actions may be initiated as a result of the risk monitoring step:     

• Risks that have been resolved may be closed      
• New risks or changes to existing risks will initiate changes to current risk resolution plans      
• Corrective action will be initiated when actual progress on risk resolution plans doesn't equal planned progress      
• Risks that have materialized into problems will initiate contingency plans      
• As a process improvement activity, experience during risk monitoring can be used to update risk identification checklists    

Document the Risk Management Process.

Nobody likes documentation, but the alternative is so much more unpleasant most people are willing to accept a certain amount of paperwork. The alternative is misunderstandings because there is poor communication, poor quality products because there is no record of past work to build on, and rework because previous decisions are forgotten.

Documentation doesn't have to be onerous. Projects that are traveling light can get by with the top-10 risk list described in the previous section. For projects that need more formality there are two other types of documents for recording risk management activity:     

1. Risk Management Plan      
2. Risk Response Plan    

The risk management plan describes the project's overall strategy and approach to risk management. A risk response plan is created for each individual risk and details the plans for managing that risk. In spite of the word 'plan' in the title of each document, neither document has to be more than a page in length.

The risk management plan is usually part of the overall project plan but may be maintained as a separate document. Figure x below shows an outline for a risk management plan.

   

   

The Risk Response Plan is used to document an individual risk as well as plan and track risk response activities. It may be used to plan and track mitigation activities as well as contingency plans. Figure y below shows a template for a risk response plan.

   Figure y. Risk Response Plan Template

Table z below provides guidelines for filling out the risk response plan in figure y.

   

   

Both the risk management plan and the risk response plans need to be coordinated with the overall project plan because they will require project resources.

Resources  

Glaser 1984, October, IEEE Computer