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 09, 2003
Abstract
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.
Summary
For an IT project to be a success it needs to go through the following steps:
-
Diagnoses of the business problem
-
Definition of a set of business solutions
to solve the business problem.
-
Definition of a set of unambiguous measurable business goals
designed around the business solutions.
-
Proposal of a set of system requirements
which can meet the set of business goals.
-
Impact analysis to decide which system requirements will have the optimum
combined impact on the set of business goals.
-
Build the system requirements in small iterative steps.
-
At each step measure the impact the system has had on the goals.
-
Adjust the goals and future requirements based on the feedback from the
measures.
-
Continue to iterate the build and measure cycle until the goals are met.
-
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.
Comments
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
NUnit
http://www.nunit.org/
http://sourceforge.net/projects/nunit/
Extreme Programming
http://www.extremeprogramming.org/rules/testfirst.html
http://www.extremeprogramming.org/index.html
Refactoring
http://www.refactoring.com
Agile Modelling
http://www.agilemodeling.com/
|
