The role of the Business Sponsor of a technology project is to ensure it successfully delivers. These slides suggest some areas to ask questions about if you are Business Sponsor of a project being delivered using Agile methodology

1. Successful Business Sponsorship
of Agile IT projects.
Chris Mundy
Managing Director, Clearcast
https://uk.linkedin.com/in/mundychris
ChrisMundyLdn

2. Too many IT projects end in Failure.
As Business Sponsor of an Agile project you
need to ensure this doesn’t happen to you.
These slides contain questions to help you
keep on track.

3. What is Agile development?
• An alternative to traditional project management intended to
help teams respond to unpredictability through incremental,
iterative work periods, known as sprints (eg 2 weeks).
• Agile methodologies are an alternative to waterfall, or
traditional sequential development.
• A project is broken down into “Epics” which are large chunks
of work and further down into “User Stories” which are short
descriptions of functionality that is required.
• How the User Stories for a sprint will be delivered are worked
through at the start of each sprint

4. Characteristics of Agile
1. Active user involvement
2. Team empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Requirements captured at high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test
early and often
10. Collaborative & cooperative approach between all
stakeholders is essential
Source: http://www.allaboutagile.com/what-is-agile-10-key-principles/#sthash.9KyO8gG9.dpuf

5. Five business risks of Agile
Risk Consequences
Unclear user needs Wasted effort: building code, tearing
it down and rebuilding it. Extra costs.Inefficient planning
Focusing on the immediate detail,
losing sight of the big picture Project derails / runs out of road
Scope creep
Project goes over budget, is delivered
late or cancelled
The project comes under pressure as
a result of the above and
collaboration between buyer and
vendor strains
Impossible to work in an agile fashion
without collaboration. Inadequate
product is delivered.

6. Questions the Business Sponsor
Should Ask.

7. “Why are we doing this Agile?”
• Agile may be the best approach for your project, or it may
increase the risks of successful delivery.
• Agile is great for projects :
• That can be delivered in stages, maybe generating early
revenues
• Where you want to get something up quickly then improve on
it
• Where you want to encourage users to help shape it
• Flexibility is important
• Be confident you won’t risk overruns or extra costs going down
the agile route

8. “How detailed and/or definitive is our spec?
Is the supplier as clear as us?”
• Have both the Business and Technology signed off the spec.?
• Don’t rely on one to be expert on the other’s area.
• Realistic pricing will depend on good understanding.
• What is clear and specific to you may not be to your supplier
• If areas of a technical spec are open to interpretation then they aren’t
specific. This may be fine, as long as you both have same understanding
• Supplier may feel (and have contracted) on the basis that a simpler
solution than you expect will suffice.
• Test: where would you stand legally in event of disagreement?
• Also… if the specification is very definitive then agile may not
be the best approach.
• Better suited where there is the opportunity to co-invent the best
solution

9. “Does the supplier have a deep
understanding of our needs?”
• Demonstrated by workflow diagrams, wireframes, proof of
concepts.
• Worth investing in proving before full commitment
• Good project planning at the outset will avoid the need to
rework later.
• Agile means flexibility to iterate but nothing (e.g. database structure)
should be locked down without planning complete
• Do everything possible to surface any mismatch between
supplier expectations and yours up front

10. “Are our internal roles sufficiently clear?
Who has sign-off for what?”
• There will usually be at least a Business Lead, a Technical lead
and a Project Manager.
• Is there clarity of roles?
• Who is ultimately responsible for ensuring the system meets business
needs?
• Who chairs user group meetings?
• Is there a clear, documented, internal sign-off process for all decisions
• Any uncertainty in roles and responsibilities adds risk

11. “Are we on track? How do we know”
• This is a hard one for agile because it’s
not delivered using a fixed road map.
• Especially important for fixed cost
projects.
• Are all the Epics* mapped out at a
high level? Has resource allocation
been allocated to each one.
• Is progress being mapped against the
original plan?
• Are realistic revisions being made as
the project progresses to ensure it still
delivers?
Epic 1
20%
Epic 2
15%
Epic 3
10%
Epic 4
10%
Epic 5
20%
Epic 6
25%
Project
*Epics are larger items of feature-level work that encompass many user stories. For example, an epic might include all
aspects of a user being able to manage their account.
% is of total project development resource

12. “What is the process for signing off user
stories and acceptance criteria?”
• User stories* are the building blocks of the
system.
• Each user story should have acceptance criteria so
everyone knows what is expected. These should
be signed off before work on that user story
begins
• If what is delivered is not as expected, either the
acceptance criteria were inadequate, or they were not
delivered.
• To minimise the chance of tearing down and
rebuilding, capture all stories in an Epic with
acceptance criteria, before dev starts on that Epic.
*An user story is a very high-level definition of a single requirement, eg “as a user I need to see a spinner while waiting
for the screen to refresh”
Epic
Story
1
Story
2
Story
3
Story
4

13. “Are project management tools being used
effectively?”
• Every agile project will utilise a project management tool, eg
JIRA or Pivotal Tracker
• In a good working relationship, the client will have access to
the tracking tool
• Helps the client prioritise, check acceptance criteria, understand where
problems may have arisen and monitor progress
• Ideally “points” [reflecting development burden] will have
been allocated to each Epic so you can track how accurately
the work involved was forecast and if you may over-run.
• If user stories are not grouped by Epic, consider carefully how
you can track delivery of the Epic, or be sure that stories being
developed will lead to its successful delivery.
• Access to the tracking tool also gives an insight into how
comprehensively and/or far out the project has been planned

14. “Are we following the process for variation
laid out in the contract?”
• With agile development it’s more likely that something will be
delivered by mutual agreement that departs from what was
originally envisaged, or mandated, in the contract
• i.e. you may agree to depart significantly from the contractual
specification in certain areas.
• Make sure that change management processes outlined in the
contract are followed. If the contract isn’t written yet then
think very carefully how change can best be managed
contractually
• At the very least, every significant variation should be
documented and mutually agreed in writing.
• Avoids each party blaming the other if things go wrong.

15. “How are we protected if the relationship
sours”
• Agile is probably more at risk than waterfall of experiencing
project difficulties as the project will be less defined up front
• There may be scope creep or other pressures on the relationship
• Does your contract mandate a way of working? Can one party
try and unilaterally change this?
• Agile is unlikely to deliver a successful outcome if both parties are not
fully engaged throughout the project. The client doesn’t need to be
embedded in the team, but does need to sign off user stories and
acceptance criteria up front, not just functionality as it is delivered.
• If you are still drafting the contract, think about how you want
to work up front and provide a mechanism for changing that
by mutual agreement should it be necessary

16. Don’t lose sight of the end game.
Review
Iterate
Plan
Reprioritise