Why Outsourcing Fails

Every year, we see corporations outsource operations only to pull back back some, if not all, of the operations. When this happens, the cost of pulling back operations or splitting things over multiple countries can leave you with significant operational issues and similar or worse costs.

Successful corporations understand the need to control costs in operations. The "spare no expense" philosophy of John Hammond in Jurassic Park is a one way ticket to disaster.

But, a focus on cost reduction is what leads corporations to face-fault when they outsource.

Corporations are seduced by the idea of potentially cutting costs dramatically; why pay expensive resources to do repetitive things when overseas people can do the same work for pennies?

The cardinal rule when outsourcing is:

Only operations that you completely understand and control can be outsourced 

To understand operations is to understand the costs of exceptions as well as how they are processed and escalated. Local resources deal efficiently with exceptions because they have informal relationships in the organization and use them to get things done efficiently; those relationships are not available to outsourced resources.

When operations gets outsourced, not only do foreign employees not understand how to deal with exceptions but also:

• They are often in another time zone 
• They don't have full access to local resources 
• They don't know who to contact inside the corporation 
• They don't understand local business rules 
• The network configuration can make it impossible to communicate properly 

Understanding an operational function means that you capture all details, including exceptions, in your information systems. Often, legacy information systems capture exception information as unstructured fields (i.e. memo fields) and off shore resources will not understand this.

99% of your operations might be straight forward, but the 1% of exceptions can at best lead to longer implementation times.  Best case scenario is that you will look bad to your customers and at worst, it will kill your bottom line.

If your information systems contain exception information in a structured way then at least you can eventually train foreign resources to resolve them. But unless exception information is captured so you can control it (i.e. not in general text fields) then it is the same thing as not having it.

When outsourced resources are under strict performance guidelines, they will do anything to clear their work queues. This often involves kicking back work they perceive as an exception as improperly specified; they will claim 'garbage in, garbage out'.

This will result in miscommunications and longer lead times to implement your services. Not only will delivery times, and errors go up, and your customers will get mad.

By the time you have fired the local employees, all the knowledge of the function has left the building and you are left with a broken system.

Key questions to get answers to:

• What does each exception in operations cost? 
• How often do they happen? 
• Can the information systems record exceptions in a way that you can track and control them? 
• Are the mechanisms that local resources use to resolve exceptions be used by outsourced resources? 

If you don't have a clear answer to each of these questions then outsourcing is likely to be a disaster. When you have a clear answer to the 3 questions and understand how you will address each exception then you will have much more success outsourcing.

Do Project Managers need Domain Experience?

Opinions vary on whether a project manager needs to have domain experience.  Certainly project managers that do not have domain experience will be the first to say that domain experience is not necessary as long as they have access to excellent subject matter experts.

I would advocate a more nuanced position; that is, a project manager does not need domain experience IF his subject matter experts understand the risks and dependencies that are inherent to the domain.

Let's go through a couple of personal projects that I have been involved with where the project manager did not have domain experience.

Telco Project

I am currently involved in a project that involves a LAN/WAN/WIFI upgrade of a large customer for a large telecommunications company.  The project manager does not have domain expertise in networks and is counting on the subject matter experts to provide him sufficient input to execute the project.

The subject matter experts are so advanced in their knowledge of networks that they no longer understand what beginners (i.e. the project manager) do not know.  They have assumed that when they indicate things to the project manager that he understands what they mean and will take appropriate actions.

The project manager is continually running into situations where he did not understand the implications of certain risks and dependencies.  This has caused a certain amount of rework and delays.

Fortunately, this is not a project with tremendous amounts of risk or dependencies so the project will be late but will succeed.

Mobile Handset Project

In the distant past, I was part of a team that was building a mobile POS terminal that worked over cellular (GSM, CDMA).  The project manager in this situation did not have domain experience and was counting on the subject matter experts.  In this case, the subject matter experts were very good at general design, but not experts in building cellular devices.

Because the subject matter experts were not specialists, they knew most of the key principles of designing mobile handsets but did not understand all the nuances of handset design.  There were several key issues required by practical handset manufacturing that were overlooked by the generalists and ended up creating such a strong cost over-run that the start-up went out of business.

Sumary

In the first project, the subject matter experts were extremely good, however, the project manager failed to understand the implication of some of their statements and this introduced large delays in the project.

In the second project, the subject matter experts were generalists and did not understand all the risks and dependencies of the project.  The project manager (and start-up) were doomed to fail because "you don't know what you don't know". Both these projects show that a project can be delayed or fail because a project manager does not have domain experience.

Conclusion

So if a project does not have many uncertainties and dependencies then it is extremely likely that the project manager does not require domain experience and can rely to some degree on his subject matter experts.

However, if the project has complex uncertainties and/or dependencies then a good project manager without domain experience is likely to find himself in a position where the consequences of not understanding the uncertainties and dependencies will either introduce serious rework or torpedo the project.

---

See also

• Schedule Risk is a Red Herring!!!
• Uncertainty trumps Risk in Software Development

Schedule Risk is a Red Herring!!!

We often hear the term schedule risk, however, it is generally a Red Herring. Stating that the schedule might stretch is about as useful as saying that eating can cause you to gain weight.

You may be correct but it gives you no leverage to solve the problem

Schedules slip as a result of a problem, if you want to solve the problem then you must identify the root cause.  Any problem will result in a task taking longer than expected and potentially affecting the schedule.

Risk and uncertainty are two sides of the same coin. Without uncertainty there is no risk.

No Uncertainty = No Risk

A risk is a contingent liability; a risk is a future event that is uncertain that has consequences. The key words are future and uncertain.

If 6 months remain and the deadline is in 2 months then there is no schedule risk because there is no uncertainty.

6 months late means that the earliest that the critical path items can finish is in 6 months. Just because the project has not hit the deadline and senior staff doesn't understand the project is late does not qualify the team to talk as if the outcome is uncertain.

It is disingenuous and cowardly to suggest to senior staff that a deadline is possible when you know that it is not.

When the team knows that they are late, they often talk about tasks as being risky simply because they hope that miracles can happen¹.

Hope is not a strategy

In fact, Kahneman points out all of us are wired to bet (pray?) on unlikely outcomes when faced with certain losses, i.e. we double down when faced with a loss.  Team members know about the negative consequences of failure and make projects seem possible simply because they want to delay the pain. Even worse, as the situation gets more desperate people will take bigger and bigger risks.

Using the term schedule risk when a project is not feasible essentially robs the managers of making a course correction until the point where very little can be done.

At a minimum, money can be saved by winding the project down. Few people have the intestinal fortitude to speak out when they know that a project is late. Unfortunately, cowardice is very common.

If you take a paycheck then you have an obligation to your organization to tell them when a project is late.

So it makes no sense to talk about schedule risk when:

• The project is late and you know it
• The project is not late but you see schedule items slipping

In the latter case you are much better to talk about why things are slipping rather than using the term schedule risk.  By talking about the root cause of the slippage, especially early in a project, can lead to you either solving the problem or adjusting the project deadline.  Either way, you will have a greater chance of ending up with a feasible project.

Related Articles

• Why Management Declared Deadlines Lead to Disaster
• No Business Case == Project Failure

References

• Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
• Jones, Capers. The Economics of Software Quality. 2011
• Kahneman, Daniel. Thinking, Fast and Slow. 2011

Stupid is as stupid does

Senior management does not set out to have failed projects, yet 7 out of 10 projects fail and you wonder why they keep doing things the same way.

As Forrest Gump's mother stated, "stupid is as stupid does", that is, smart people sometimes do stupid things.  Most senior managers are pretty smart, however, managers end up doing some very stupid things.

Now from a human perspective, something very interesting is going on here.  For example, suppose you were give the following choices:

1. An 80% chance of making $100
2. A guaranteed $50

Choosing the 1st alternative has an expected value of $80, so people might be expected to choose this because $80 is more than $50. However, because humans are risk averse, almost everyone will choose the second alternative with guaranteed money.

Now out of 10 software projects:

• 3 will succeed
• 4 will be challenged
• 3 will outright fail

To put that in perspective, if you were watching people cross the street at an intersection:

• 3 cross the street successfully
• 4 get maimed
• 3 get killed

How interested would you be in crossing that street?

Stupid is as stupid does...

You can Google "software project failure rates" to see that this has been demonstrated reliably over many industries over 50 years.  Challenged projects are over budget and under deliver but senior management manages to sell them as victories.  I do not consider challenged projects to be successful; hence the statement that 7 out of 10 projects fail.

So if human beings are risk averse and the odds of project success are so low then:

Why does senior management ignore risks on software projects?

It seems likely that senior management can't conceive of their projects failing. They must believe that every software project that they initiate will be successful, that other people fail but that they are in the 3 out of 10 that succeed.

This inability to understand the base rate of failure in software development is systemic. There are so many software projects that are started by senior management where the technical team knows that the chance of success is 0% from the start.

Senior management is human (seriously, they are :-) ) and is risk averse, you just need to find a way to remind them of this. One way to get senior management to think twice about projects is to make sure that there is a meeting before launching the project where management is asked the following question:

Assume that this project will fail, why would it have failed? What will the consequences be?

This exercise (if done seriously) may have the effect of causing senior management to realize that the project can indeed fail. With luck, the normal risk aversion that every human being is endowed with will kick in and the project may get re-evaluated.

Stupid is as stupid does...

Related Articles

• Why Management Declared Deadlines Lead to Disaster
• Stop It!  No... really stop it
  • Article about the 5 most common worst practices in software
• Shift Happens
  • Why scope shift is inevitable in software projects

Bibliography

Kahneman, Daniel. Thinking, Fast and Slow.

Kahneman explains why it is human nature to ignore base rates of failure and why we over-estimate our chances of success in any venture.

Uncertainty trumps Risk in Software Development

Successful software development involves understanding uncertainty, and uncertainty only comes from a few sources in a software project.  The uncertainties of a software project increase with the size of the project and the inexperience of the team with the domain and technologies.

The focus on this article is on uncertainty and not on risk.  In part 1 we discussed uncertainty and in part 2 we discussed risk, so it should be clear that:

All risks are uncertain, however, not all uncertainties are risks.

For example, scope creep is not a risk (see Shift Happens) because it is certain to happen in any non-trivial project.  Since risk is uncertain, a risk related to scope creep might be that the scope shifts so much that the project is canceled.  However, this is a useless risk to track because by the time it has triggered it is much too late for anything proactive to be done.

It is important to understand the uncertainties behind any software development and then to extract the relevant risks to monitor.  The key uncertainties of a software project are around:

• requirements
• technology
• resources
• estimating the project deadline

Uncertainty in Requirements
There are several methodologies for capturing requirements:

• Business requirements document (BRD) or software requirement specification (SRS)
• Contract-style requirement lists
• Use cases
• User stories

Regardless of the methodology used, your initial requirements will split up into several categories:

The blue area above represents what the final requirements will be once your project is completed, i.e. the System To Build.  The initial requirements that you capture are in the yellow area called Initial Requirements.

With a perfect requirements process the initial requirements area would be the same as the System To Build area.  When they don't overlap we get the following requirement categories:

1. Superfluous requirements
2. Missing requirements

Superfluous initial requirements tends to happen in very large projects or projects where the initial requirements process is incomplete.  Due to scope shift the Missing requirements category always has something in it (see Shift Happens).  If either of these two categories contains a requirement that affects your core architecture negatively then you will increase your chance of failure by at least one order of magnitude.


For example, a superfluous requirement that causes the architecture to be too flexible will put the developers through a high learning curve and lead to slow development.

If scalability is required of the architecture but it is missing during the initial architecture then you will discover that it is difficult and costly to add later.

The physical equivalent would be the apartment building here on the right.  The foundation was insufficient to the needs of the building and it is slowly collapsing on one side.  Imagine the cost of trying to fix the foundation now that the building is complete.

I've been in start-ups that did not plan for sufficient scalability in the initial architecture; subsequently, the necessary scalability was only added with serious development effort and a large cost in hardware. Believe me, throwing expensive hardware at a software problem late in the life cycle is not fun or a practical solution :-(.

The overlapping box, Inconsistent Requirements, is to categorize known and missing requirements that turn out to be in conflict with other requirements.  This can happen when requirements are gathered from multiple user roles all of whom have a different view of what the system will deliver.

It is much easier and faster to test your requirements and discover inconsistencies before you start developing the code rather than discover the inconsistencies in the middle of development.  When inconsistencies are discovered by developers and QA personnel then your project will descend into fire-fighting (see Root cause of 'Fire-fighting' in Software Projects).

The physical equivalent here is to have a balcony specified to one set of contractors but forget to notify another set that you need a sliding door (see right).  When the construction people stumble on the inconsistency you may have already started planning for one alternative only to discover that rework is necessary to get to the other requirement.

Note, if you consistently develop software releases and projects with less than 90% of your requirements documented before coding starts then you get what you deserve (N.B. I did not say before the project starts :-) ).   One of the biggest reasons that Agile software development stalls or fails is that the requirements in the backlog are not properly documented; if you Google "poor agile backlogs" you will get > 20M hits.

Requirements Risks
Some risks associated with requirements are:

• Risk of a missing requirement that affects the core architecture
• Risk that inconsistent requirements cause the critical path to slip

Uncertainty in Technology
Technical uncertainty comes  from correctly using technology but failing to accomplish the goals as outlined by your requirements; lack of knowledge and/or skills will be handled in the next section (Uncertainty Concerning Resources).  Team resources that don't have experience with technology (poorly documented API, language, IDE, etc) does not constitute a technical risk it is a resource risk (i.e. lack of knowledge).

Technical uncertainty comes from only a few sources:

• Defective APIs
• Inability to develop algorithms

Unforeseen defects in APIs will impact one or more requirements and delay development.  If there is an alternative API with the same characteristics then there may be little or no delay in changing APIs, i.e. there are multiple choices for XML parsing in Java with the same API.

However, much of the time changing to another API will cause delays because the new API will be implemented differently than the defective one. There are no guarantees that the new API will be bug free.

Mature organizations use production APIs, but even then this does not protect you against defects.  The best known example has to be the Pentium bug from Intel discovered in 1994.  Although the bug did not seem to cause any real damage, any time you have an intermittent problem the source might always be a subtle defect in one of the APIs that you are using.

Organizations that use non-production (alpha or beta) APIs for development run an extremely high risk of finding a defect in an API.  This generally only happens in poorly funded start-ups where the technical team might have excessive decisional control in the choice of technologies.

The other source of technical uncertainty is the teams inability to develop algorithms to accomplish the software goals.  These algorithms relate to the limitations of system resources such as CPU, memory, batteries, or bandwidth concern, i.e.:

• Performance
• Memory management
• Power management
• Volume of data concerns

Every technical uncertainty is associated with one or more requirements.  The inability to produce an algorithm to satisfy a requirement may have a work-around with acceptable behavior or might be infeasible.

If the infeasible requirements prevents a core goal from being accomplished then the project will get canceled.  If affected requirements have technical work-arounds then the project will be delayed while the work-around is being developed.

Technical Risks

Some risks associated with technology are:

• Risk that a defective API will cause us to look for another API
• Risk that we will be unable to find a feasible solution for a core project requirement

Uncertainty Concerning Resources
When using the same team to produce the next version of a software product there is little to no resource uncertainty.  Resource uncertainty exists if one of the following are present:

• Any team member is unfamiliar with the technology you are using
• Any member of the team is unfamiliar with the subject domain
• You need to develop new algorithms to handle a technical issue (see previous section)
• Any team member is not committed to the project because they maintain another system
• Turnover robs you of a key individual

Resource uncertainty revolves around knowledge and skills, commonly this includes: 1) language, 2) APIs, 3) interactive development environments (IDEs), and 4) methodology (Agile, RUP, Spiral, etc).  If your team is less knowledgeable than required then you will underestimate some if not all tasks in the project plan.

When team members are unfamiliar with the subject domain then any misunderstandings that they have will cause delays in the project.  In particular, if the domain is new and the requirements are not well documented then you will probably end up with the wrong architecture, even if you have skilled architects.

The degree to which you end up with a bad architecture and a canceled project depends on how unfamiliar you are with the subject domain and technologies being used.  In addition, the size of your project will magnify all resource uncertainties above.

The majority of stand-alone applications are between 1,000 and 10,000 function points.  As you would expect, the amount of the system that any one person can understand drops significantly between 1,000 and 10,000 function points.  The number of canceled projects goes up as our understanding drops because all uncertainties increase and issues fall between the cracks.  N.B. The total % of the system understood by a single person drops precipitously between 1,000 and 10,000 function points.

When there are team members committed to maintaining legacy systems then their productivity will be uncertain.  Unless your legacy system behaves in a completely predictable fashion, those resources will be pulled away to solve problems on an unpredictable basis.  They will not be able to commit to the team and multi-tasking will lower their and the teams productivity (see Multi-tasking Leads to Lower Productivity).

Resource Risks
Some risks associated with resources are:

• The team is unable to build an appropriate architecture foundation for the project
• A key resource leaves the project before the core architecture is complete

Uncertainty in Estimation
When project end dates are estimated formally you will have 3 dates: 1) earliest finish, 2) expected finish, and 3) latest finish.  This makes sense because each task in the project plan can finish in a range of time, i.e. earliest finish to latest finish.  When a project only talks about a single date for the end date, it is almost always the earliest possible finish so there is a 99.9% chance that you will miss it.  Risk in estimation makes the most sense if:

• Formal methods are used to estimate the project
• Senior staff accepts the estimate

There are numerous cost estimating tools that can do a capable job.  Capers Jones lists those methods, but also comments about how many companies don't use formal estimates and those that do don't trust them:

Although cost estimating is difficult there are a number of commercial software cost estimating tools that do a capable job:  COCOMO II, KnowledgePlan, True Price, SEER, SLIM, SoftCost, CostXpert, and Software Risk Master are examples. 

However just because an accurate estimate can be produced using a commercial estimating tool that does not mean that clients or executives will accept it.  In fact from information presented during litigation, about half of the cases did not produce accurate estimates at all and did not use estimating tools.  Manual estimates tend towards optimism or predicting shorter schedules and lower costs than actually occur.    

Somewhat surprisingly, the other half of the case had accurate estimates, but they were rejected and replaced by forced estimates based on business needs rather than team abilities. 

Essentially, senior staff have a tendency to ignore formal estimates and declare the project end date.  When this happens the project is usually doomed to end in disaster (see Why Senior Management Declared Deadlines lead to Disaster).

So estimation is guaranteed to be uncertain.  Let's combine the requirements categories from before with the categories of technical uncertainty to see where our uncertainty is coming from.  Knowing the different categories of requirements uncertainty gives us strategies to minimize or eliminate that uncertainty.

Starting with the Initial Requirements, we can see that there are two categories of uncertainty that can addressed before a project even starts:

1. Superfluous initial requirements
2. Inconsistent requirements

Both of these requirements will waste time if they get into the development process where they will cause a great deal of confusion inside the team.  At best these requirements will cause the team to waste time, at worst these requirements will deceive the team into building the architecture incorrectly.  A quality assurance process on your initial requirements can ensure that both of these categories are empty.

The next categories of uncertainty that can be addressed before the project starts is:

1. Requirements with Technical Risk
2. Requirements Technically Infeasible

Technical uncertainty is usually relatively straight forward to find when a project starts. It will generally involve non-functional requirements such as scalability, availability, extendability, compatibility, portability, maintainability, reliability, etc, etc. Other technical uncertainties will be concerned with:

1. algorithms to deal with limited resources, i.e. memory, CPU, battery power
2. volume of data concerns, i.e. large files or network bandwidth
3. strong security models
4. improving compression algorithms

Any use cases that are called frequently and any reports tie up your major tables are sources of technical uncertainty.  If there will be significant technical uncertainty in your project then you are better off to split these technical uncertainties into a smaller project that the architects will handle before starting the main project.  This way if there are too many technically infeasible issues then at least you can cancel the project.

However, the greatest source of uncertainty comes from the Missing Requirements section.  The larger the number of missing requirements the greater the risk that the project gets canceled.  If we look at the graph we presented above:

You can see that the chance of a project being canceled is highly correlated with the % of scope creep. Companies that routinely start projects with a fraction of the requirements identified are virtually guaranteed to have a canceled project.

Beware of consulting firms that conduct audits of your software projects and  dramatically increase the scope of your projects.  The very action of increasing the scope will increase your chances of failure.  If their ability to increase scope results in them making more money then perhaps they don't have your best interests at heart.

In addition, even if you use formal methods for estimation, your project end date will not take into account the Missing Requirements.  If you have a significant number of missing requirements then your estimates will be way off.

Estimation Risks

The most talked about estimation risk is schedule risk.  Since most companies don't use formal methods, and those that do are often ignored, it makes very little sense to talk of schedule risk.

When people say "schedule risk", they are making a statement that the project will miss the deadline.  But given that improper estimation is used in most projects it is certain that the project will miss its deadline , the only useful question is "by how much?".

Schedule risk can only exist when formal methods are used and there is an earliest finish/latest finish range for the project.  Schedule risk then applies to any task that takes longer than its latest finish and compromises the critical path of the project.  The project manager needs to try to crash current and future tasks to see if he can get the project back on track.  If you don't use formal methods then this paragraph probably makes no sense :-)

Conclusion

The main sources of uncertainty in software development comes from:

• requirements
• technology
• resources
• estimates

Successful software projects look for areas of uncertainty and minimize them before the project starts. Some uncertainties can be qualified as risks and should be managed aggressively by the project manager during the project.

Uncertainty in requirements, technology, and resources will cause delays in your project.  If you are using formal methods than you need to pay attention to delays caused by uncertainties not accounted for in your model.  If you don't use formal methods then every time you hit a delay caused by an uncertainty, then that delay needs to be tacked on to the project end-date (of course, it won't be :-) ).

If your project does not have strong architectural requirements and is not too big (i.e. < 1,000 function points) then you should be able to use Agile software development to set-up a process that grapples with uncertainty in an incremental fashion.  Smaller projects with strong architectural requirements should set up a traditional project to settle the technical uncertainties before launching into Agile development.

Projects that use more traditional methodologies need to add a quality assurance process to their requirements to ensure a level of completeness and consistency before starting development.  One way of doing this is to put requirements gathering into its own project.  Once you capture the requirements, if you establish that you have strong architectural concerns, then you can create a project to build out the technical architecture of the project.  Finally you would do the project itself.  By breaking projects into 2 or 3 stages this gives you the ability to cancel the project before too much effort is sunk into a project with too much uncertainty.

Regardless of your project methodology; being aware of the completeness of your requirements as well as the technical uncertainty of your non-functional requirements will help you reduce the chance of project cancellation by at least one order of magnitude.

It is much more important to understand uncertainty that it is to understand risk in software development.

[Original article here, remember we have moved!]

---

Appendix: Traditional Software Risks
This list of software risks courtesy of Capers Jones.  Risks listed in descending order of importance.

• Risk of missing toxic requirements that should be avoided
• Risk of inadequate progress tracking
• Risk of development tasks interfering with maintenance
• Risk of maintenance tasks interfering with development
• Risk that designs are not kept updated after release
• Risk of unstable user requirements
• Risk that requirements are not kept updated after release
• Risk of clients forcing arbitrary schedules on team
• Risk of omitting formal architecture for large systems
• Risk of inadequate change control
• Risk of executives forcing arbitrary schedules on team
• Risk of not using a project office for large applications
• Risk of missing requirements from legacy applications
• Risk of slow application response times
• Risk of inadequate maintenance tools and workbenches
• Risk of application performance problems
• Risk of poor support by open-source providers
• Risk of reusing code without test cases or related materials
• Risk of excessive feature "bloat"
• Risk of inadequate development tools
• Risk of poor help screens and poor user manuals
• Risk of slow customer support
• Risk of inadequate functionality

Uncertainty and Risk in Software Development (2 of 3)

Defining Risk and its Components

Part 1 of 3 is here.

There are future events whose impact can have a negative outcome or consequence to our project. A future event can only be risky if the event is uncertain. If an event is certain then it is no longer a risk even if the entire team does not perceive the certainty of the event.

Risks always apply to a measurable goal that we are trying to achieve; if there is no goal there can be no risk, i.e. a project can't have schedule risk if it has no deadline.

Once a goal has been impacted by a risk we say that the risk has triggered. The severity of the outcome depends on how far it displaces us from our goal. Once triggered, there should be a mitigation process to reduce the severity of the possible outcomes.



Before looking at software project risks tied to these goals, let's make sure that we all understand the components of risk by going through an example.

Risk Example: Auto Collision

Let's talk about risk using a physical example to make things concrete. The primary goal of driving a car is to get from point A to point B. Some secondary goals are:

• Get to the destination in a reasonable time
• Make sure all passengers arrive in good health.
• Make sure that the car arrives in the same condition it departs in.

There is a risk of collision every time you drive your car:

• The event of a collision is uncertain
• The outcome is the damage cost and possible personal injury
• The severity is proportional to the amount of damage and personal injury sustained if there is an accident
• If there is loss of life then the severity is catastrophic

A collision will affect one or more of the above goals. Risk management with respect to auto collisions involves:

• Reducing the probability of a collision
• Minimizing the effects of a collision

There are actions that can reduce or increase the likelihood of a collision is:

• Things that reduce the chance of collision

• Understanding safe driving techniques  
• Driving when there are fewer drivers on the road
• Using proper turn signals
• Things that increase the chance of collision
• Drinking and driving
• Driving in heavy fog 
• Wearing sunglasses at night

By taking the actions that reduce a collision while avoiding the actions that increase it we can reduce the probability or likelihood of a collision.

Reducing the likelihood of a collision does not change the severity of the event if it occurs. The likelihood of an event and its consequence are independent even if there are actions that will reduce the likelihood and consequences of an event, i.e. driving slowly.

If an auto collision happens then a mitigation strategy would attempt to minimize the effect of the impact. Mitigation strategies with respect to auto collision are:

• Wear a seat belt
• Drive a car with excellent safety features
• Have insurance for collisions
• Have the ability to communicate at all times (i.e. cell phone, etc)  

Having a mitigation strategy will not reduce the chance of a collision, it will only lessen the severity.

Goals of a Software Project

The primary goals of a software project are:

1. Building the correct software system
2. Building the system so that its benefits exceed its costs (i.e. NPV positive)

Building the Correct Software System

What is the correct software system? Cartoons similar to this one are easily found on the Internet:

The correct system is shown in the last frame of the cartoon; so let's define the  correct system as what the customer actually needs. To build the correct system we will need to have correct requirements. 

How Long Will The Project Take?

Let's assume we have complete and consistent requirements for a correct system. How long will it take to build this system?  One approach is to take a competent team and have them build out the system without imposing a deadline.  Once the system is built we would have the actual time to build the system (T_build) .

T_build  is theoretical because unless you are using an Agile methodology you will want to estimate (T_estimate) how long it takes to produce the system before you start.  Nonetheless, given your resources and requirements  T_build does exist and is a finite number; as one of my colleagues used to say, "the software will take the time that it takes".

Most executives want to know how long a project is going to take before the project starts.  To do this we take the requirements and form an estimate (T_estimate) of how long the system will take to build.  The key point to note here is that the actual time to build,  T_build, and the estimated time to build the system, T_estimate , will be different.  The key thing to keep in mind is that T_estimate is only valid to the extent that you use a valid methodology for establishing an estimate.

Building the System so that its Benefits Exceed its Costs 

Building a system so that its benefits exceed its costs is equivalent to saying that the project puts money on the organization's bottom line. We hope that an organization will do the following:

1. Define the system correctly (project scope)
2. Assess the financial viability of the project (capital budgeting)
3. Establish a viable project plan

Financial viability implies that the available resources will be able to produce the desired system before a specific date (T _viable). If T_build < T_viable then the organization will have a financially successful project, if T_build > T_viable then the organization will have a financial failure.

The problem is that we don't know what T_build is unless we build out the software system first, but we don't want to build the project if it is not viable, i.e. T_build > T_viable and that we have a financial failure. We need to have a reasonable expectation that the project is viable BEFORE we build it out. Therefore we use a proxy by estimating the time (T_estimate) it will take to build the software from our project plan.

Once we have a time estimate then we can go forward on the project if T_estimate < T_viable. The estimate, T_estimate, for a project can be done in multiple ways:

1. Formal cost estimation techniques
2. Senior management declared deadlines
3. SWAG  estimates  

Software Project Risks

There are several primary risks for a software project:

• Schedule risk
• Estimation risk
• Requirements risk
• Technical risk

We often confuse schedule risk and estimation risk. Schedule risk is the risk that the tasks on the critical path have been under estimated and the project will miss the end date (i.e. T_build > T_estimate). A project that takes longer than the estimate is not necessarily a failure unless T_build > T_viable.
You can only talk meaningfully about schedule risk in projects where:

• formal estimation techniques are used
• proper task dependency analysis is done
• project critical path is identified

Most of us do not work for organizations that are CMM level 4+ (or equivalent), so you are unlikely to be using formal methods. When the project end date is arbitrary (i.e. method 2 or 3 above) it is not meaningful to talk about schedule risk, especially since history shows that we underestimate how long it will take to build the system, i.e. T_estimate <<<  T_build. When formal methods are not used (i.e. method 2 or 3 above) then the real issue is estimation risk and not schedule risk.

The real tragedy is when an IT departments attempt to meet unrealistic dates set by management when a realistic date would still yield a viable project (below). Unfortunately, unrealistic deadlines will cause developers to take short cuts and usually cripple the architecture. So that when management gives you additional time after their date fails, the damage to the architecture is terminal and you can't achieve the initial objective.

Requirements risk is the risk that we do not have the correct requirements and are unable to get to a subset of the requirements that enables us to build the correct system prior to the project end date. There are many reasons for having incorrect requirements when a project starts:

• The customer can not articulate what he needs
• Requirements are not gathered from all stakeholders for the project
• Requirements are incomplete
• Requirements are inconsistent

Technical risk is the risk that some feature of the correct system can not be implemented due to a technical reason. If a technical issue has no work around and is critical to the correct system then the project will need to be abandoned.

If the technical issue has a work around the:

• If the technical issue prevents the correct system from being built then we have requirements risk
• If the technical work around takes to long it can trigger schedule risk

Next blog:

• Discuss other risks and how they roll up into one of the 4 risks outlined above
• Discuss how risk probability and severity combines to form acceptable or unacceptable risks
• Discuss risk mitigation strategies
• Discuss how to form a risk table/database
• Discuss how to redefine victory for informal projects

The Art of War: How it Applies to Software

Sun Tzu wrote:

War is of vital importance to the state; hence it is a subject of inquiry which can on no account be neglected.

In our modern world, software is of vital importance to your organization.   If you can build software consistently and reliably you will gain a tremendous advantage over your competition.  

If developing software is like waging war then who is the enemy? 

The enemy is complexity.  Complexity comes from having to make dozens of decisions correctly for your software project to even have a chance of succeeding.  For every thing that you know at the outset of the project, there will be at least ten things that you don't know.   Complexity is compounded by making those decisions on a deadline, especially if that deadline is not well chosen.

So when you consider launching a software project you are looking at the tip of the iceberg.  Your ability to handle uncertainty will dictate how successful you will be.

Unlike a conventional war this enemy does not sleep, has no obvious weaknesses, and can not be deceived.  Once you engage the enemy your success will depend on correctly estimating the magnitude of complexity and making excellent decisions.

Sources of Uncertainty

If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.

Attack by Stratagem, p. 18

Uncertainty comes from a few main sources:

• Team resources unfamiliar with the technologies to be used
• Requirements that are incomplete or inconsistent
• Technical requirements that turn out to be infeasible
• Inability to understand project dependencies
• Inability to formulate a correct and understandable plan

Unlike fighting a conventional enemy, complexity will find all your weaknesses.  The only way to defeat complexity is through understanding the requirements, having well trained teams, building a solid project plan, and executing well. 

Unfortunately the way most organizations develop software resembles the Charge of the Light Brigade (poem). 

In that battle about 400 men on horses attacked 20 battalions of infantry supported by 50 artillery pieces. 

Needless to say it was a slaughter.

The Art of War (online)

Several principles outlined by Sun Tzu apply to software development as well:

• Deception
• Leading to advantage
• Energy
• Using Spies
• Strengths and weaknesses
• Winning whole

Deception

Since the enemy is complexity we can not deceive it.  Rather the problem is that we allow ourselves to be deceived by complexity. 

How often do you see developer's say that they can code anything over a weekend over a case of Red Bull? 

People generally do not launch software projects because they want to fail; but when only 3 out of 10 projects succeed, it shows that people have been deceived about the complexity of building software.

This statistic has haunted us for 50 years.

Senior management should really pause and consider if all their ducks are lined up in a row before embarking on a software project.  Unfortunately senior management is still underestimating complexity and sending teams to face virtually impossible projects.

Leading to advantage

Thus it is that in war the victorious strategist seeks battle after the victory has been won, whereas he who is destined to defeat first fights and afterwards looks for victory in the midst of the fight.
                            Tactical Dispositions, p. 15

Complexity emerges from the sources of uncertainty mentioned above.  Successful organizations plan to remove known uncertainties and have a plan to handle the ones that will emerge.  Getting into a project before understanding the magnitude of the uncertainty is a recipe for failure.

Energy

That the impact of your army may be like a grindstone dashed against an egg—this is effected by the science of weak points and strong

Energy, p. 4

The team's energy needs to be directed against uncertainty with appropriate force at the appropriate time.  When this happens uncertainty will be minimized and the chances for success will increase.

It is imperative to create a table of all risks that might affect your software project.  If you aggressively minimize the probability of risks triggering you will reduce uncertainty and increase your chances of success.

Software projects succeed when there is a rhythm to the attack on complexity.  High intensity problem solving needs to be followed by lower intensity stability building.  The team must move at a sustainable pace or risk burning out.  Software teams do not succeed when they are working 10+ hours a day; they become like dull swords -- unable to do anything.

Using Spies

Foreknowledge cannot be elicited from ghosts and spirits; it cannot be inferred from comparison of previous events, or from the calculations of the heavens, but must be obtained from people who have knowledge of the enemy's situation.
                                                                                                    Using Spies, 5 —6

The enemy is complexity and is intangible, i.e. invisible, odorless, and untouchable. Your spies are your business analysts, architects, and project managers.

Your business analysts will work with the business to define the scope of the complexity.  Ask for anything you want, but commit to build all you ask!

Remember that all large complex systems that work are built from small simple systems that work, so aim to build the smallest usable product initially.  Asking for too much and providing insufficient resources and/or time will lead to a failed project.

The architects provide checks and balances on the business analysts to make sure that the project is feasible.

The architects will provide key dependency information to the project managers who make sure that a proper execution plan is created and followed.

Each of these spies sees a different aspect of complexity that is not visible to other people. Unless the reports of three types is combined effectively you risk not knowing the extent of the software that you are trying to build.  If you go into battle without proper intelligence you are back to the scenario of the Charge of the Light Brigade.

Strengths and weaknesses

Military tactics are like unto water; for water in its natural course runs away from high places and hastens downwards.  So in war, the way is to avoid what is strong and to strike at what is weak.
                                     Weak Points and Strong, p. 29—30

Water exhibits ordered flexibility.  It is ordered because it seeks to flow downhill; however, it is flexible and will go around rocks and other obstacles.  A software project needs to make continual progress without getting sandbagged with obstacles.  Methodologies like RUP or Agile software development can make sure that you exhibit ordered flexibility.

Winning whole

Winning whole in a software project means delivering the software on time and on budget without destroying the health and reputations of your team (including management).  Failed projects extend their effects to every member of the team and everyone's resume.

When you engage in actual fighting, if victory is long in coming, then men's weapons will grow dull and their ardor will be damped.
                                                               Waging War, p. 3

When organizations bite off more than they can chew they exert tremendous pressures on the team resources to work extended hours to make deadlines that are often unrealistic.  

In the pressure cooker you can expect key personnel to defect and put you into a worse position.  How many times have you found yourself on a Death March?

Conclusion

Both waging war and software development are serious topics that involve important struggles.  If software development is a war against ignorance, uncertainty, and complexity then many of the strategies and tactics outlined in The Art of War give us direction on how to execute a successful project.