Programming in the Large

Nearly all software is created in the context of a project. Projects don't just happen. They must be actively managed. Managing a project involves a wide range of diverse activities. These activities can be shared among team members, but more often they are assigned to one individual: the project manager. The project manager's primary responsibilities are planning, tracking and controlling product development.

Figure 1. The primary responsibilities of project management are planning, tracking and controlling product development

Every project must spend some time on overhead activities like estimating, scheduling and reporting progress. With larger projects that involve more internal and external stakeholders, these management activities take on greater importance. One or two individuals working alone on software for their own personal use have less at at risk and can get by with less rigorous management practices. Contrast this with a large team of individuals working together to build a complex software system for an external client. The new challenges they will face are what project management is intended to address.

Working in teams requires planning and organizing the work of multiple individuals. Team members need to know what is expected of them and how their work fits into the overall effort. Having external clients and stakeholders requires better control over development processes. At the beginning of a project, clients understandably want to know how much the system will cost and how long it will take to complete. In order to provide these estimates and then deliver on them, the team needs effective project management.

The Nature of Project Work

Before you can appreciate the special challenges of managing a software project, it helps to know a little something about the nature of project work in general.

A project is a temporary endeavor undertaken to create a unique product or service [PMI 2000]. Most of the work in our economy is performed as either a project or as an operation. Projects are the standard way of organizing work when the anticipated duration is finite and the end result is a unique product or service. Operations are the preferred way of organizing work that is ongoing and repetitive. Customer support and human resources are examples of ongoing operations.

Some of the key characteristics of a project that have consequences for how they are managed are:

• Projects create unique products or services. The output of a project is something original that has never been done before.
• Projects are temporary. Every project has a definite start and end date. Projects are initiated to accomplish a specific objective. Once the objective has been achieved (or the project is no longer justified), the project is terminated.
• Projects are performed by a team of individuals. While it is possible to have a team of one, most projects are performed by a team of individuals with complementary skills. Individuals working together are subject to team dynamics which can have a positive or negative impact on the capability of the group.
• Projects are progressively elaborated. The goals and objectives of a project become clearer and better defined as the project moves forward. As a consequence, the output of a project tends to evolve in increments over a series of iterations punctuated by feedback.

Projects: Old Concept, New Approaches

Project have been around as long as humans. Some notable projects in the history of civilization include:

• Egyptian Pyramids - In ancient Egypt pyramids were built as tombs for the ruling elite. Construction of a pharaoh's resting place would commence when he assumed the throne and end upon his death. (A definite start and end date.) The largest pyramid in Egypt, the Great Pyramid of Giza, was built for the Egyptian pharaoh Khufu. (The project sponsor.) Modern Egyptologists believe the Great Pyramid of Giza required the coordinated efforts of more than 20,000 workers over a 20 year period. Figure 2 shows how a crew of 2,000 might have been organized [Winston 2006].

Figure 2. Possible organization of 2,000 workers participating in the construction of an Egyptian Pyramid [Winston 2006]

• Roman Aqueducts - Imagine trying to supply fresh water to a city 30 miles inland using only gravity to transport the water. Over a period of 500 years starting in 312 BC, ancient Romans built numerous aqueducts to supply water to their cities and industries. Construction of an aqueduct was a huge project. Once water was flowing, responsibility for its care and maintenance was transferred to a Curator Aquarum (water commissioner) and managed as on ongoing operation.

• Polaris Missile - The Polaris missile is a submarine launched ballistic missile capable of delivering nuclear war heads. Construction of the missile began in 1955 with a plan to have a fully operational missile ready in 8 years. It was a massive project involving more than 20,000 separate contractors. Compared to pyramid construction, the Polaris missile program was several orders of magnitude more complex, had a shorter schedule and involved more workers. Having access to computers and precision machine tools made the technical obstacles easier to overcome, but comparable advances in project management were needed to overcome the formidable administrative challenges inherent in such a large undertaking. For this the Navy invented the Program Evaluation and Review Technique (PERT) which is still used today. Thanks in part to the use of PERT, the Polaris missile project came in 3 years ahead of schedule.

Figure 3. Notable construction projects from 2550 BC to 1950 AD [Girin 2006, Musselman 2006].

The construction technologies used on each of the three projects mentioned above are radically different, but the project management practices are remarkably similar. Each started with a project proposal from someone willing to sponsor or fund the project. A feasibility study concluded that the project was worth pursuing. Workers were recruited and organized. The work was guided by project plans including a schedule for performing the work and a budget for managing resources. The project sponsor and others interested in the results of the project were kept informed of progress with regular status updates.

The principles of project management haven't changed much in over 4,000 years, but project managers today have access to new tools and techniques that make it easier to effectively manage larger more complex projects. Perhaps the most important new tool is the personal computer and project management software such as Microsoft Project. These tools make planning more efficient, especially in environments where change is prominent. New techniques such as GANTT charts, PERT/CPM, and earned value analysis have also been invented during the first half of the 20th century in order to deal with the complexity of large projects that have lots of interdependent tasks.

Standard Functions of Project Management

The 5 primary functions performed by project managers are [Reifer 2006, Software Management]:

• Planning - deciding in advance what to do. Planning also includes risk management which is planning for adverse events.
• Organizing - defining roles and responsibilities for the project team (the organizational structure).
• Staffing - filling and keeping filled roles defined by the organizational structure.
• Directing - leading and motivating team members to achieve their potential.
• Controlling - periodically assessing project status and taking corrective action when actual progress deviates significantly from plans.

I was curious how well these 5 categories account for all that is expected of today's project manager, so I decided to perform a little experiment. I went to an online employment database and searched for positions offered in IT project management. Among all the matches I selected 14 of the most complete job postings. From these, I extracted a representative sample of the duties and responsibilities they were seeking in an applicant. Lastly, I organized and grouped the duties according to the 5 standard functions of project management. The results are shown in figure 4.

Figure 4. An amalgamation of several job posting for the position of IT Project Manager

As figure 4 shows, the 5 standard functions of project management seem to account for nearly all of what is expected of today's project manager. The few duties that don't neatly fit into one of the 5 standard functions are broader responsibilities that help to further define the role of project manager. First, communication is mentioned in both duties and requirements. As with all types of knowledge work, good communication is crucial. The project manager is the main conduit for information flowing into and out of the project. Second, one of the most important responsibilities of the project manager is balancing the competing constraints on time, resources (primarily money), features and team morale. This is summarized nicely with the expected duty:

Deliver projects on time, on budget, with delighted customers and a happy team.

The data also give some indication of the percentage of effort a project manager can expect to devote to each function. If the number of duties within each function is any indication of the percentage of effort likely to be devoted to the function, it's reasonable to conclude that project managers will spend most their time on planning followed by control.

Project Life Cycle

The project management activities of planning, organizing, staffing, directing and controlling have to be coordinated with the software development activities of requirements gathering, design, implementation and testing. Just as the product of software development moves through a sequence of phases marked by product-oriented milestones, the project as a whole moves through its own sequence of phases marked by project-oriented milestones (See figure 5).

Figure 5. Product and Project Milestones

The major project-oriented milestones are:

• Initiation – The project is defined and approved. The main deliverable of this phase is a project charter.
• Planning – Activities needed to deliver on project objectives are planned. The main deliverable of this phase is a project or iteration plan.
• Execution, Tracking & Controlling – Work is performed as described in the project plan. The bulk of the project effort will be expended here but other than tracking and controlling it’s not a busy time for the PM. The main deliverable of this phase are status reports showing that the project is on track to meet its established goals.
• Closeout – The customer accepts results and the project team reflects on what went right and areas for improvement. The project team might also do casual analysis on problems in order to identify their root causes and what might be done to improve performance on future projects or iterations.

Figure 6 shows the approximate timing of the major phases in the project life cycle relative to those of product development. Project initiation defines the scope of the project which sets the stage for requirements gathering. During the requirements phase the product definition takes shape. The product requirements drive project planning.

Figure 6. Timing of Project Life Cycle Phases Relative to those of Product Development

Output of project planning is a schedule and budget for performing the detailed technical activities of product development. Simultaneous with construction activities, progress is measured and corrective actions are taken as needed to keep actual performance in line with planned performance. Plans aren't immutable though. The necessary corrective action might very well be to change the plan.

At the end of the project or iteration, closure is reached with the customer and lessons learned are documented.

The diagram above is a conceptual diagram designed to show the general relationship between the phases of product development and those of project management. It should not be interpreted as suggesting a purely sequential ordering of either work-flow. Project management is no more a sequence of discrete activities with definite start and end points than product development is. Just as requirements, design, implementation and testing can overlap, so can project initiation, planning, control and closeout. For example, on a project following an agile methodology, the planning milestones might be a release plan at the beginning, an iteration plan at the start of each iteration and a daily stand-up planning meeting at the beginning of each day. It's up to the project manager and project team to decide on an appropriate set of milestones based on the individual needs of each project.

The Four Variables of a Project

Every project has to balance the desire for features and quality with constraints on time and cost. Time and money are always in short supply and the desire for features and quality is limitless. There is rarely enough time or money to deliver all of the features and quality the customer can use. Consequently, project success depends on finding an optimal balance among these four variables.

Figure 7. Desire for features and quality has to be balanced with constraints on time and cost

In more detail, the four variables of a project are:

Time. Time, or duration, is the amount of calendar time available to do a project. Time is sometimes confused with effort which is the total number of hours spent working on a task. If someone works half-time on a task for two months, the effort is one person month but the duration is two months. (The distinction between duration and effort is examined in greater detail in chapter 5.)

Cost. Cost is the amount of money available to do a project. Money by itself doesn't create software, but money purchases human effort which is the force that creates software. With more money you can obtain more effort by either hiring more people or investing in items that make existing staff more product (i.e. tools, motivational rewards, personal concierge services, etc.).

Features or Scope. Features are what the software can do. It is convenient to include in this variable not only functional requirements but also any work that is negotiated and prioritized alongside functional requirements. This includes non-functional requirements like usability and performance as well as the work it takes to correct non-critical defects. If the cost of fixing a few minor defects is the same as adding a new feature, the customer may elect to endure the defects (at least for awhile) in exchange for increased functionality. The term "scope" more accurately accounts for the diversity of work that makes up this variable and is often used in place of "features" when there is a need or desire to acknowledge the range of tasks that make up the work of a project.

Quality. The term "quality" means different things to different people. In the context of project planning, "quality" can mean freedom from defects and/or the degree to which non-functional requirements such as usability, reliability, and security are present in the final product. Since non-functional requirements have characteristics (in terms of planning) that make them interchangeable with product features, it makes more sense to include non-functional requirements with features and define quality here as the number and severity of defects.

The Software Equation

The following conceptual equation illustrates the relationship between the four variables of a project. Using algebraic symbols, it suggests how a change in one variable will impact the others. For example, it says that customers wanting more features must be willing to accept one or more of higher cost, longer schedule, or less quality.

Cost * Time = Features * Quality

Figure 8. The Software Equation in Four Variable

The software "equation" above is a conceptual one. (See chapter 22 for a real mathematical equation for computing project cost and duration as a function of software size.) The mathematical symbol for multiplication "*" gives the right intuition about the relationship between variables, but it doesn't accurately capture the nuances of the trade-offs. The software equation above is a useful "formula" for conveying the concepts as long as you keep in mind:

• The true relationship between the variables is non-linear and in some cases non-monotonic. If the customer asks for twice as many features you can't simply double cost to compensate for the added work. When it comes to quality, there is a sweet spot where both higher and lower levels of quality will tend to increase costs.

• In some cases there is a time lag between a change in one variable and its effects on the others [Planning Extreme Programming]. If you stop including pre- and post conditions in your code you might get a short-term boost in productivity but the long-term consequences are likely to be negative. Also, when you add staff (an increase in cost) an increase in output (number of features and product quality) is delayed until the new staff members are fully productive and stop negatively impacting the productivity of existing staff members. People and time are not interchangeable in the short run.

• There are practical limits to how much a change in one variable can be compensated for by a change in another. There are times when even an infinite amount of money isn't enough to have certain features completed by a certain fixed deadline.

What follows is a closer look at the true relationship between these four variables. To simplify the discussion, changes in only two variables at a time are considered.

Features Versus Cost

How does adding more features effect cost when quality and schedule are held constant? In general, when work is simple and easily portioned among those doing the work, cost scales linearly with product output. If three people can paint one side of a fence in one hour, six people can paint both sides of the fence in the same amount of time. Assuming everyone is paid the same wage, doubling the size of the job doubles the cost.

Figure 9. Cost scales linearly when work is perfectly partitionable

Software production doesn't scale as nicely. If you double the number of features planned for a project and you want to keep the same schedule (and quality), you will need more than double the number of people. You can't simply double head count because as team size grows, individual productivity drops. There are technical as well as organizational reasons for this.

On the technical side, the cost of adding a feature grows with system size. In general, the cost required to implement the ith feature will be a bit more than the cost of the i-1th feature. Each additional feature requires a little more effort to implement than the one that came before it because new code isn't completely independent of existing code. New features must integrate with existing code. As system size grows, it takes more effort to understand the existing system to the point that code changes can be made and validated. Taken to the extreme, systems can grow so large and so complicated that they resist any changes at all. A good system architecture that divides the software into loosely coupled modules can slow the growth in complexity, but can't completely eliminate the problem.

Another reason it takes more than twice as many people to implement twice the number of features is that larger teams are less productive than smaller teams. Just as it is difficult to have isolated independent code modules, it's difficult to to have isolated independent project tasks. The communication needed to coordinate concurrent tasks adds to the overall work of the project. Figures 10 and 11 illustrate this dynamic. As team size grows, individual productivity drops. Small teams are more productive because they spend comparatively less time on communication and coordination.

Figure 10. Small groups are more productive because they spend a smaller percentage of their time on communication and coordination

Figure 11. As team size grows, individual productivity drops

The features-cost curve, then, looks something like that shown in figure 12. The relationship between features and cost is non-linear [Putnam 1996, p8]. As product size grows (as measured by lines of code, function points, stories, etc.) the cost or effort per unit of product grows even faster. Software development is one of the few production processes in the world that has dis-economies of scale. When paying for new code, instead of getting a volume discount you pay a volume premium.

Figure 12. Non-linear relationship between features and cost

Time Versus Cost

This section considers how shrinking or lengthening a project's duration effects cost when features and quality are held constant. Time is money, so customers often are willing to pay more if it means having their software sooner. There is a limit, though, to how much a schedule can be compressed. A project expected to take one person 60 weeks can't be completed by 60 people in one week no matter how much money is thrown at it. This is true because a certain portion of the work is fundamentally sequential. You have to know the requirements before you can write the code. You have to write the code before you test it, etc. No matter how many people share the work, certain activities have to be performed in sequence and having more people doesn't shorten the time it takes to complete these sequential activities. As Fred Brooks noted, "The bearing of a child takes nine months, no matter how many women are assigned."

Figure 13 illustrates the delicate balance between time and cost. Every project has a nominal schedule which is the expected amount of time it will take to complete the project under normal circumstances without rushing. It is possible to compress this schedule somewhat, but the cost of compressing the nominal schedule escalates quickly and there is a point beyond which it is impossible to compress the schedule further. Schedule compression is accomplished by increasing staff and doing more work in parallel. It is the increase in staff that raises the cost. (The previous section explains why an increase in staff lowers productivity and increases unit costs.)

Figure 13. Non-linear relationship between time and cost

The area of the graph representing a schedule compressed beyond 75% of the nominal schedule is considered the "impossible region" because there is no convincing evidence backed by credible data of any project every finishing within this zone [Boehm 81, p 466]. The existence of this region is one more reason to keep historic data on completed projects. Without measurement data on completed projects, you can be tricked or bullied into committing to a schedule that falls within the impossible region.

For more on the trade-offs between staffing and schedule, including the dynamic effects of increasing staff, see "People and Time are not Interchangeable" in chapter 7.

Quality Versus Cost

The relationship between quality and cost depends on how you define quality. Figure 14 shows the relationship between quality and cost when quality is taken to be the rate at which defects are introduced into the product.

Figure 14. Non-linear relationship between quality and cost where quality is defined as the number and severity of defects

According to figure 14, you can have your quality cake and eat it too. When all of the expenses are added up, producing a low-quality product actually costs more than producing one of higher (but not perfect) quality. If an organization is consistently finding fewer than 95% of defects before customer acceptance, there is an opportunity to improve quality without increasing costs.

Research shows that a defect removal efficiency of 95% is about optimal. Defect removal efficiency is the percentage of defects detected before the software is released. A defect removal efficiency of 95% means that 19 out of 20 defects are detected before the product is released*. At this level of quality the cost of preventive measures such as testing and inspections is more than offset by a reduction in costs associated with poor quality work. Organizations operating at less then 95% removal efficiency are leaving money on the table. They could have shorter schedules, lower costs and increased quality simultaneously. (See chapter 21 for more on the trade-offs between cost and quality.)

____________________________
* The software has to be in production for a certain duration (usually 1 year) before you can calculate defect removal efficiency. Defects are tracked during this time in order to know how many latent defects were in the product when it was released.
____________________________

Costs rise rapidly as quality approaches perfection or zero defects. Ultrahigh levels of quality can be costly but are justified for certain life- and business-critical applications. For example, NASA spends about $3.5 million a year just for testing the approximately 476 KLOC that make up the primary flight control software for the Space Shuttle [Zelkowitz 2001].

The quality-cost curve takes on a different shape when quality is defined as the degree to which non-functional requirements like usability and adaptability are present in the software. This interpretation of quality produces a quality-cost curve (see figure 15) that is equivalent to the features-cost curve shown earlier (see figure 12). The work needed to implement non-functional requirements has the same cost and schedule consequences as the work needed to implement functional requirements. In both cases you are going through the activities of requirements, design, implementation and testing. Skimping on non-functional requirements might impact customer satisfaction, but it won't raise the cost of rework the way higher defect rates do. When attempting to balance the software equation, non-functional requirements can be treated like functional requirements.

Figure 15. The relationship between quality and cost where quality is the degree to which non-functional requirements are present

Finding an Optimal Balance

All projects have to operate within the constraints of the software equation. Just as electrical engineers have to abide by Ohm's law, software engineers have to act in accordance with the software equation. 

Cost * Time = Features * Quality	Volts = Resistance * Amperes
Software Engineers are constrained by the Software Equation	Electrical Engineers are constrained by Ohm's Law

 Figure 16. Equations set limits on what is feasible

Customers typically press for favorable treatment of all variables--they want it fast, cheap and good (See sidebar). However, there are trade-offs among the four variables which makes it impossible to optimize them all. Project success depends on finding an optimal balance among all four. There will be inefficiencies if the balance tips too much either way. If values for the four variables are set at a point where cost and time are excessive, the project won't be competitive. If feature and quality goals are set too high, the project isn't likely to succeed and will be inefficient in what it does manage to accomplish.

 

 

The project manger works with the customer and other key stakeholders to find the optimal balance among the four variables. The dialog starts with the customer identifying which variables are fixed and the degree of freedom with those that aren't. Here are some examples of fixed and variable constraints:

• "If we don't have these 15 features, we won't be competitive in the marketplace." (Features are fixed.)

• "If these 3 additional user stories can be completed by February, the client is willing to commit additional funds." (Cost has some flexibility.)

• "We absolutely have to have this working before the trade-show in July." (Time is fixed)

The customer then identifies the priority among variables that have a degree a freedom. Cost estimates for features are provided by those expected to do the work. The project manager uses this data to come up with options for balancing the software equation. The customer selects among the options.

There is a myth in project management that the customer is free to set values on all but one of the variables. It is an "equation", so in theory this should work. In practice, however, there is a limit to how much one variable can balance unconstrained values for the others.

The key points to remember when trying to balance the software equation are:

• There are trade-offs among the variables of a project and it's impossible to optimize them all.
• The customer sets priorities but can't dictate all variables. There has to be a degree of freedom with at least one variable.
• The variables are strongly interdependent. Anything beyond a small change in one variable will impact most, if not all, of the other variables.

Variations on the Software Equation

The four-variable version of the software equation strikes a reasonable balance between including enough detail to be useful but not so much to be overwhelming. Sometimes its useful to consider variations of the equation that include fewer or more variables.

Three Variables

According to the rule of threes, people tend to have an affinity for lists of three. This principle is used to great effect in comedy. Notice that it is always three people walking into a bar ("A priest, a rabbi and a minister walk into a bar …”), never 2 or 4. Lists of three appeal to something deep within our mammalian brain. Perhaps as a consequence of this, the main constraints on a project are often presented as three rather than four variables. In this simplified form of the software equation, features and quality are combined into a single measure of performance or scope (See figure 17). The resulting model is often referred to as the project triple constraint or iron triangle.

Figure 17. The Project Triple Constraint or Iron Triangle

The project triple constraint is a convenient short hand for discussing the main control variables of a project, but use it with caution. There is some risk in not treating quality as an explicit control variable that is openly defined, measured and tracked. The concern is that when the going gets tough (and it always does), quality will be compromised not because it is the best lever for balancing the software equation but because it is the least visible one.

No one sets out with the intention of compromising quality, but late in a project there is inevitable tension among the four variables of a projects. The problem usually starts with schedule pressure. How a project responds to schedule pressure often depends on what is being measured and tracked. If there are documented schedule, budget and feature goals but no written quality goals, it's not hard to guess which one is likely to be compromised. It may very well be that quality is the best candidate for compromise, but there is no way to know this if quality isn't being tracked as a separate variable.

Quality is a particularly vulnerable target because the effects of poor quality often aren't completely felt until after the project has been completed and declared a success. Compromises to quality don't have to occur as a result of willful deceit either. Inadvertent compromises to quality can occur as the result of wishful thinking or naivety. ("Things seem to be going pretty well. Maybe we don't need all the time we allocated for system test.") Making quality goals explicit makes it harder to compromise quality inadvertently without recognizing it or deliberately without acknowledging it.

Five and More Variables

Managers of software projects are frequently pressured to commit to unrealistic schedules and budgets. The software equation is a tool that can be used to combat unreasonable demands. When asked to take on a project with an impossible schedule, the project manager can point to the software equation and proclaim, "Sorry, we can't commit to your proposed schedule. The software equation would be out-of-balance." Be forewarned though, an astute customer may well respond, "There is nothing absolute about your equation. Your equation assumes a certain level of productivity. When you say that it is out-of-balance, what you really mean is that it is out-of-balance for you and your team at your current level of productivity."

Indeed, the software equation given above isn't absolute. It does have an implied productivity factor. Here it is again with the productivity factor made explicit:

Cost * Time * Productivity = Features * Quality

Figure 18. The Software Equation in Five Variables

Productivity is output per unit of labor. As productivity rises you can deliver the same number of features in less time at less cost.

One way of expressing productivity in software development is LOC per person month. It is important to understand that "productivity", as it is used in the equation above, doesn't represent individual productivity, but rather, process productivity which is a measure of the efficiency and effectiveness of an entire team or organization. This broader definition of productivity encompasses many factors including [Putnam 96]:

• Tools and programming language
• Methods
• Skill and experiences of the team
• Application type and complexity

Substituting these factors back into the software equation gives the rather long formula:

Cost * Time * (Tools * Methods * Team Capability * 1/Complexity) = Features * Quality

A change in any one of these factors of productivity will effect the balance of forces on a project. For example, giving a team better hardware and software tools will allow them to deliver more features for the same amount of time and money.

The main variables that effect project performance are time, cost, features and quality, but as the expanded form of the software equation above shows, there are many other secondary factors also involved.

There is at least one potential hazard that must be guarded against when productivity is factored into the software equation: the temptation to balance the software equation by assuming dramatic leaps in future productivity. "I know our historic data show very little chance of completing this project by the proposed completion date, but our productivity numbers don't reflect our true potential. We experienced some bad luck resulting in one-time problems on those past projects. We are likely to be much more productive going forward. Let's assume a 25% gain in productivity for this next project."

Team productivity can go up or down. Productivity is likely to remain unchanged between projects baring any major changes in personnel or new investment in software process improvement. [TBD: Did Putnam say an 11 percent increase in process productivity per year is about average [Putnam 1997]? I need to check this. I suspect this conclusion comes from Industrial Strength Software: Effective Management Using Measurement.]

What Can and Cannot Be Negotiated?

At the start of a project the project manager creates preliminary estimates for cost and schedule based on what is known about the project. The customer's first reaction to the estimates is often sticker shock. Not infrequently, their second reaction is to try and negotiate a better deal for themselves. There is nothing wrong with healthy negotiation per se; it can often lead to outcomes that maximize value for everyone. However, if you do find yourself negotiating the terms of a project, it's important to understand what can and cannot be negotiated.

Things that cannot be negotiated:

• Estimates. An estimate is a prediction of the cost or duration of a project. There are many different estimation techniques but one thing they all have in common is they produce estimates based on inputs such as project requirements, historical project data and personal experience. If the estimation process is agreed upon in advance, the estimates can not change unless the inputs change. Customers may wish estimates for cost and duration to be lower, but they can't be negotiated lower. You can only change the inputs and rerun the estimation process.
• Relationships between parameters. There are trade-offs between parameters in the software equation. How changes in one variable effect the others is well established (see discussion above). These trade-offs are intrinsic to software. You can't change the nature of software through negotiation.

Things that can be negotiated:

• Trade-offs among parameters. Working with the customer, the project manager can suggest various options for balancing the software equation and maximizing value. The conversation might go something like this: "If schedule is your first priority, we could meet your schedule goals by either dropping these two features or dropping one feature and increasing the budget by 15%." Negotiating trade-offs among parameters is one of the best ways to maximize value from work performed.
• Targets and Associated Risk. Targets are different from estimates. Targets are desired business objectives. You can negotiate what targets the team will work towards, but when you do you have to be willing to accept the associated risk. So in essence, the negotiations are over targets and associated risks. When estimates differ substantially from targets, there is a high probability the project will fail. Customers and project managers can negotiate what targets to aim for and how much risk they are willing to accept.
• Unpaid overtime. When targets and estimates are far apart, the only practical way of completing the project on time and within budget is for the team to work significant unpaid overtime. There is a limit to how far and how long a team can be stretched before productivity starts to diminish. Habitual pressure to work long hours leads to low morale, burnout and high turnover. Unpaid overtime is an option that can be negotiated but it should be negotiated with full understanding of the consequences.

Perhaps even more important than knowing what can and can't be negotiated is simply recognizing what is being negotiated. The customer might start the conversation with, "Let's talk about these estimates. There is no way I can accept these numbers. You need to shave at least three months off the schedule." The customer is using the word "estimate" but what is really wanted is a plan for hitting a business target. Both sides need a clear understanding of what is being negotiated. In this case the conversation is gearing up to be a negotiation over how much risk everyone is willing to accept and expectations for unpaid overtime (and the consequences it brings).

Characteristics of a Well-Run Project

A well run software project is a partnership between the customer and the development team. As with any good partnership there are certain rights and responsibilities on both sides.

Customer's Bill of Rights

The customer has the right to [McConnell SPSG]:

1. Set objectives for the project and have them followed.
2. Be presented with accurate estimates for the cost and duration of the project with a level of precision that is commensurate with the level of detail, certainty and stability manifest in the system requirements.
3. Decide which features are in and which are out of the software.
4. Make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes.
5. To know the project's status clearly and confidently.
6. To be apprised regularly of risks that might affect the outcome of the project and to be provide with options for addressing potential problems.
7. Have ready access to project deliverables including product increments throughout the project.

Project Team's Bill or Rights

Members of the development team have the right to [McConnell SPSG]:

1. Know the project objectives and to clarify priorities.
2. Know in detail what is needed and to clarify the product definition if it is unclear.
3. Have ready access to the person responsible for making decisions about the software's functionality.
4. Work in a professionally responsible way.
5. To approve the effort and schedule estimates for any work they are asked to perform. Members of the development team also have the right to revise estimates whenever requirements change or assumptions on which earlier estimates were based change.
6. Have the project's status reported accurately to customers and upper management.
7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.

Notice that one person's right is another person's responsibility. There is also an interdependency. Take away one right and it is likely to impact the ability to deliver on a responsibility which is likely to impact a right, and so on until all rights are lost.

These rights and responsibilities give both customers and developers the confidence and security they need to be effective. Without these rights there is fear and mistrust on both sides which prompts participants to slip into survival mode where their primary instincts take over and the objective becomes protecting their own self-interests at the expense of the common good.

References

Winston, Alan. Retrieved 2006. http://www.touregypt.net/featurestories/pyramidworkforce.htm

Girin, Bruno. Pyramid Photo retrieved 2006.

Musselman, Dale. Roman Aqueduct photo retrieved 2006.