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 Gant and Pert charts used in project scheduling?
8. What is risk management? What are the key elements of a risk management plan?            

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 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]:   

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 responsibilitie