Constraints of Software Development

There are five main constraints in software development management: people, time, functionality, budget, and resources (excluding people). Agile methods recognize these constraints and seek to protect and exploit them.

Resources must be protected from uncertainty. Uncertainty manifests itself when the unplanned happens. A system can absorb uncertainty with the provision of buffers. Tom DeMarco wrote an entire book Slack, about buffering resources in software!

In every case, a constraint can be protected by a buffer. A buffer would normally be allocated in the same unit of measure as the constraint is measured. Hence, people should be buffered with people, schedule with time, budget with money, functionality with requirements, and other resources with similar resources.

Protecting the People Constraint

All Agile methods recognize that software development is an innately human activity. It is performed by people. Therefore, people are the single most important potentially capacity constrained resource in software development.

As the single most important resource on a software project, people must be protected. There is more than one way to provide a buffer for the people. The most obvious is to have more developers than needed. The second is to assume that the people are only productive for a subset of the work day. My favorite number is 5.5 hours. This is a personal choice. Others may suggest different numbers. Buffers must also be introduced to accommodate vacations and ill-health. A wise manager will buffer a little more for unpredictable, life changing events such as a death, birth, marriage, terminal illness, and divorce and more esoteric ones such as fire at home, flood, earthquake, automobile accident, sports injury, and, most recently, military service. Typical American high technology employers with whom I have worked seem to assume that they get 48–49 weeks per year of labor from a software developer. Futhermore, they often assume that the employee will work an average of 9 to 10 hours per day when only paid for 8 hours. A good manager who understands that his people constraint must be buffered will assume much less. My personal choice is to allow 15% for vacation and other outage, that is, a 42–43 week work year, coupled to 5.5 hours of productivity each day.

When executives see these hard numbers written down, there is often an adverse psychological effect. Therefore, it is vital that senior management understands that software is an innately human activity and that software developers are not machines that can be switched on and off like the lights.

How big a people buffer is needed? The answer is that buffer size varies with uncertainty. The greater the uncertainty, the larger the buffer must be. There is some possibility that a project will suffer from no downtime or people outage. It is just possible that no one will get sick, get married, have a baby, or suffer a loss of a close family member. It may even be a time of year when no one is interested in taking a vacation. Such times are rare.

It is important that this people buffer is added to the project early.

Uncertainty will vary with the length of the project. With a very short project, there is little uncertainty about people. With a longer project, there is more scope for things to happen unexpectedly. However, it is better to think of software development as an on-going process where projects are simply inventory passing through a system of software production. In which case, it is reasonable to suggest that people-related uncertainty tends to level out at a predictable level. The numbers I gave above (43 weeks and 5.5 hours) are numbers based on my experience—my own empirical evidence. Others may observe different empirical data.

Protecting the Time Constraint

Every finished product or project has a desired delivery date or a predicted delivery date. A desired delivery date is when the customer asked for delivery. A predicted date is when Engineering (or IT) estimated they could deliver it. The important thing is that a date is agreed upon by the software development organization and the customer. This date is a system constraint. A date gets promised, and it is bad business to break promises.

Sometimes, the delivery date has been set for hard business reasons. For example, a change in government regulations is being introduced, and the new product must be delivered in order for the customer to meet its legal obligations. In other words, the date constraint is imposed from outside the organization and is totally outside the control of anyone in the organization. Such hard delivery dates are common in heavily regulated industries such as investment, finance, banking, tax and audit, telecommunications, power generation, and other public utilities.

If the delivery date is a constraint, it must be protected by a time buffer. The length of the time buffer must be based on the uncertainty involved in the project. The uncertainty must be assessed with respect to the technology, people, subject matter, architecture and delivery environment, the maturity of the organization, and a number of other factors such as the reliability of upstream suppliers.

For example, consider a relatively mature software development organization that might audit as SEI SW-CMM Level 3. With a project that looks similar to one just completed, uses the same architecture, has an existing and experienced team, uses the same technologies, and has subject matter well known and understood by the everyone involved, the company might just be 100% certain that the project can be finished on time. In this case, with 100% certainty, I would use my minimum buffer number of 15%.

On the other hand, in a newly formed start-up with a new team, a poor understanding of the subject matter, and a new challenge that requires bleeding-edge technology, it is fairly certain that a lot can and will go wrong. This must be planned for. A good textbook answer for buffering in such a situation would be 200%. In reality, it is only possible to get away with such a buffer, if there is no process maturity and no one making public guesses as to how long the project should take. In many cases, a development manager will find it impossible to gain agreement on 200%. In which case, I would suggest a fallback position of no less than 100%.

In order to read this table, you must understand the measure of certainty. Certainty is the percentage likelihood that a task will be completed on time. The 100% certainty implies that similar tasks always complete on time. If only one in every two tasks tends to complete on time, then the certainty would be 50%. In reality, certainty is the gut feeling of the developers who are on the spot. If they feel confident, they may estimate 90% certainty. If they've never seen something before and have no idea how to do it, they are more likely to estimate <50% certainty. For example, if a developer estimates a job as 1 month, with a 40% certainty of completion, then the estimate should ideally be inflated by 2 to 3 months.

Protecting the Scope Constraint

The functionality of the system represents another constraint. Once again, the agreed scope represents a promise. Failing to deliver the agreed functionality means a broken promise. Broken promises are bad for business.

If the scope constraint is to be protected, it must be buffered with more scope. In essence, the manager must gain agreement with the customer that some of the scope would be "nice to have" but doesn't need to make it into the currently agreed deliverable.

In other words, if the scope constraint is to be protected, then the scope of required functionality must be prioritized. The customer (or product marketing) must determine the ranked order of importance for the functionality in the scope. This could be as simple as assigning a value on a 3-point scale to each required function, for example, "must have," "preferred," and "nice to have."

Functionality priority is actually a two-dimensional problem. When a customer is asked how important any given feature in the scope might be, the answer is likely to be, "It depends." What the customer means is that the importance varies according to the delivery date. This is best explained with an example.

With an investment banking application, a new feature is required to meet new government legislation. The feature must track stock trading activity of "insiders" within periods shortly before public announcement of trading results. The new law takes effect at the beginning of the fourth quarter. If the customer is asked how important the feature is, they will say it is a "must have" feature. The company stands to be heavily fined if the feature is not delivered on time. However, if the question is rephrased to ask how important the feature is for delivery by the end of the first quarter of the same year, the answer will be different. Naturally, the feature is useless at that time. Early delivery makes everyone feel comfortable about the new regulations, but it is not necessary for the business. The new feature will not be used until October 1. There is no Throughput value in early delivery.

Hence, it is important to gather the time-varied priority for each requirement in the scope. The program manager should plan to agree on a scope with the customer that includes a number of "nice to have" requirements that perhaps later become "must have." Engineering would agree to schedule these requirements in the plan, but the customer agrees to let them slip, in the event of unplanned events disrupting the schedule.

I can hear a chorus of people shouting, "Wait! You can never get agreement on such a scope buffer." Why not? This is caused by a lack of trust. The customer will assume that buffered requirements will never be delivered. This is based on experience with poor software development organizations who never deliver what they promise and would certainly never overdeliver. Hence, the scope is nonnegotiable.

As a precursor to ever being able to buffer scope, a development organization must provide end-to-end traceability, transparency, and repeatability. It must be capable of building trust with its customers and showing that it can deliver on promises. Only when the customer learns to trust the software development organization, through an understanding gained from visibility into the software process, will the customer agree to prioritize and buffer scope.

Hence, it should be taken de facto that scope buffering is not available to the immature software production system as a protection mechanism against uncertainty. Trust must be earned through a series of deliveries that met expectations. After this, it is possible to negotiate a scope buffer.

Trust

Establishing trust is the most important goal for any development manager. Trust is the most valuable weapon in a development manager's arsenal. Trust is gained through a combination of transparency and delivering on promises. Show people how the system works, what is involved, how long it takes, and what went wrong when it does go wrong, and trust will grow. Lack of trust is usually a symptom of lack of understanding. The organization doesn't need to run like a well-oiled machine. It doesn't need to perform like an automaton in order to win trust. It is all right for things to go wrong. Customers understand human frailty. In fact, they often like it. What they want to see is honesty. They will accept problems occurring when they can see and understand the reason for them.

It is possible to build a customer relationship where buffering scope is a regular occurrence. It requires a mutual trust. Trust must be earned. Managers can earn trust by delivering on a few promises.

Hence, it may be easier initially to use buffers in time and people, to insure that the agreed scope is delivered. It may not be possible to buffer scope until a mutual trust is established. After two or three projects or product deliverables which were on time, and on budget, the customer may be willing to discuss prioritizing requirements and buffering scope.

Protecting the Budget Constraint

The budget for a development project is very important. If it is underestimated, money may run out and the project will fail to deliver. Failure to have enough money may result in a broken promise. Exceeding the budget represents another broken promise. Broken promises are bad for business.

Budget is buffered with money. It is that simple. How much money is needed? Once again, the size of the buffer will depend on the uncertainty. General operating expenses have a low uncertainty. Generally, the cost of the developers and their immediate overheads for office space and other costs are relatively predictable. A buffer will be needed to cope with technology and subject matter uncertainty. In other words, the larger the time buffer, the larger the budget buffer must be.

A budget buffer is needed to cope with time overrun, that is, use of the time buffer. More may be needed to cope with unforeseen costs related to technology or subject matter.

For example, if it is discovered that the team will have to invent a whole new class of middleware in order to meet the requirements, the project has been landed with some unforeseen work to meet nonfunctional (architectural) requirements. Perhaps, it is discovered that the team will need a new, expensive development tool, or the team chooses to buy components or middleware to save time and reduce risk. Technology uncertainty or risk reduction can result in extra budget demands.

When the subject matter for a new software product is poorly understood, the estimate of its complexity may be in error. As the scope is investigated during analysis and design, an area of the requirements may prove to be much more involved than previously thought. This may result in the estimate of the inventory in the system increasing. I call this discovering of unseen inventory, the revealing of scope "dark matter." Dark matter is the stuff of the universe that is known to exist, but cannot be seen or measured. Every project has a degree of dark matter. The newer the subject matter, the more dark matter there is likely to be. If the project is a Human Resources Management system with a team that has done it all before, the chance of a significant mistake in the scope and inventory estimate is unlikely. However, if the project (writing in 2003) is a leading edge wireless, enterprise resource planning system designed to run over a public packet data network delivering ERP to mobile employees in a distributed B2B value chain, then it is new territory. The need for a budget buffer to cope with uncertainty is very important.

Protecting the Resource Constraints

Other resources for a software development organization include desktop computers, all servers, network, backup systems, printers, disk storage capacity, paper, meeting rooms, wall space, tables, chairs, desks, water fountains, vending machines, and toilets, to name just a few.

It is important to remember that because software is an innately human activity, the majority of the costs are incurred by the people. If a day is lost from a developer's time because a PC broke down, it is possible that Throughput for the whole system may have been lost. It is, therefore, vital to know where the constraint is within the system of software production. If a developer works in the constraint and produces a unit of production per day and the software production system averages $10,000 of Throughput per unit, then the cost of losing one developer for only one day could be $10,000.

It doesn't make sense to lose development or test resources because of a failure in equipment. It is essential to have enough equipment for everybody and a buffer stock. The team must not lose efficiency because there is no water in the fountain or tissue paper in the toilets.

How many resources are needed in the buffer? Again, this depends on the uncertainty. These days PCs are very reliable. Perhaps you only need one or two spares for a whole business unit. Servers do not seem to be so reliable. Disk drives seem to wear out. Networks can be unpredictable, too. So can the power supply. Is the organization located somewhere that lost its power due to exceptional weather conditions—flood, snow, or ice-storm? Is the location a place where the power grid is unpredictable and brown-outs are common? It is important to protect the most precious resource and the biggest constraint—developers. In order to do so, resources must be buffered.

Local Safety

There is a recognized problem with estimating fine grained tasks or deliverables. This problem is known as the "local safety" problem. It can lead to significantly inaccurate estimates caused by explainable human psychology.

If asked how long a small task will take, a developer will naturally not want to deliver it late. After all, this is a small task, it should be on time or the developer wouldn't be professional. Hence, the estimate will include a buffer to absorb the developer's uncertainty about the task.

The estimate given by the developer will depend on how confident that developer is that he has understood the task and knows how to perform it. If there is uncertainty in the understanding of the task, then the estimated time to completion is likely to be significantly longer. No one wants to be late with such a small task. Overconfidence can lead to some estimates as little as 5 days. Other estimates will be as long as 30 days. Goldratt predicts that developers with an 80% confidence about the task duration will suggest around 20 days for the task. The difference between 20 and 12 is known as the local safety, that is, 8 days.

So a 12-day task may be estimated as up to 30 days. Imagine if this was to happen across a project with 2,000 tasks. The estimates for the whole project would be wildly inaccurate. In fact, the project might look so costly that it is cancelled before it is even started.

How can this problem be avoided?

Goldratt's first truly astute assertion about project management is that in an accurately planned project consisting of many tasks, approximately half the tasks will be slightly late, assuming the planning was accurate. This is very counterintuitive, but it is a fact. If a project is accurately planned and delivered on time, statistically approximately half the tasks should be early and half should be late. Accepting this notion is hard, but once accepted, it is possible to consider the solution.

Accurate project planning techniques must avoid asking developers to estimate small tasks based on effort. The tasks to be performed must be broken out based on some form of (relative) complexity and risk. To work best, this requires a codification scheme for assessing the complexity and risk. An analysis method that enables small pieces of client-valued functionality to be codified for complexity or risk is required. This enables the inventory in the system of software production to be estimated without the psychological effect of local safety. By not asking the developer to estimate how long it will take, the local safety problem is removed.

Hence, complexity and risk analysis of the inventory are the keys to providing estimates without local safety. There are several techniques for doing this: Function Points in structured analysis, Feature Complexity in FDD, and Story Size and Risk Points in XP.

It is possible to correlate the level of effort involved in a given unit of inventory through empirical measure. Historical data for recent projects can be used to estimate the level of effort involved in processing inventory of a given risk or complexity. This data can then be used to estimate how long it will take to process the remaining inventory through the software production system.