Contact Us

Making Projects Succeed: Part 1 - Measurable Business Goals

This article is written by Dave Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers on agile .NET projects and has extensive experience in agile development techniques, particularly Test-Driven Development. Dave can be emailed at davechaplin@byte-vision.com.

Date: Tuesday, September 9, 2003


It is often stated that the majority of all IT projects have either failed or are running late. In my opinion the largest contributor to failure is due to building the wrong product. The documented system requirements may well be met, but if the end product doesn’t actually add any real business value then the project has failed. Building the wrong thing results from getting the requirements wrong, and getting the requirements wrong means failing to diagnose the business problem and clearly define measurable business goals from which solutions can then be built to solve them problem. This article discusses how to correctly define the unambiguous measurable business goals in order to mitigate the risk of the project failing.


For an IT project to be a success it needs to go through the following steps:

  1. Diagnoses of the business problem
  2. Definition of a set of business solutions to solve the business problem.
  3. Definition of a set of unambiguous measurable business goals designed around the business solutions.
  4. Proposal of a set of system requirements which can meet the set of business goals.
  5. Impact analysis to decide which system requirements will have the optimum combined impact on the set of business goals.
  6. Build the system requirements in small iterative steps.
  7. At each step measure the impact the system has had on the goals.
  8. Adjust the goals and future requirements based on the feedback from the measures.
  9. Continue to iterate the build and measure cycle until the goals are met.
  10. Claim success and reassign resources to other areas.

What is a Business Problem?

A business problem is ultimately a concern with the bottom line, but could be expressed at lower levels as statements like:

  • We are losing business because our competitors are cheaper.
  • Existing customers are leaving because the support we provide is not good enough.
  • Our product is not as good as our competitors.

To solve business problems we need to define business solutions .

What is a business solution?

A business solution is an idea about how to solve a business problem. Examples are:

  • Gain more market share
  • Make our customers more satisfied
  • Reduce the cost of manufacture
  • Increase the speed of processing orders

To achieve the business solutions we need to define business goals. These put more weight to the business solutions and define clear targets in order to solve the business problem.

What is a business goal?

A business goal is an unambiguous definition of a clear target that needs to be reached in order to satisfy a business solution and effectively solve the business problem. Here are some examples:

  • Increase profit by 10% by next quarter.
  • Reduce staff turnover by 15%.
  • Ensure at least 95% of orders are processed in under 2 minutes.

These are business goals because they describe what is meant to change, how it is meant to change, a unit of measure for the change, and a target for change. They often also specify a target date for the goal to be met.

If it cannot be measured and does not have a target then it is not a business goal.

[Note: A business requirement is another name for a business goal. However, it is often the case that business solutions get labelled as business requirements.]

What is a system requirement?

A system requirement describes a piece of functionality the system must provide. The set of system requirements define what will be built in order to meet the business goals. Each system requirement should trace back to one or more business goals.

Can system requirements be vague?

Yes, in the same way that business goals can be vague. More often than not the system goals are not even specified: Here are some examples of terrible system requirements:

  • It must be very user friendly
  • It must be fast
  • It must be easily maintainable
  • It must be very secure
  • It must always be available
These are ambiguous and cannot be measured. They are open to interpretation and pretty much a waste of time even writing down.

Defining system requirements as goals?

It is often the case that the system requirements need to be defined using the same rigorous unambiguous manner as the business goals and also agreed by the stakeholders. For example, the following could be system goals:

  • It should take no longer than 1 hour of formal training before the user can complete all tasks without any guidance from a trainer. The user is assumed to have little knowledge of computer systems except for email and Internet Explorer.
  • It should not take more than 3 minutes to complete a purchase order.
  • The mean time to repair a defect should be no longer than 1 hour.
  • Access should not be possible by anyone other than a specified group of users.
  • The system should be available 98% of the time between 9am and 5pm

These are fairly brief examples. They also need ranges of acceptability and also tests need to be defined as to exactly how they will be measured. I will go into much further detail about defining precise system goals in another article.

Why should goals be unambiguous and measurable?

Goals must be unambiguous so that there is no chance at all of anyone involved in the project of misinterpreting them. They need to be measurable so that any system built to achieve them can be measured for their effectiveness and also to know when they have been reached.

Suppose someone is given the following brief to create a solution from: Brief: “Significantly improve the percentage of purchase orders dispatched within one hour”. They examine the existing process and write a piece of software to print address labels rather than writing them by hand. They think this is good because it saves 5 minutes and also reduces the amount of manual copying errors. The writer of the software thought this was pretty significant.

Did this solve the ‘business requirement’? Well, the answer is no, because it reduced the current turn around time by 5 minutes and made only a 1% decrease in the percentage of orders dispatched within an hour. Also, it added the additional cost of a printer to print the labels and also meant that staff needed to be trained up to use the machine to print the labels. Also, there was no requirement to reduce the amount of manual copying errors, since another department already had checks in place to mitigate those. Also, when the project stakeholder said ‘significant’ they meant a 100% improvement on existing levels. This was later found to be confusing when another one of the stakeholders said they thought significant meant better than all their competitors.

Now let us look at a business goal being properly defined:

Description of goal: To dispatch 80% of all purchase orders within 1 hour. The time measured is the time from receiving the request for purchase from the client to the time the order is dispatched. This needs to be achieved within the next 3 months.

Unit of measure: Percentage of orders dispatched within one hour.
Current percentage: 45% [as measured]
Target percentage: 80%
Worst Acceptable: 75% [If we cannot reach 80%, then the worst acceptable level is 75%]
Best possible: 95% (competitors ABC Ltd achieve this)
Test: Monitor all purchase orders over a 2 week period and measure the percentage of orders dispatched within the target time.

This clearly defined measurable business goal enables the system designers to objectively evaluate which of their ideas will be most effective. Once a system requirement is implemented the test can be conducted to determine if the implementation has met the target. If it has then success can be claimed and resources can be re assigned to other areas of the business, or onto other goals. If not, then other implementation will need to be considered. This is what iterative development is all about which will be discussed later. There will be other goals which will also need to be satisfied, some of which could be negatively effected by system requirements designed to meet other goals. The whole set of business goals needs to be evaluated against the whole set of possible system requirements. This will help to determine which set of system requirements will have the best overall effect.

Unless the goals are unambiguous and measurable they will be misinterpreted by both stakeholders and system designers which runs the risk that the real business need will not be met. They need to be measurable so they can be tested and evaluated to see if success can be claimed.

What is NOT a business goal?

Here are some items which are not business goals:
  • Reduce headcount
  • Automate the purchasing process
  • Provide better support for our customers
  • Provide a button to view an order

These are not business goals. This can be deduced by asking the following questions:
  • If I sack all the staff and reduce the headcount 100% have I met your requirements?
  • If I automate the purchasing process which then costs 10 times as much to run as it currently does, have I met your business requirements?
  • How will you measure ‘better support’ and at what point can we say we have made support better?
  • How will providing a button to view an order help the business?

The statements are actually business solutions to increasing profit, becoming more efficient, and maintaining and expanding the customer base, which are good high level business solutions .

What happens if goals are missed out?

If the goals are missed out then the system designers are left, at best, with the business solutions to work from. From those, they then have to interpret for themselves what the real goals could be. This then wastes time whilst project managers, system designers, business analysts and developers discuss heatedly about what to build since each has their own interpretation about what the goals could be. Some people on the project interpret the goals the same and this combined voice can result in those ideas being adopted. Sometimes, perhaps a highly paid consultant speaks with so much rhetoric that their solutions can adopted. Often, to resolve the discussions and get back to building something, the project manager will dictate what should be built based on their interpretation. Whilst all this is happening the stakeholder could have a completely different set of goals and thus expectation of what the solution being built will eventually achieve for them. When the product is released to the stakeholder the real goals become apparent, finger pointing and apportioning for blame starts.

Here are some typical symptoms of projects with no clear goals:
  • There are no clearly defined set of measurable goal or targets.
  • There is no objective way of measuring the impact of one suggested solution over another.
  • The project is currently or will run late.
  • The stakeholders are frustrated that you are not meeting their requirements and are losing interest.
  • The final product will meet a fraction, if any, of the originally ended purpose (although that will be hard to measure!)
  • The best developers leave the project.
  • Morale is generally bad for everyone involved in the project.
  • The project manager requests overtime and weekend working.
  • There is a sudden panic towards the end to fix the system up quickly.
  • There is no clear understanding of how useful the current build is going to be.

If this sounds like your project then perhaps you also have no clearly defined goals.

Leaving business requirements vague and immeasurable results in too much misinterpretation and guesswork which results in very amateur ‘trial and error’ type development projects that cost far too much than they should.

Imagine playing archery with ten targets in a field with no idea what hitting each target scored or how many points you needed to score to become the winner. The only way of knowing if you had won would be to try something out and then ask the umpire. You could go for weeks before finding out that you were really in a triathlon and that you could have scored much more points if you had not wasted so much time and instead moved onto the skiing event. By this time of course your competitors would have passed the finish line long ago.

How can the Business Goals be established?

To establish the business goals discussions need to be had with the project stakeholders starting with the very simple but single most important question on a project: ‘What are your goals for this project?’

If you are lucky your stakeholder will state exactly what they are, how they will be measured and when they need to be achieved by. If you ever come across this situation then please call me and I will eat my own hat!

More probably the stakeholder will either state system requirements that they want you to implement, having diagnosed the problem themselves, or give you a high level business solution that cannot be measured. For example:

  • System requirement stated: “I want to be able to count the number of words in a document quickly”
  • Business solution stated: “I need to increase revenue”

Both statements are useful and not to be dismissed. If a system requirement is stated we can ask the question ‘Why?’ in order to get to business solutions. Once we arrive at business solutions we can ask ‘How?’ to get at quantifiable measures to define the goals.

It is the role of the business analyst to establish the business problem, the business solutions, and define the business goals. It is the role of the project manager to co-ordinate the entire team of business analysts, system designers, developers, testers, and stakeholders to ensure the business goals are met. It is the role of the system designers and developers to build solutions that will meet the business goals. It is the role of the testers to test that the solutions created meet the business goals.

Here’s an example of a conversation with an analyst and a client that results in a set of unambiguous measurable business goals being established. For example:

Analyst: Why do you need to count the words?
Client: Because I charge my clients per word?
Analyst: how do you charge them after counting the words?
Client: I send them an invoice. Analyst: Why do you need to count the words quickly?
Client: Because the manual process takes up time when I could be writing more articles.
Analyst: Why do you want to write more articles?
Client: To make more money?
Analyst: How much more money do you want to make?
Client: I would like to double my current revenues.
Analyst: How long does it currently take to invoice a client?
Client: 20 minutes.
Analyst: How long would you like it to take?
Client: 1 minute would be great.
Analyst: How many invoices do you create each week?
Client: 25.
Analyst: How long does it take to write an article?
Client: 1 hour.
Analyst: Where else do you feel you waste time?

And so on….

The business problem is that the client wants to increase the revenue of the company. The business goal is that they want to double the company revenue. One business solution is to write more articles or perhaps double them. In order to double the number of articles extra time needs to be created by reducing the time spent on other activities, one of which has been identified as the invoicing process.

Because of that discussion we can then go on to examine how we could perhaps meet the goal of doubling revenue. The client has assumed they must free up more time for writing articles and defined the solution themselves by asking for something to count the words quickly on a page. Perhaps another solution might be to simply double their prices!! Another might be to provide them with better tools for authoring the articles. The important point to note is that when we start from a clear business goal we can then consider many ways of achieving that goal. Remember, the system designers and developers are best place to design a system to meet the goals, and the stakeholders are best placed to understand their business goals.

Golden rule: Don’t let your stakeholders define the system requirements

Golden rule: Don’t let anyone other than the stakeholders agree with goals for the project

How does iterative development help?

Iterative development is when you build a small part of the overall system, release it to a pilot set of users and then obtain feedback. You then adjust the activities of the project based on that feedback.

In engineering rockets use a similar process of a feedback loop to guide them to their chosen destination. Rockets take measures at frequent intervals and feed those measurements back into their computers to adjust the direction they are travelling. It is the same with iterative development.

Iterative development can take longer than waterfall development, because the code base needs to re engineered at each step based on the changes in direction defined. However, the chances of hitting the target are increased.

How can iterative development fail?

In order to make the adjustments you must be able measure how far away from the target you are at the end of each iteration. If you do not know how to measure where you are, and you do not know what the target is then it will not be possible to adjust the plan. In practice on iterative projects with no clear goals changes do get made but they tend to be vague hand waving type suggestions with no real basis for their justification.

Iterative development without clear goals and measures is a waste of resources. You would be better off using the waterfall method and producing the same ineffective result quicker.

Who should agree the goals and when?

Once a draft set of business goals has been established it is of paramount importance to agree the goals and measures with the stakeholders and order the priority of the goals. Be extremely careful at this stage not to allow the business analyst and/or project manager to agree the goals without consulting the stakeholder. To do so negates the whole point of setting the goals in the first place. If they are not agreed by the stakeholder then the whole problem if misinterpretation rears its ugly head again.

Once the goals have been initially set and prioritised use the end of the first iteration to take a set of measurements to establish how far the goals have been met. Meeting with the stakeholders and report the results. You will need the list of goals, how far targets have been met, how much has been spent, and how much will need to be spent to reach each target not yet fulfilled. The stakeholder can then realign priorities. It may well be that some goals have not hit initial targets but they are close enough at this stage and the stakeholder would prefer to focus on some of the other goals.

Golden rule: Agree all goals with the stakeholder and only allow them to prioritise the goals.


To ensure project success ensure you have a set of unambiguous measurable business goals which are agreed and prioritised with the stakeholders. At each iteration measure the distance from the goals and report progress, then allow the stakeholder to re prioritise accordingly.

Good luck

Dave Chaplin

Other Articles

Test Driven Development (Dec 2003)
The Losers Olympics (Sep 2003)
Making Projects Succeed: Part 1 - Measurable Business Goals (Sep 2003)
Pitfalls In Software Development (June 2003)
Extreme Web Architectures - Testing Web Applications In Seconds (June 2003)
Pair Programming and Quad Programming - From Experience (June 2003)
Making Extreme Programming A Success (April 2003)
Contractual Test Driven Development (TDD with DBC) (April 2003)
Moving To XP (Feb 2003)
Maximising Development Productivity (Dec 2002)
Writing Automated Browser Tests Using NUnit and IE (Oct 2002)
Mitigating Requirements Risk With Agile Practices (Oct 2002)
10 Tips for Successful Team Leading (Oct 2002)
Developing Automated Using Tests Using NUnit 2.0 With VB.NET (Sep 2002)
Quality By Design - Part 1.doc (May 2001)
Quality By Design - Part 2.doc (May 2001)
Quality By Design - Part 3.doc (May 2001)

Other Resources


Extreme Programming


Agile Modelling

All content © Byte-Vision Limited 1997 - 2004