Leading Successful Programmes (LSP) v2.8

Programme Leadership Course
Version 2.7
February 2009
Leading Successful Programmes

2
Copyright © Maddison Ward 2006
Course Objectives
 What you will learn from this course
 What a programme is, and how to lead it
 What levers you can use to drive a programme to a successful outcome
 How to maintain a high-performing delivery organisation
 How to manage the client
 What processes you need to have in place to monitor and control a programme
 What you will not learn
 Anything about methodologies, such as Prince, Agile, RUP etc.
 What documents you need to produce when
 How to use Microsoft Project

Copyright Maddison Ward 2006
What is a Project or Programme?
The bus of success carries many passengers, but the bicycle of failure is ridden alone
--Stuart Robb 2001
The bus of success carries many passengers, but the bicycle of failure is ridden alone
--Stuart Robb 2001

4
 What is a programme
 What are the characteristics of a project?
 How does this differ from a programme?
 Does “size” matter?
 What is the difference between a “project” and a “workstream” or
a”workpackage”?
 What makes a project or programme “successful”?

5
Management vs Leadership
 What is the difference between a good “manager” and a good “leader”?
 Describe the characteristics of each
 Why is leadership vital in project or programme management but not in day-
to-day business as usual activities?
Consider about the following statement.
Managers manage tasks?
Leaders manage people?

6
 A definition of a project
 Work undertaken by people in a managed way to produce a pre-determined
desired outcome.
 Product of many tasks done by one or more people
 A definition of a programme
 Work undertaken by people in a managed way to produce a pre-determined
desired outcome.
 Product of many interrelated projects, workstreams/workpackages
 What do we mean by managed?

7
What do we mean by managed?
 We know & CONTROL the following:-
 What the pre-determined desired outcome is SCOPE / REQUIREMENTS
 Who is delivering it RESOURCES
 By when PLAN / GANTT
 How much it will cost COST - CAPEX / OPEX
 How much it will make BUSINESS CASE / ROI
 Who is the customer for it STAKEHOLDERS / END CUSTOMER
 Risks & current issues with its delivery RAID
 The communications to all those involved All those impacted
 The QUALITY of the outcome QUALITY CRITERIA

8
What if we don’t directly “control”?
 Examples of parts of a project where we do not directly control, include
 Resources, who are owned/controlled by a line manager (matrix management)
 Budget, which is controlled by a finance department
 Scope, which is controlled by the business owner for the project
 Etc…
 How then, can we manage our project, where we do not control all
aspects of it?
LEADERSHIP

9
What is LEADERSHIP?
 Leadership is:-
 The ability to influence and organise a group of people to achieve a common
purpose or goal (without necessarily having direct control over them)
 and within the context of project/programme management, to a
 A pre-determined (certain) outcome (scope),
 by a certain time
 within a certain budget
 and to a certain quality (how do you measure this objectively, not subjectively?)
 What makes a project or programme “successful”?
 Certainty
 Projects don’t get delivered by processes
 Projects don’t get delivered by technology
 Projects get delivered, implemented and accepted by….. PEOPLE!

10
What makes a programme successful?
PROCESS
PEOPLE
TECHNOLOGY
Collateral
Knowledge
Procedures
Forums
Terms of Reference
Directory Structures
Project Folders
Signoffs/Acceptances
Culture
Behaviours
Leadership
Training
Incentives/Reward
Peer Reviews
Monitoring
Environment
Milestone Management
Risk/Issue Management
Portfolio Management
Financial Management
Resource Management
Knowledge Management
Configuration Management
Microsoft Project
RAID Logs (Excel/MS Access)
Timesheeting (Clarity) GOOD PROCESSES
are no substitute for
GREAT LEADERSHIP

11
Influence & Organise
 How do you influence?
 Shout
 Command
 Direct
 Persuade
 Cajole
 Bully
 Communicate
 Ask politely
 Friendly request
 How do you organise?
 Hierarchical command & control
 Flat structures, delegated accountability
 Random/chaos
 Processes
 Plan
What are the benefits/drawbacks of each of these approaches?

12
Origins of Leadership
 Origins of leadership - why do we have leaders at all?
 Psychology of leadership
 Group behaviour in higher mammals (ie, us)
 Alpha Male
 Physical strength vs intellectual strength
 2001 – A Space Odyssey
 Ape “takes the lead” using a bone as a weapon
 Others “follow” the leader
 Example of “intellectual leadership”
Take the lead – it wasn’t given!

13
Origins of Leadership
 Emergence of leadership (& followership) in evolution (studies of animals)
 Need to co-ordinate as a group, where individuals are better off acting and moving together with
others.
 Leader–follower patterns emerge not only during coordinated group movements, but also during
other group activities, such as hunting, deterring predators, teaching, internal peace-keeping and
dealing with other groups.
 Across species, individuals are more likely to emerge as leaders if they have a particular
physiological, or behavioural trait increasing their propensity to act first in coordination problems.
 Motivation: Individuals most in need of a particular resource are more likely to be the leader.
Leadership in humans correlates strongly with both ambition and autonomy traits
 Temprement: Bold animals often emerge as leaders and shy animals emerge as followers. These
differences are enhanced by social feedback in that bold leaders inspired faithful followership, and shy
followers facilitated effective leadership. In humans, boldness has a substantial heritable component.
Furthermore, experiments show that the most talkative member of a group often becomes the group's
leader, more or less regardless of the quality of their inputs — this is referred to as the ‘babble effect’.
 Dominance: In many cases dominant individuals lead not because they enforce followership. Instead,
dominants operate more autonomously (given their superior body size, or access to resources) and are
in a better position to elicit followership since they hold a particularly strong influence over the
behaviours of group-mates and have an established importance within social networks
 Knowledge: Finally, having some unique knowledge or expertise increases the likelihood of an
individual emerging as leader and attracting an enthusiastic following. Humans are extremely good at
estimating the expertise of other individuals even in newly formed groups and knowledgeable
individuals often emerge as group leaders

14
Origins of Leadership in humans
There have been at least five major transitions in the evolution of
human leadership:
 1: leadership emerged in pre-human species as a mechanism to solve simple group coordination
problems where any individual initiated an action and others followed
 2: leadership was co-opted to foster collective action in situations involving significant conflicts of
interest such as internal peacekeeping in which dominant or socially important individuals
emerged as leaders
 3: dominance was attenuated in early human egalitarian societies which paved the way for
democratic and prestige-based leadership facilitating group coordination
 4: the increase in human group size selected for powerful social-cognitive mechanisms, such as
theory of mind and language, providing new opportunities for leaders to attract followers through
manipulation and persuasion
 5: the increase in social complexity of societies that took place after the agricultural revolution
produced the need for more powerful and formal leaders to manage complex intra- and
intergroup relations — the chiefs, kings, presidents, and CEOs — who at best provide important
public services and at worst abuse their position of power to dominate and exploit followers
In summary, human leaders not only initiate group action but also motivate, plan,
organise, direct, monitor, and punish to achieve group action. They may lead
democratically or despotically, from the front or from the back, and lead small or very
large groups.
Source: The Origins and Evolution of Leadership Andrew J. King, Dominic D.P.
Johnson and Mark Van Vugt

15
Attributes of leadership
 Upbringing
 Uprising / Events
 Vision (Outcome)
 Motivation (Passion)
 Mobilisation (Team-building)
 Tenaciousness
 Decisiveness *
 CHARISMA
 * Timothy D. Wilson’s book Strangers To Ourselves provides compelling evidence for an adaptive unconscious, a
part of us that evolved to make decisions for us. Wilson talks about letting the adaptive unconscious make
decisions for us. The point is that we should not analyze the information in an overly deliberate, conscious manner,
constantly making explicit lists of pluses and minuses. We should let our adaptive unconscious do the job of
forming reliable feelings and then trust those feelings, even if we cannot explain them entirely. His experiments
demonstrated that the longer the time we spend making decisions, the less happy we are about the decision we
end up making.

16
Examples of great leaders
 Alexander the Great
 Boudica, Queen of the Iceni
 Napoleon Bonaparte
 Admiral Lord Nelson
 Lawrence of Arabia
 Mohandas Ghandi
 Adolf Hitler
 Winston Churchill
 John F Kennedy
 Margaret Thatcher
CONSIDER:
Many of these leaders are only
recognisable as being “great” for
a relatively short period or during
some key event! Often, their
“greatness” went catastrophically
awry having reached their
pinnacle.
What leadership attributes did each of these “leaders” demonstrate?
After a great height, comes a great fall!

17
Exercise: Consider these leaders
 TEAM 1: Consider the following “war leaders” – “Admiral Lord Nelson &
Churchill”
 What qualities did they exhibit as a great leaders?
 TEAM 2: Consider the following “civil rights leaders” – “Ghandi, Nelson
Mandela, Malcolm X”
 What qualities do each of these leaders exhibit
 How does their style differ from the previous example (Churchill & Nelson)
 Each had their own success. What attributes did they exhibit that made them
identifiable as great leaders?
 TEAM 3: Consider the following “business leaders” – “Richard Branson, Alan
Sugar, Gordon Ramsay”
 What qualities do each of these leaders exhibit
 How does their style differ from the previous examples
 Each had their own success. What attributes did they exhibit that made them
identifiable as great business leaders?
 What do you perceive their failings as?

18
Empathy
Gravitas
What makes up leadership attributes?
Charisma
POWER
Respect
Openness
Approachability
Enthusiasm
Empathy
Body language
Reward
Coersion
Referent
Legitimate
Expert
Lead by example
Influence positively
Be Inclusive
Be factual / knowledgable
Be human
Be honest
Body Language
AUTHORITY
In what proportion do these need to be to make a great leader?
How would you rate yourself?
Virtue
Dignity
Integrity
Solemnity
Seriousness
Substance
Purpose
Vision
Drive
Motivation
Relentlessness
Decisiveness

19
Power
 What is power? Why is it important?
 How do you get power? Are you “given power” (authority)?
 What is the relationship between Power and Respect? ?
 What happens when you try to exercise Power without Respect
 What happens when you try to take power and face resistance (Revenge Cycles)
 Can you have power, but still have friends on the programme (what level of “detachment” do you
need?)
 When should you use the three types of power?
 Power over (taken) - despotic
 Power under (given) - democratic
 Power sharing (consensus)
 Where does Charisma fit?
 Can you deliver a programme without Power?

20
What kinds of power can I exercise?
Power styles are created by the followers belief over the power a leader holds and
allows the leader to exert influence. If the followers do not hold the requisite belief
then the leader is not able to influence them.
 Reward power needs follower to believe leader will reward them. This type of power needs to
be used carefully to prevent followers becoming accustomed to rewards and refusing to complete routine tasks without a reward.
Generally rewards should not be offered, to follower employees to complete duties which are a normal part of their role. They
need to be proportionate to the value and effort expended.
 Coercive power needs follower to believe leader will punish them. Coercive powers should be
used carefully; overuse can lead to unhappy employee followers. Unhappy followers can be negative or unmotivated, they may
resign or adopt a “work to rule” attitude. These also need to comply with the appropriate laws and HR policies and should be
used VERY sparingly.
 Legitimate power needs follower to believe leader has right to instruct them. This
power is created by the leader’s job title (such as captain, doctor, or area manager), combined with the
follower’s belief that the job title gives the leader the right to give them orders.
 Referent power need follower to believe leader has desirable qualities. This is created when
the followers believe that the leader possess qualities that they admire and would like to possess. The followers identify with their
leader and attempt to mimic or copy their leader.
 Expert power need follower to believe leader is an expert, ie, the leader has “expert” knowledge or
skills that are relevant to the job or tasks they have to complete. Often an experienced member of the team or staff in an
organisation, can have expert power even though they are not a supervisor or manager.

21
Charisma
 What is charisma? Why is it important?
 How do you get charisma? Are you “born with it”?
 What is the relationship between charisma, respect and power? ?
 What happens when you try to exercise Power without Charisma
 Can you deliver a programme without Charisma?
 The three attributes of charismatic people
 they feel emotions themselves quite strongly;
 they induce them in others;
 they are impervious to the influences of other charismatic people.
Is charisma the same as empathy?
Is empathy important in leadership too?

22
Can Charisma be learned?
 General: Open body posture, hands away from face when talking,
stand up straight, relax, hands apart with palms forwards or
upwards
 To an individual: Let people know they matter and you enjoy being
around them, develop a genuine smile, nod when they talk, briefly
touch them on the upper arm, and maintain eye contact
 To a group: Be comfortable as leader, move around to appear
enthusiastic, lean slightly forward and look at all parts of the group
 Message: Move beyond status quo and make a difference, be
controversial, new, simple to understand, counter-intuitive
 Speech: Be clear, fluent, forceful and articulate, evoke imagery, use
an upbeat tempo, occasionally slow for tension or emphasis

23
Respect
 What is respect? Why is it important?
 How do you get respect? Are you “born with it”?
 What is the relationship between charisma, respect and power? ?
 What happens when you try to exercise Power without Respect
 Can you deliver a programme without Respect?
 The attributes of commanding respect
 Respect is ‘earned’. If your followers feel you are worthy of respect as a result
of your actions and your words, they will respect you.
 Therefore, you can never DEMAND respect, it has to be given.
 Respect is a result of admiration from peers and sub-ordinates. Links to mimickry
in the evolution of leadership (I would like to be like that person, therefore I
respect them).

24
How can you command respect?
 Lead by example: If you say one thing, and do another, you won’t gain respect. Avoid
the label ‘all talk, no action’. If you mean it, do it! “Eat what they eat”… If you’re
asking people to work like slaves, stay until 3am to solve problems, you are there with
them until the fat lady sings. If not, you’ll not be leading from the front!
 Influence positively: Avoid explicitly manipulating people, which leads to revenge
cycles. Create commonality of purpose with others to encourage willingness by them
towards delivering the same goals. You cannot influence people without them buying-in
to your desired outcome. Be tenacious (avoid giving up mentality) and decisive.
 Be inclusive: Avoid ‘I think’, ‘I feel’ and become a ‘we’ person. If people think you’re
puffing up your own ego by virtue of your position, they’ll find ways to undermine you.
Be particularly praiseworthy of others when they have succeeded in a task which helps
you towards your goals - praise THEM to their peers, not YOU!
 Be factual and knowledgeable: Use clear facts to support your opinions. Avoid trying to
look knowledgeable when you don’t know - it’s ok not to know something and seek
advice and information from others.
 Be human: Approachability is vital to gaining respect. If others fear your reaction to bad
news, they will avoid giving it to you and you will lose their respect.
 Be honest: Lies quickly get found out. So does posturing, pretending to know
something when you don’t, pretending something is green when it’s red, finished when
it isn’t. Any of these fatally undermines your integrity and therefore your respect.
 Have the right body language: Open posture, sitting or leaning slightly forward,
attentive listening skills (2 ears, 1 mouth), speaking only when you have something
insightful and relevant to say, avoiding excitable gestures/arm waving, calmness and
serenity all give power to commanding respect

25
Interrelationship of Power, Charisma, Respect, Purpose &
Gravitas
 A School Teacher is given power, but what about respect, gravitas, purpose, empathy
& chrisma?
 Would ALL teachers be universally described as having great leadership qualities?
 A teacher who maintains control in the classroom often has respect and is
acknowledged by the pupils as the leader.
 A teacher who has to battle with a disruptive class where there is usually a
ringleader often hasn’t gained the acceptance of the pupils as the leader. - who is
the leader in this example?
 What if a teacher had charisma and respect, but is given no power?
 In giving this tutorial, I have no ‘given power’. Therefore, what legitimises my being leader?
 Is a charismatic teacher better than a teacher who maintains control through
bullying and mass detentions of the class? Does that teacher display
empathy?
 Does a great teacher have a purpose?
Therefore, are the best teachers also exhibiting all the qualities of great
leaders?
= AUTHORITY

26
Types of Leadership
 Hierarchical leadership
 You will attend meetings on-time
 Do it your own way at your own risk
 Directional
 (Vertical leadership)
 Consensus leadership
 Can we all agree that we will attend meetings on-time
 Also known as facilitative leadership
 I’m delegating accountability to you to deliver. I will support you, but I’m paying
you good money, treat it like it’s your own company
 Empowering
 (Horizontal leadership)
MILITARY
(leaders promoted/honed)
“CIVIL RIGHTS MOVEMENT”
(leaders emerge/evolve)
Which style is better? Can the styles be mixed?
Would a mixed style produce better results?

27
Leadership style - how not to be a walkover
 If you use consensus (democratic) leadership, how do you reflect your
disappointment, frustration or anger if that person doesn’t deliver?
 Most effective representation of “anger” is expressing it without the “high drama”
of rage (The Devil Wears Prada approach)
 You still have the same “power”, even if you don’t express it by shouting
 However, you must assert your disappointment clearly, using the right vocabulary
and body language (you must retain “control”)
 You have a “right” to be angry, however you need to maintain a respectful, non-
abusive, clean approach to dealing with the situation
 Avoid “Revenge Cycles”, common in “despotic” leadership
 You are expressing your rage with me by shouting at me/abusing me
 I’m going to find “passive/aggressive” ways to undermine you
 Many programmes fail because they have a poor relationship with team members
 Avoid “I did my best” mentality
 Accepting failure!
 Losers do their best. Winners go home and [text deleted] the “prom queen” –
Sean Connery (The Rock)

28
Leadership Styles – key factors
 A natural empathy with your key stakeholders
 Single-mindedness, strength of vision & strength of purpose
 Sceptical of conventional wisdom
 “Just because this is the way it’s always been, doesn’t make it the best way”
 Balance with “Why risk something new when the traditional way is proven, low
risk”
 Conventional wisdom is often the path of least resistance (people are naturally
change resistant)
 Other attributes of exceptional leaders
 Clear thinking
 Careful preparation
 Exceptional energy
 Willpower

29
Leadership Styles – key factors
 The ability to focus remorselessly on the desired outcome
 Disinclined to see two sides to any question or work for consensus because
that would imply doubt and indecision
 Need sage, trusted counsel to back your judgment
 Create an environment of CHANGE INEVITABILITY (it will change, whether
you resist or support)
 Know how to be pragmatic and when to retreat, (making smoke when
necessary)
 Balance pragmatism with steely resolve

30
Using psychology to lead
 Have empathy with the team, the client & the organisation
 I understand and acknowledge your point of view, but...
 Have you thought of... Might it be possible to...
 We, not me… Use the “team” - ‘we should get our plans together by…’
 Using emotions to drive behaviour
 Assertiveness vs aggressiveness
 Creating the balance between strength and friendship
 Your style dictates the style the programme exhibits
 If you don’t COMMAND respect, you won’t get any.
 What are the ways you get to command respect?
 What builds a cohesive, driven, motivated team?
 Your strength should be big picture, you need a deputy who does detail
 (eg. a PMO manager)

31
What are the tools leaders can use to lead?
 How do you control behaviour through influence?
 Reward
 Praise
 Shame
 Recognition
 Promotion
 Demotion
 Collective event
 Anger
 Shouting
 etc…
 The exceptional email…

32
Leadership Example
 Apollo 13...
 Gene Krantz established a “tiger team”
 What leadership characteristics did Gene demonstrate during the Apollo 13 crisis?

33
Leadership Example
 Downfall...
 Hitler lost control as a leader...
 What characterises Hitler’s style that lost the confidence of those around him?

34
Common scenarios
 The following are very common for programme managers coming onto a new
programme.
 Project managers are poor / low calibre.
 No PMO, client doesn’t see the need for them / doesn’t want to pay for one
 Client has read he needs a programme manager in an airport magazine but doesn’t really know
what to expect from one
 Previous PM was very good at creating/following procedures but the programme is hopelessly
late (why?)
 Clients expectations are completely unrealistic
 Client has no idea what it takes to deliver what is being asked for
 Key client stakeholders have totally different, misaligned objectives
 Programme is being “led” by the technology and the technical architects who are “excited” by the
prospect of loads of new technology
What do you do about them?

35
The difficult decisions
 Which approach is better?
 To get managers to take accountability or to avoid a blame culture
 To recycle a weak team or to reinforce with expensive consultants
 To maintain the dialogue with the client or to lead the project managers in
developing the plans
 To develop solutions to key problems or to send the team away to come up with
options
 To share the team’s concerns around the delivery timeframes or to maintain a
stubborn focus on delivering to the date
 To tell the client the date’s not achievable or to keep pursuing regardless until you
either succeed by force of will or the date is missed
None of these questions have a black or white answer.
 There are many factors that can influence the right course of action, the behaviour of the
client, the lifecycle of the programme, the behaviour of the team...

36
Programme Manager’s top-tips
 Allow yourself time to make good, well-informed decisions
 Don’t waste a lot of time gathering loads of data or getting buried in information.
Your team should distill key information into two or three options.
 Be decisive! Ensure you make a decision quickly, and then stick to it. It is ok to
change a decision occasionally if new information comes to light, but don’t make a
habit of it.
 Surround yourself with good people and particularly good project managers.
 Make sure they’re on the hook to deliver and they feel the pain when they don’t
 Allow them to learn from their mistakes and failures
 Don’t be afraid to refuse to sign things off if they don’t meet your expectations or
they don’t sound right.
 Learn to say “NO”
 It’s ok to “DO NOTHING”
 Know your goals
 And clearly understand your mandate and the extent of your powers. Eg. Can you
fire someone on the programme? If you disagree with a technical decision, are
you empowered to overrule it?

37
Role Plays
 You need to ask a difficult business sponsor for more budget as the scope is
increasing.
 You need an unmotivated developer to give you dates he/she will deliver
and commit to
 A supplier is pressurising you to place an order with them.
 You need to sack a poor performer
 There’s a problem & no-one knows what to do
 Your project manager doesn’t have firm grasp on his/her delivery dates
 A supplier calls and says he/she is not going to deliver on-time
 You need to get a decision from a group of people, but everyone has a
different point of view
Are there other situations you’ve faced which you’d like to game out?

Questions / Review of the day

39
Spider’s Web
TEAM Macbeth
Objective: Working in collaboration
with Team Hamlet, use the string to
get the ball from START to the
GOAL specified in the envelope,
carrying it above head height, but
without touching it.
Rules:
•You must not communicate with Team Hamlet
•Each team member must be holding the string
•Only the string may touch the ball.
•The ball must be carried above head height
•If the ball is dropped, you must return to START.
•If anyone touches the ball, you must return to
START.
TEAM Hamlet
Objective: Working in collaboration
with Team Macbeth, use the string to
get the ball from START to the
GOAL specified in the envelope,
carrying it above head height, but
without touching it.
Rules:
•You must not communicate with Team Macbeth
•Each team member must be holding the string
•Only the string may touch the ball.
•The ball must be carried above head height
•If the ball is dropped, you must return to START.
•If anyone touches the ball, you must return to
START.
You have 15 minutes to complete the task

Programme Dimensions
Every obstacle yields to stern resolve.
--Leonardo da Vinci
Every obstacle yields to stern resolve.
--Leonardo da Vinci

41
Four Dimensions of Project/Programme Delivery
 Product what is it?
 Scope: what am I going to get
 Time: when will I get it
 Cost: how much will it cost me
 Quality: will it work?
 Organisation who delivers it?
 Process how does it get delivered?
 Client/Business is it what I’m expecting?
PRODUCT
CLIENT or
BUSINESS
ORGANISATION PROCESS
RISK
OUTCOME
Clouded by the fog of RISK - likelihood of a successful outcome
Essence of good project management is to set &
monitor the levers of product delivery in “equilibrium”
Processes should guide where the levers should be set, how the
delivery should be monitored and identify risk areas.
=> REDUCE RISK | INCREASE CERTAINTY

42
Four Essential Disciplines of Portfolio Management
Plan
Management
Resource
Management
Financial
Management
Prioritised initiatives
Project Estimation
Inter-dependencies
Are we doing the right thing,
at the right time,
in the right order
to maximise business value?
Resource (talent) pool
BAU baseline
Project Plans
Do we have sufficient people,
with the right skills,
available at the right time
Budget
Business cases
Project costings
Can we afford it and
does it make us any money?
Change
Management
Project Plans
Change Impact Map
Training Needs Analysis
Stakeholder Engagement
Can the business tolerate the
change footprint and is the
business ready for it?
Tools/Diagnostics Discipline Allows us to understand:-
Underpinned by clear, accurate, unambiguous STATUS (through dashboard etc)
PERFECTVIEW

Managing the levers of RISK

44
Page 44
Programme Dimensions
REDUCE SCOPE
INCREASE BUDGET
INCREASE TIME
LOWER QUALITY
INCREASE SCOPE
REDUCE BUDGET
REDUCE TIME
INCREASE QUALITY
RISK
There are four levers to play with –
the challenge is to set each lever at just the right place that the programme is
stable, deliverable and an equilibrium is established.
1. BUDGET 2. SCOPE 3. QUALITY 4. TIME
Risk Balancing Act

45
Page 45
Reducing scope results in...
SCOPE
Fewer Geographies
Less Functionality /
Completixy
Lower Test Time/Costs
Less Functionality
Delivered (Lower
Revenues?)
Lower Application Build
Time/Cost
Lower Infrastructure
Capital/Maintenance
Costs (Test)
Lower Volumes /
Customers
Lower Infratructure
Build/Support Costs (Test)
Less Infrastructure
Capital/Maintenance
Costs (Prod/DR)
Lower Implementation
Costs
Potential For Performance
Bottlenecks
Less payback

46
Page 46
Increasing time results in...
TIME
Extend Delivery
Timescales
Fewer/Smaller Test
Infrastructure
Capital/Maint Costs
Date is fixed and will not
deliver all functionality
Lower Peak Resource
Load Cost
Capital/Maintenance
Costs (Test)
Reduce Parallel Activities
Lower Infratructure
Reduce Management
Overhead Costs
Capital/Main Costs (Test)
Not all functionality
delivered
Reduced Resource Costs
for Complex Integration

47
Page 47
Reducing quality results in...
QUALITY
Reduce Code Quality
Higher Defect Rates & Re-
work (increasing
Development costs)
Faster Coding Time
(potential lower resource
costs)
Undertake Less Testing
Lower Infratructure
Less Infrastructure
Capital/Maintenance
Costs (Test)
Lower Application
Development Costs
Increased Risk of
Application Failure
Utilise More Offshore
Resources
(lower unit cost/da)
Provide Service With Less
Resilience
Fewer Test Resources
Increased Risk of
Unexpected/Erroneous
Results
Higher Testing Costs
Build/Support Costs
(assuming offshore d/c)
Less Infrastructure
Capital/Maintenance
Costs (Prod/DR)
Risk of Extended Service
Outage
Risk of Missing
Contractual SLA’s
Risk of Missing Settlement
Deadlines
Increased Management
Overhead Costs
Stronger Governance
Required, Increased
Governance Costss

48
Quality can’t be rushed!
 Quality
 If there are no quality criteria defined, there can be no quality measurement
 If quality can’t be measured, it can’t be managed
 If quality isn’t reviewed, it is unknown (until the thing’s delivered)
 If new technology or unproven methods are utilised, expect a higher error / issue
rate, reduced quality, less knowledge / experience and therefore corresponding
increases in time & cost
 It is vital to have proper quality criteria for each of the major delivery areas.
 It is also vital to have a quality plan/approach, a list of products/deliverables to be
reviewed and a plan to review them!
“You can’t rush quality” - Boyd Coddington, 2006

Creating a high-performing
ORGANISATION
Coming together is a beginning, staying together is progress, and working together is success.
--Henry Ford
Coming together is a beginning, staying together is progress, and working together is success.
--Henry Ford

50
Creating a high-performing ORGANISATION
 Types of organisation
 Matrix Management / Competency pools
 Organisational cohesion & communications
 Organisational performance

51
Different types of organisation
 Hierarchical Traditional [Alexander the Great/Adam Smith]
 The Army
 Government
 Competency High “projects” focus, low “business as usual”
 CapGemini
 Accenture
 Bechtel
 Product Commodity focus, low “consulting”
 Microsoft
 Oracle
Product lifecycle
Project outcomes
Steady state / BAU

52
Challenges with a hierarchical organisation
 Inflexible
 Long chains of command to the top
 Poor communications
 Potential for conflict of priorities if mixing project and BAU work
 Matrix management
 Who owns the “final say”?

53
How does governance fit in?
 PMO
 Architecture Design Board
 how is this comprised?
 Who has the final say?
 Assurance & Governance functions
 Who is accountable?
 Role of Portfolio Management

54
Organisational cohesion
 Everyone in the organisation MUST have clear objectives, consistent with
the objectives of the programme
 Everyone in the organisation MUST know what they are responsible for and
accountable to deliver
 Everyone in the organisation MUST know who they report to for what
 Everyone in the organisation MUST be measured and bonused on objectives
relevant to the successful outcome of the programme
The programme manager MUST regularly verify that everyone in the
organisation is crystal clear on all of the above

55
Communications
 It is essential that the programme manager communicates directly with the
entire organisation verbally using “cascades” on a regular basis.
 It is absolutely essential that everyone in the organisation feels they can
openly and honestly report problems and communicate issues.
 It is vital that the programme manager has two-way communications with
team members at ALL levels, not just through the management team.
 ALL decisions regarding structure, pay & conditions etc MUST be decided
upon and communicated RAPIDLY.
 A vacuum created by uncertainty over any of the following KILLS a programme
 What am I doing (and why am I doing it)
 Who do I report to
 How does what I’m doing fit in
 Is the programme scope/date changing
 Am I being renewed
 Are there any changes in the terms of my engagement in the programme
 Are my personal objectives closely aligned with what I’m being asked to do
 Is the client happy
 MIGHT WE SLIP THE DATES?

56
Organisational cohesion
 Example of a programme booklet

57
Organisational performance
 A dysfunctional programme organisation WILL fail
 Nothing should be a barrier to success
 Strength of will and strength of purpose are the key
 There are no such terms as...
 It can’t be done
 It will never work
 There’s insufficient time
 etc.
- If you accept these phrases, you are, by implication, accepting failure –
- The question is, however, what is the balance between dogged
determination and “listening to wise counsel”
(pragmatism vs steely resolve)

58
Organisational performance
Don’t know what they are doing
Can’t be arsed
Do know what they are doing
Can’t be arsed
Don’t know what they are doing
Keen
Do know what they are doing
Keen
(but a pain in the arse)
SACK
TRAIN
MOTIVATE
MANAGE
 There is NO perfect team member. Just can do or can’t do!!!!

59
Organisation top-tips?
 There is no right or wrong way to organise a programme.
 The more the programme fits into the existing organisation structure, the easier it will
be to make work
 Programme organisation charts are frequently a nightmare (as they are highly political
and are often at odds with the company org-structure).

Managing the Client

61
Managing the client
 What does the client want
 HIS STUFF DELIVERED – on time, on budget and exceeding his expectations!
 CONFIDENCE – that his delivery is with a safe pair of hands
 THE TRUTH – he’s going to find out eventually anyway
 What does the client want to KNOW?
 What am I getting? Is it still what I want? SCOPE
 Do my people keep dreaming up more things to do? CHANGE
 What have I spent / How much more am I in for? COST
 Am I still going to make any money out of this? BENEFITS
 When am I going to get it / is it on track SCHEDULE
 Is there anything likely to cause the wheels to come off? RISK
 Is there anything holding us up I can do something about ISSUES
 Do I need to decide anything or give guidance DECISIONS
 Have the senior stakeholders or sponsors changed? High churn in
executive sponsorship spells trouble

62
Managing the a difficult client
 What kind of influencing styles can one deploy against a difficult client
 Managing expectations

Managing the Client
THE BUSINESS CASE

64
Contents
• Why do we have to do Business Cases?
• How should a Business Case be written?
• What are the types of things that are looked at when Business Cases
are reviewed?
• What do Finance/Procurement typically look for when reviewing
Business Cases?
• What is a Benefit?
• Redflags / Greenflags in a business case

65
The purpose of a Business Case is to capture the reasoning for initiating a project
or task.
“As an organisation, we have limited choices in terms of labour and money, and
we have to prioritise in accordance with the right decision based on investment
and strategic direction”.
The principle purposes of the business case process are to;
• Introduce a way of thinking that causes people with the authority to recommend projects to firstly
consider their value, risk and relative priority as a fundamental element of submitting the project
approval
• Require those proposing a project to justify its value to the company and to self-cull any proposals that
are not of demonstrable value
• Enable management to determine if the project proposed is of value to the business and achievable
compared to the relative merits of alternative proposals
• Enable management to objectively measure the subsequent achievement of the business case’s
benefits.
The business case process is an organisational process
(and not a Finance process).
Why do we have business cases

66
Why is a business case important
 It answers the question for the client “Why am I doing this”
 It tells the client “how much money am I going to make once it’s done”
 It ensures the client “keeps the faith”
 House renovation example
 Why would you invest in a renovation project property
 How much would you spend on the renovations
 How much do you expect to make
 Film investment example
 Invest in this film, it’s going to be great, really exciting, lots of stars...
 How do I know it is going to make money
 What are the major cost variables
 How do I know what I need to measure & monitor in order to know whether I’m going to
make any money
 Investing in something should be “informed”. It should NEVER be a leap
of faith.

67
What should go in a business case?
 Financial
 Non-financial
 Not doing the initiative
A business case needs to be:-
 Measurable & MEASURED
 Realistic, not fantasy
 Assumptions MUST be evidentially supported
A BUSINESS CASE SUMMARY SHOULD BE THE
DRAGON’S DEN QUESTIONS ANSWERED!
(ie. a 5 minute pitch, and/or maximum 2-3 page written summary)
Why am I doing this & how much
am I going to make?

68
What should go in a business case?
 Summary of the proposal, key benefits, timescales, costs, risks, approval to proceed
(and spend) to next stage - 2 – 3 pages
Detailed Business Case
 Current situation, rationale for change, description of opportunities
 What is proposed, including outcomes/objectives
 How does the initiative fit with any overall business strategy
 Over what timeframe, key milestones, level of planning detail
 Financial analysis, commitments at each stage gate, cashflow, funding, variance,
procurement, discounted cashflow (NPV)
 Sensitivity analysis, key risks & issues
 KPIs, tangible/intangible business benefits
 Effect of not proceeding
 Other options considered, including costings, reasons for rejection
 Impacts of business-as-usual operations, headcounts, other projects/dependencies
 Next steps & Appendices

69
How should a business case be written?
The business case process should ensure;
• The required issues have been thoroughly considered and documented
• Sufficient information to facilitate fair evaluations of different proposals is available
• Both the value and risks inherent in the proposed project are clear
• The project is sponsored by, and has the commitment of an employee with the capability
and authority to deliver the benefits
• The delivery of the outcomes and benefits can be traced and measured
The business case should be written based on the following guidelines;
• The Business sponsor / owner should write the case (not the Project Manager)
• There should be one consistent template
• The explanation should be reasonably high level (circa 3 pages) with any technical detail
referenced in Annexes
• It should provide the necessary background information to inform decision making by
senior management

70
What is a benefit?
Tangible Intangible
FinancialNon-financial
Reduction in costs
Accommodation savings
Better cash management
Increased revenue
Increased contribution
Better quality of service
Improvement to KPI targets
inc. CSI
Lower staff turnover
Fewer customer complaints
Improved productivity eg AHT
Lower customer churn
Increased people morale (Reflect)
Corporate ‘image’
Better access to information
Improved processes
Increased competitiveness
Access to markets
Regulatory requirement
Based on Deloitte ‘Types of benefits’

71
Business Case Levers
 Revenue Enhancement
 When the programme has completed we are expecting this amount
of revenue growth.
 Cost Reduction
 We currently spend this amount on doing this stuff, after the
programme we will spend that
 Risk Reduction
 If we don’t do this, we can expect this amount of fraud
 Compliance
 We will be “fined” this amount if we don’t do this
QUESTION: Would I spend MY OWN MONEY on this?

72
 Revenue Enhancement is the hardest value to predict in a business case,
because a business is never stable
 Has revenue grown because of my programme or because of new
products we introduced or the fact that the market conditions have
changed, one of our competitors went bust, we came out of recession
etc.
 Cost Reduction is the easiest to measure because most organisation’s
cost management and FTE management will easily determine changes to
the cost profile
 BUSINESS CASE GOLDEN RULES
 All assumptions MUST be closely scrutinised, because many are rubbish
 If you can’t measure it in isolation, you can’t tell what’s impacting it
 Many business cases aren’t worth the paper they’re written on
 At its most basic form, the client simply wants to know what he’s going
to make out of it, and whether he would be better off sticking the money
in the bank.
 If you don’t measure the benefits post go-live, you don’t know whether
what you’ve delivered has added any value.

73
 Is the business case “religious or agnostic”?
• Is this the sponsor’s “pet project”
• How likely is it the business case will be rejected and the programme not
proceed
• Would the sponsor be willing to sacrifice his own salary/bonus on the definite,
measurable results from the business case
 Where a business case has options, has the team chosen their preferred
option, as opposed to the one most likely to produce the highest
benefits?
• CRM are classics – is the “big package” the best solution?
• In order to make back £50m, you have to have very significant uplifts in
revenue and profit.
 Business cases are “orders of magnitude”
• Variance in accuracy depends on the amount invested in driving out the detail
• A business case is a living document – at each stage, as more is known, more
detail should be incorporated into the case in order to determine whether the
programme is still worth proceeding with
• 100% of the costs of a programme will be known when it is finished & spent!

74
What makes a successful business case
•The investment has value and importance
•The project will be managed properly
•The company has the capability to deliver the benefits
•The company’s dedicated resources are working on the highest value
opportunities
•Project’s with inter-dependencies are undertaken in the optimum sequence
• Procurement input – named individual?
• Finance input – named individual?
• What is the impact of not doing the initiative?
• What are the first year support (FYS) costs? (and associated capitalisation rules)
• Have quotations for third party work been included?
• Alternative suppliers/solutions considered?
• What can we de-commission?
• Strategic reason/fit (cost saving/legal requirement/capacity/revenue
enhancing)
Business Cases are formal documents which put the case for the investment of
money and other resources in a project or programme of work.

75
What do procurement look for
Procurement;
•The quantity of external spend that is being considered – Opex / Capex (£m)
•A description of what products or services are being purchased externally
•Which suppliers are being / have been considered – are they an existing or
preferred or a new supplier. If a new supplier, what process has been gone
through to select them?.
•Are the products /services therefore calling off from an existing contract or
price list or is a new contract being put in place?.
•Which procurement individual has been engaged & was it as early as possible?
•Have any wider synergies (for example, co-sourcing, shared services etc.)?
Finance and Procurement are engaged at project inception.

76
What do Finance typically look for?
Finance;
•The proposed expenditure represents “value for money” / strategic fit
•The financial evaluation is appropriate, correct and all options have been
considered
•The costs are confinable within Budget (or authorised deviation)
•Appropriate accounting and control procedures are in place
•Operational line authority and other authority / concurrence has been given
•Procurement policy has been followed
•Have the benefits been baked into Opex plans? signed up to?
•Has discounted cashflow (NPV), wage inflation, leasing, depreciation,
amortization etc. been factored into the numbers?

77
Red flags in a business case?
This initiative will:-
• Improve business efficiency
• Improve job satisfaction
• Create increased customer loyalty
• Improve staff effectiveness
• Reduce risk of fraud
• Generate increased sales
• Is an enabling initiative
• Will improve the customer experience
• Will increase product holdings per
customer to an average of 2.1
• Will reduce Average Call Handling Time to
1.3 minutes/customer
Why is this an issue:-
Where will these efficiencies be derived? How much cost will be saved?
Will there be FTE reductions as a result?
How does this translate to company performance? Will it improve staff
retention, therefore lower recruitment costs?
What is the customer lifetime value? How much does customer loyalty
cost and how much does it contribute to revenue and margin?
How does staff effectiveness translate into reduced FTEs, increased
capacity and therefore costs/benefits?
How does this quantify? What is our risk exposure in £ value? How
much fraud have we seen to-date?
How many sales? How does this impact cost of sale, stockholding and
cashflow. How much additional revenue & margin
This is a catch-all get-out-of-jail free benefit, because we can’t really
think of any benefits.
How much is that improved customer experience worth. Does it match
the cost of the improvement.
How much does that contribute to overall revenue and margin. This,
inof itself is not a useful measure
Same point as above. Does that allow us to avoid costs or reduce costs
in our call centres by reducing FTE’s?

78
Green flags in a business case?
This initiative will:-
• Improve business efficiency by improving average call handling time from 2:30 minutes to
1:30 minutes per call. We handle 25,000 calls per annum, thus increasing our call handling
capabilities by 50%. We propose, therefore to reduce FTE’s in 2012 by 12 heads, saving
£1.3m per annum. Please see Appendix A: Cost Savings for detailed breakdown.
• Improve job satisfaction, thus improving our staff retention rate from 5% staff churn per
annum to 2%. This in turn will reduce our recruitment costs by £85,000 per annum and
reduce our staff training downtime by 980 man-weeks per annum. This will result in an FTE
reduction of 3 heads, saving £240K per annum.
• Create increased customer loyalty. At present, the fully loaded cost of acquiring a new
customer is £9,380, based on £4,230 above the line marketing costs, £5,100 below the line
marketing costs and a £1,380 cost of sale. Therefore by reducing churn by 8%, we would add
£11.6m per annum to margin. Please see Appendix F: Churn reduction forecast model for
details.
• etc. etc.
Business benefits have numbers that can be measured!

Managing the Client
THE REQUIREMENTS

80
What are requirements
 They are what the client “wants you to deliver”
 They are unambiguous statements of BUSINESS need (not IT systems need)
 They are realistic and achievable
 They can be directly correlated to a business benefit
 (so we know what value each requirement is contributing)
 There aren’t too many of them in each phase of work
 They aren’t dictating the solution in a way that increases risk
 They are uniquely referenced
 They are “standalone” and not “embedded”
The most important thing is that a programme team member can read one,
and clearly understand what the client wants without having to clarify it.

81
Requirements pitfalls
 The solution must comply with all applicable laws
 Which laws are applicable? This is a “catch all requirement”
 The solution must comply with ISO20020 Information Governance
 This is not one requirement. This is hundreds of requirements, all contained in the
ISO 20020 document. Each one of these should be individually specified and
understood
 The solution must have the ability to use multiple dictionaries and support
multiple languages & character sets
 This is not one requirement, it is three.
 The system must provide tools like calendar and calculator
 To do what? Like???? What else?
 The solution must support changes to the challenge/response password
 This is highly ambiguous – what does this actually mean??? How? Using an online
system, phoning a call centre etc. etc. This could be three lines of code or a
whole business process
 None of the above have reference numbers, so there is no traceability, nor is
there any rationale as to what business benefit they support or why!

82
 Be careful of the distinction between a “BUSINESS REQUIREMENT” and an IT
FUNCTIONAL (or systems) REQUIREMENT “
 Are there any non-functional requirements (particularly business ones, such
as business volumetrics (number of users/geographies), service levels that
must be achieved
 Are there any business change requirements specified (new ways of
working). Do there need to be any?
 Has the “customer” impact been considered – how do the requirements
relate to the “customer experience”. Has the customer experience been
defined.
 Have “data” requirements been specified? (Reference data sources / data
retention). All these things have impact on costs.
 Poorly defined requirements lead to poorly delivered programmes, lots of
change requests and lots of aggravation with the client.

83
What are the “types” of requirements
Business SME
input
Business Driver
Research
Industry Best
Practice
Customer
Experience
Lifecycle
Customer
Experience
Definition
Business
Model
Business
Case
Target To-be
Processes
Impacted
Processes
Process KPI’s &
Volumetrics
Process-led
requirements
Process Maps
Hypotheses
Business
(People)
Requirements
Functional
Requirements
(Technology)
Non-Functional
Requirements
(Technology)
Business
Environment
Requirements
Organisational
Impact
Assessment
Systems
Requirements
“PEOPLE”
“PROCESS”
“TECHNOLOGY”
Organisational Requirements
Systems Functional Requirements
Business Requirements Specification
Prioritised
Initiatives
Traditional waterfall “requirements” breakdown – process led

84
Business Requirements

85
System Functional Requirements
 “like”???? “etc”?????

86
 Business Requirements Specification (BRS) says “we want a car. It must have
gauges.”
 Discovery phase conducted between client and systems integrator created a
functional requirements document that says “it must be a car, have four wheels and
be able to carry two passengers.
– Didn’t mention gauges at all.
 SI provided a contract with a referring document stipulating the functional
requirements as the scope
 The Business had some “implicit requirements” that appear to have been omitted or
assumed. For example;
– The car must be able to travel off-road
– The car must be capable of reaching 155mph
– People must be able to drive!
 Contract that the Client has signed can be fulfilled with a Suzuki Jeep
– The basis of the Systems Integrator estimating and costing
 BRS, including all the implicit “detailed” requirements indicate that the need is for
a Porsche Cheyanne and driving lessons!

87
Alternatives to the Business Requirements Specification
 Particularly in an Agile world, it has been necessary to move away from
detailed requirements specifications.
 Take too long to write
 Ambiguity leads to the wrong outcome
 New approaches include defining outcomes at various levels of granularity
 Multi-layered approach…
 Define overall business goal (and the business capabilities therein)
 Sub-divide business goal into a series of scenarios (epics)
 Define role of each ‘actor’ within the scenario (user stories)
 Drill into each role/actor until all the business rules, handoffs and processes are fully understood
 Define benefits of each scenario (business value vs cost)
 Collaborative engagement with third-parties
 Prioritisation process
 Order the delivery of requirements into business benefits delivering
 Create the release schedule & product backlog

Managing the Client
THE COMMERCIALS

89
Managing the COMMERCIALS
 Tripartite relationships rarely work!
 Who is accountable? What if it goes wrong? If the SLA’s aren’t met, is it the
designer or the builder?
 If the SLA’s aren’t agreed in advance, they will be a source of conflict
 If the prime contractor cannot guarantee the SLA’s, the prime contractor has no
idea whether the SLA’s can be met.
 That means he doesn’t have the experience to know whether the solution will meet
the SLA’s.
 Therefore, he’s either not done it before or he is not a prime contractor.
 You can only fix the price of the contract if the entire scope is known and
locked
 If your programme slips, you can’t expect a sub-contractor to tolerate slippage
 If change requests come into the programme, they should be impacted by ALL
teams, including sub-contractors!
 Time and materials should be used in “requirements, capped T&M in
“design” Fixed price for a complete programme should NEVER be entered
into until these two phases are agreed, understood and signed off!

90
Managing the COMMERCIALS
 Always use a structured procurement process
 Request for Information/Request for Proposal force the team to fully think through
and document all the requirements before committing to a product
 Using a structured, weighted evaluation allows the products to be evaluated
against each prioritised requirement
 Typical evaluation criteria include
 Technical, Operational, Functional, Commercial, Implementation, Total cost of ownership
 Kepner Tregoe is a common weighted evaluation procedure
 An RFI/RFP process is there to protect you & the team from accusations of
favouritism
 A well run process drives out best value. Note, not just CHEAPEST!
 RFI/RFP doesn’t have to take six months. Can be done within two – three
weeks if the process is rigorously defined and adhered to
 Always publish a timetable to a decision AND STICK TO IT!

91
COMMERCIALS GOLDEN RULES
 If you MEASURE the wrong things, you create the wrong BEHAVIOURS which
leads to the wrong OUTCOMES
 CHEAPEST IS VERY RARELY BEST
 NEGOTIATE ‘WARM BUT TOUGH”
 “COMPETITIVE DIALOGUE”

Deriving the plan
How do you arrive at a release schedule & plan

93
Attributes of a great plan
 Plan must be believable
 Plan must be “smooth”, not back-loaded (quarterly releases?)
 Plan must have measurable milestones in each phase to monitor progress
 Plan should work “right-to-left” as well as left-to-right
 Plan should have appropriate delivery horizon (3 – 6 months, high level of
detail, 12months+, releases)
 Dependencies should be known & UNDERSTOOD
 Collaborative planning – commonly derived and understood plan!

94
Managing the Processes
The NineDimensions Approach
 RAID Management
 Change Management
 Financial Management
 Status Management
 Deliverables Management
 Planning & Estimating
 Resource Management
 Quality & Governance
 Stakeholder Management

95
What level should I be managing at?
 Recommend managing at the “work-package” level
 Dependencies between work-packages or external from the programme
MUST be known
 I can’t start this piece of work until..... PRE-REQUISITE
 I can’t finish this piece of work until.... CO-REQUISITE
 For a work-package to be “COMPLETE”, all work must have been finished,
no-one should be working on it any more, all the deliverables should be
signed off, the exit criteria should have been met.
 It is NOT acceptable to mark a work-package as complete when work is still outstanding
 It is extremely dangerous to mark a work-package as complete, and roll-up any work still
outstanding into a NEW work-package (snowball effect, disguising slippage)
 If a work-package lasts less than a week, you are managing at too lower
level.
 Each work-package should have a work-package description produced for it
in advance of the work being started. It should be signed off by you and the
client (the client should sign the consolidated stage-plan)

96
Work-package Descriptions
What should be in a WDP?
Should be completed by
the person responsible
for performing the work
and signed off by the
person accountable for
it’s successful outcome
• Purpose of the work-package
• Approach to deliver it
• Owner (and lead performer)
• Inputs & Outputs (components)
• Dependencies & Constraints
• Reporting Requirements
• Scope
• Resources
• Milestones
• Costs
• Acceptance Criteria
• Reviewers & Sign-offs
• Risks, Assumptions
• Document Control

97
Work-package Descriptions
Example set of programme workstreams & work-packages
LLD-I-P-WP
Programme
LLD-I-A-WP
ACCELERATE
LLD-I-C-WP
CRUISE
LLD-I-T-WP
TEST
LLD-I-CS-WP
CS
LLD-I-CH-WP
CHANNELS
LLD-I-F11
SOC Autodeploy
UAT
LLD-I-A01
Offer Strategy
LLD-I-C01
KPI Reporting
LLD-I-T01
AsIs
Test Process
LLD-I-CS01
Outbound UAT
LLD-I-D01
UAT
LLD-I-F12
XS/US Campaign
5 Free MMS
LLD-I-A02
Campaign
Offer Schedule
LLD-I-C02
Process
Measures
LLD-I-T02
Quick Wins
LLD-I-CS002
Pilot (Phase 1)
LLD-I-D02
Pilot
LLD-I-F13
Data Xfer
£49.98
LLD-I-A03
Campaign &
Offers for Indirect
LLD-I-C03
BPCU Capability
LLD-I-T03
BAU Test
Process (Interim)
LLD-I-CS03
Rollout (Phase 1)
LLD-I-D03
Rollout
LLD-I-F14
Campaigns
for Direct
LLD-I-A04
Resource
Transition
LLD-I-C04
Business Case
(Full)
LLD-I-T04
Long-Term
Test Reqts
LLD-I-I01
UAT
LLD-I-F15
BPCU Campaigns
LLD-I-A05
Campaign
Reporting Reqts
LLD-I-C06
Change Mgt
Review
LLD-I-I02
Front3 Launch
LLD-I-F16
XS/US Campaign
Web & Walk
LLD-I-A06
Processes
LLD-I-C06
Review Exit /
Completion Criteria
LLD-I-I03
Carphone
Deployment
LLD-I-A07
SOC Change
Process
LLD-I-C07
Facilitate
Channel Launch
LLD-I-I04
Channel
Implementation
LLD-I-A08
Handset Mgt
Process
LLD-I-C08
Business Review
LLD-I-A09
Interim OMSE
Solution
LLD-I-A10
Housekeeping
LLD-I-F-WP
FIX
LLD-I-F01
Campaign Design
Review
LLD-I-F02
XS/US Campaign
Itemised Billing
LLD-I-F03
CAP Rule Change
LLD-I-F04
BIS Preparation
LLD-I-F05
Outbound
Campaign
LLD-I-F06
WebReg/Domino
Defects
LLD-I-F07
SAS Model
Prioritisation
LLD-I-F08
VAT Solution
LLD-I-F09
£90 Subsidy
LLD-I-F10
Belnded
Definition Soln
LLD-I-A11
Marketing
Reporting
LLD-I-A12
OMSE / SAP
Pricing
LLD-I-T00
TestCTNs
LLD-I-F17
INFO Campaign
Direct Debit
LLD-I-F18
INFO Campaign
First Call Resolution
LLD-I-F19
Business Support
LLD-I-F20
End2End Testing
Of ALL fixes
LLD-I-A13
Campaigns for
CS Outbound UAT
LLD-I-A14
CCOS Bible
LLD-I-A15
Campaigns for
CS Renewals
LLD-I-CS04
Outbound
CAP Rule UAT
LLD-I-CS05
Outsourcer
Deployment
LLD-I-CS006
Pilot (Renewals)
LLD-I-CS07
Rollout (Renewals)
LLD-I-P-WP
Programme
LLD-I-A-WP
ACCELERATE
LLD-I-C-WP
CRUISE
LLD-I-T-WP
TEST
LLD-I-CS-WP
CS
LLD-I-CH-WP
CHANNELS
LLD-I-F11
SOC Autodeploy
UAT
LLD-I-A01
Offer Strategy
LLD-I-C01
KPI Reporting
LLD-I-T01
AsIs
Test Process
LLD-I-CS01
Outbound UAT
LLD-I-D01
UAT
LLD-I-F12
XS/US Campaign
5 Free MMS
LLD-I-A02
Campaign
Offer Schedule
LLD-I-C02
Process
Measures
LLD-I-T02
Quick Wins
LLD-I-CS002
Pilot (Phase 1)
LLD-I-D02
Pilot
LLD-I-F13
Data Xfer
£49.98
LLD-I-A03
Campaign &
Offers for Indirect
LLD-I-C03
BPCU Capability
LLD-I-T03
BAU Test
Process (Interim)
LLD-I-CS03
Rollout (Phase 1)
LLD-I-D03
Rollout
LLD-I-F14
Campaigns
for Direct
LLD-I-A04
Resource
Transition
LLD-I-C04
Business Case
(Full)
LLD-I-T04
Long-Term
Test Reqts
LLD-I-I01
UAT
LLD-I-F15
BPCU Campaigns
LLD-I-A05
Campaign
Reporting Reqts
LLD-I-C06
Change Mgt
Review
LLD-I-I02
Front3 Launch
LLD-I-F16
XS/US Campaign
Web & Walk
LLD-I-A06
Processes
LLD-I-C06
Review Exit /
Completion Criteria
LLD-I-I03
Carphone
Deployment
LLD-I-A07
SOC Change
Process
LLD-I-C07
Facilitate
Channel Launch
LLD-I-I04
Channel
Implementation
LLD-I-A08
Handset Mgt
Process
LLD-I-C08
Business Review
LLD-I-A09
Interim OMSE
Solution
LLD-I-A10
Housekeeping
LLD-I-F-WP
FIX
LLD-I-F01
Campaign Design
Review
LLD-I-F02
XS/US Campaign
Itemised Billing
LLD-I-F03
CAP Rule Change
LLD-I-F04
BIS Preparation
LLD-I-F05
Outbound
Campaign
LLD-I-F06
WebReg/Domino
Defects
LLD-I-F07
SAS Model
Prioritisation
LLD-I-F08
VAT Solution
LLD-I-F09
£90 Subsidy
LLD-I-F10
Belnded
Definition Soln
LLD-I-A11
Marketing
Reporting
LLD-I-A12
OMSE / SAP
Pricing
LLD-I-T00
TestCTNs
LLD-I-F17
INFO Campaign
Direct Debit
LLD-I-F18
INFO Campaign
First Call Resolution
LLD-I-F19
Business Support
LLD-I-F20
End2End Testing
Of ALL fixes
LLD-I-A13
Campaigns for
CS Outbound UAT
LLD-I-A14
CCOS Bible
LLD-I-A15
Campaigns for
CS Renewals
LLD-I-CS04
Outbound
CAP Rule UAT
LLD-I-CS05
Outsourcer
Deployment
LLD-I-CS006
Pilot (Renewals)
LLD-I-CS07
Rollout (Renewals)

98
Work-package Dependencies
98
LLD-I-A01
Offer Strategy
LLD-I-C01
KPI Reporting
LLD-I-T01
AsIs
Test Process
LLD-I-CS06
Outbound UAT
LLD-I-A02
Campaign
Offer Schedule
LLD-I-C02
Process
Measures
LLD-I-A03
Campaign &
Offers for Indirect
LLD-I-T03
BAU Test
Process (Interim)
LLD-I-A04
Resource
Transition
LLD-I-C04
Business Case
(Full)
LLD-I-T04
Long-Term
Test Reqts
LLD-I-I01
UAT
LLD-I-A05
Campaign
Reporting Solution
LLD-I-C06
Change Mgt
Review
LLD-I-I02
Front3 Launch
LLD-I-A06
Processes
LLD-I-C06
Review Exit /
Completion Criteria
LLD-I-I03
Carphone
Deployment
LLD-I-A07
SOC Change
Process
LLD-I-C07
Facilitate
Channel Launch
LLD-I-I04
Channel
Implementation
LLD-I-A08
Handset Mgt
Process
LLD-I-A09
Interim OMSE
Solution
LLD-I-A10
Housekeeping
LLD-I-A11
Marketing
Reporting
LLD-I-A12
OMSE / SAP
Pricing
LLD-I-A13
Campaigns for
CS Outbound UAT
LLD-I-A14
CCOS Bible
LLD-I-A15
Campaigns for
CS Renewals
LLD-I-CS07
Outbound
Rollout
LLD-I-CS09
Pilot (Renewals)
LLD-I-CS10
Rollout (Renewals)
LLD-I-A16
End2End Test
A
B
LLD-I-CS08
Renewals UAT
C
LLD-I-F06
WebReg/Domino
Defects
LLD-I-D02
Pilot
31/2/07 3/4/07 28/5/07 30/7/07
LLD-I-T05
Interim Test
Environment
LLD-I-A17
Outbound PRP
This is where
Microsoft Project can
really help – use it
to manage & track
dependencies
between
work-packages &
identify the critical
path

99
Status Reporting
 My project/workstream is on-time and on-budget.
 My project is on-time but over-budget
 My project is on-time and on-budget, but I forecast it will go over-time
 My project is on-time and on-budget, but I forecase it will go over-time and over budget
 My project is on-time and on-budget, and will deliver on-time and on-budget, but the number of
defects is extremely high
 My project is on-time and on-budget, the number of defects is low, but I have hundreds of change
requests which haven’t yet been impact assessed
 My project is on-time and on-budget, but in a weeks time I lose all my resources to Project X
 My project is late and over-budget
 My project is on-time and on-budget but there’s an issue that’s preventing me from making any
further progress
 My project is on-time and on-budget, but I’m dependant on another project which is late
WHAT IS THE CORRECT RAG STATUS FOR EACH OF THESE?

100
RAGs
 It is essential that
commonly agreed and
understood status for
RAGs are defined and
communicated.
Otherwise, one person’s
Green is another person’s
Amber.

Managing a programme’s PROCESSES
A successful PMO

102
Managing the Processes
A Successful PMO
 What does a good PMO do?
 Why do you need one?
 How big should it be?
 What if the client won’t pay for one?
 If you don’t have an excellent PMO, with a top-class PMO manager, you won’t have
a clue what the status of your programme is
 If you have time to undertake some of the PMO’s tasks, you aren’t leading the
programme
 There is a big difference between a programme management office and
programme governance.
 The PMO serves you!
 Programme Governance servers you and the organisation

103
Key Success Factors – what benefits does a PMO bring?
 When we know what we should be doing each week and we know whether
we’re doing it/we’ve done it
 We know what our deliverables are, who our resources are, what we’re
spending, and how all these compare to plan
 When everyone understands exactly what their role and empowerment is
 When we have a management and governance structure which is
efficient, embedded and trusted
 When our decisions are explicitly made at the right level and accepted by
our stakeholders
 When everyone who has an interest in us understands what we’re doing
 When our planning focus is months, not weeks
 When our morale is sustained by our success

104
Programme Management Office Organisation & Activities
Programme
Office Manager
Programme
Communications
Analyst
Programme
Quality
Assurance
Programme
Controller
Financial Analyst
Programme
Controller
Resources
Programme
Controller
Plan
Programme
Administrator
Programme
Controller
RAID/Change
•Financial Controller
•Order Management
•Contract Management
•Supplier Management
•(Logistics Support)
•(RAID Process)
•(Change Process)
•IT Work Orders
•Workshop Support
•Email Dlists
•Logistics Support
•Meeting Room Management
•Senior Team Diary Mgt
•Hotel Administration
•Meeting Minutes
•RAID Process Owner
•Change Process Owner
•(Financial Controller)
•(Document Controller)
•Stage Plan Delivery
•PMO Processes Owner
•Status Report Owner
•Ad-hoc reporting
•Quality Management
•(Plan Manager)
•Procedures Adherence
•Audit Relationship
•Governance
•Integrated Plan Manager
•Dependency Manager
•Deliverables Tracking
•Document Controller
•Signoff Tracking
•Future phase planning
•(Quality Manager)
•Programme Comms
•Stakeholder Management
•Steering Group Secretariat
•Team Environment
•Programme Brand
•Workshop Support
•Workstream Review/audit
•Project audit
•New starters
•Organisation Maintenance
•Performance Management
•Contractor Roll-on/Roll-off
•Resource Planning
•Terms of Reference / RACIs
•Role Description Management
•Logistics / Desk Planning

105
KSFs – what does the role needs to succeed?
 Programme Manager
 Providing leadership and engagement to the team
 Programme Manager looks ahead and around
 PMO performs to the Programme Manager, but PM directs the PMO
 Says Yes, and says No – and No sticks
 Programme Office Manager
 Structure of c. 5-8 people which operates the detail
 Led by strong Operational Manager
 Reporting to the Programme Manager, but empowered and equipped to
run the machine
 PMO drives and guides performers
 Governance and internal programme processes
 Workstreams follow the direction set by PMO
 Based on agreed, aligned plans not diktat!
 PMO is not just an administrative or advisory function

106
Example of PMO service levels
 New starter (due to join)
 Desk move
 Access to document mgt tool
 Access to process mapping tool
 Access to Time reporting tool
 Visio / Project
 Laptop
 External Access
 Internet Access
 Request for a hotel
 Request for meeting / workshop support
 Update to plan
 Update to programme status
 Change request
 Addition to risks or issues
 Request for a telephone
 Purchase request (Purchase order CAPEX)
 Request for a projector
 Ad-hoc requests
2 weeks
6 weeks
1 day
1 day
10 days
2 weeks
2 weeks
2 weeks
1 weeks
1 day
2 days
1 day
1 day
7 days
1 day
100 years
10 days
Never
-
tbc
tbc
Request SLA Primary Contact

Programme Pitfalls and Assurance

108
Key attributes of a successful programme
 Managed, achievable expectations
 Commonly believed in Programme Plan
 Communication & Openness
 Delegated Accountability
 Passion & Commitment (from everyone to succeed)
“Changing the
programme is not a
weakness”
“Avoid shared
workstream
resource”
“Requirements MUST
be unambiguously
clear”
“If it can’t be said
on one side of A4,
the message is too
complex”
“Avoid trying to
change ‘too much’ in
one release”
“Watch out for
Powerpoint Frenzy
or Meeting Mania”
“Beware of a dotted
lines on organisation
charts”
“TEST EARLY as
possible - especially
integration”
“Everyone in the
business must be
committed to the
change”
“Watch for scope-
creep by stealth –
change requests”
“Be ready for the
technology not to
work or be late”
“NEVER, EVER be
the first to
implement a V1.0
solution”
“Know the desired
outcome/vision
before you start”
“Training Needs and
User adoption are
freqently under-
estimated”

109
Programme Assurance
 Poor programme managers fear “assurance & audit”
 Excellent programme managers EMBRACE “assurance & audit”
 Another pair of eyes
 No-one has all the right answers all the time
 The assurer might spot something I’ve missed which means I succeed instead of
fail
 As time progresses, most programme managers tend to start to get tunnel vision
on specific issues which can be hard to break out of and stand back from.
 Avoid being defensive.
 Use assurance as the opportunity to draw from the assurers knowledge and skills too.
 If they’ve pointed something out bad and it sounds accurate, acknowledge it and embrace
change, don’t try to defend the status quo or the reasons why.
 Few people get sacked for changing things not working or doing the right thing

110
Programme Assurance Survey
 Enclosed is a 100 question quick survey which a programme manager can use
to get the temperature of things going well and things going not-so-well in a
programme.
 It should be completed by ALL team leaders and project managers in a
programme.
 It is also useful to distribute to a few team members (even though some of
the questions aren’t relevant to them)
 It assesses the programme dimensions outlined previously
 Risk
 Organisation
 Client
 Process
 The closer to 0 each score, the poorer the programme is.
 Negative scores are VERY BAD!

112
Quality criteria - example
Documentation Quality All Documents Accurate Desk Check Work Products shall be accurate in content, presentation, technical content, and adherence to accepted elements of style. Various
Clear Desk Check Work Products shall be clear, concise and well structured. Any/All diagrams and graphics shall be easy to understand and be
relevant to the supporting narrative.
Various
Quality Plan Complete Desk Check Quality Goal/Attribute Coverage % PM
Test Plan Traceable Desk Check Consistent with Requirements and High Level Design PM
Complete Walkthrough Addresses all aspects of Testing as set out in Project Test Plan Test Lead
Test Reports Complete Desk Check All testing covered, pass/failure rates and defects raised must be reported at the end of a test pass. PM
Release Notes Traceable Testing All defects addressed in a particular release must be listed and outstanding known issues must be clearly spelled out! Test Lead
Timely Desk Check Must be received along with an official release of code for Testing and/or Acceptance PM
Weekly Status Reports Format Desk Check The nature of the Development Status should incorporate earned value as a mechanism for reporting completeness. Test
Status should be provided showing number of Test Cases Planned, Documented, Executed and Passed or Failed. Defects
Status and details should also be available for Review. Visibility of Keane risks and issues should also be provided.
PM
Timely Desk Check Must be received on a weekly basis PM
All Guides and Manuals Understandable Walkthrough Content clear, understood and deemed acceptable by all relevant stakeholders Various
Complete Walkthrough Content addresses all requirements and functionality being delivered Various
Developers Guide Usable Walkthrough Content accepted by Architect(s) and Dev Responsible Stakeholders in Various
User Manual Usable User Acceptance Testing Manual as used by System Users during UAT deemed usable and fit for purpose. No TBDs or critical/major issues/defects
outstanding.
Various
System Administation
Manual
Usable Operations Acceptance Testing Manual as used by System Administrators during OAT deemed usable and fit for purpose. No TBDs or critical/major
issues/defects outstanding.
Various
Design Quality Screens Design Traceable Desk Check Consistent with Requirements BA
Usable Demonstration Mockups acceptable to Business Various
Database Design Traceable Desk Check Consistent with High Level Design Architect
Compliant with Standards Desk Check Adheres to MID Data Architect
Low Level Design (LLD) Traceable Desk Check Consistent with High Level Design Architect
Clear Walkthrough Design accepted by Architect(s) and Dev Responsible Stakeholders in Various
Product (Code) Quality Application/System Compliant with Standards Code Reviews Adheres to Coding Standards Architect/ Dev
Traceable Code Reviews Consistent with Low Level Design Architect
Understandable Code Counting Tool Internal Documentation, e.g. Comments at acceptable % of Code PM/Architect
Code Reviews JavaDoc's exist and are complete for all Java Code PM/Architect
Code Counting Tool Code Complexity determined based on Average McCabe Metric per Function (Cyclomatic Complexity Number) at
acceptable level
PM/Architect
Testable Site Acceptance Testing Code can be built and deployed on Test Environment and will run without blocking defects. Test Lead
Reliable Performance Testing Defect Counts and Severities (specific to Performance) at an acceptable level Test Lead
Usable Demonstration Defect Counts and Severities arising out of Screen Reviews (per Iteration) at an acceptable level Various
User Acceptance Testing Defect Counts and Severities arising from UAT at an acceptable level Business
Stakeholders
Functional Testing (all Phases) Defect Counts and Severities at acceptable (and declining) levels Test Lead
Installation "Kit" Complete Code Reviews Process/Mechanisms delivered as outlined in Low Level Design Architect
Usable Site Acceptance Testing Defect Counts and Severities at an acceptable level Test Lead
Database Setup Scripts Complete Code Reviews Process/Mechanisms delivered as outlined in Low Level Design Data Architect
Usable Site Acceptance Testing Defect Counts and Severities at an acceptable level Test Lead
Sample Templates Clear Code Reviews Content accepted by Architect(s) and Dev Responsible Stakeholders in Various
Test Quality Unit Tests Complete Coverage Tracking Tool Code Coverage % arising from automated Unit Test using Junit at an acceptable level PM/Architect
System Test Objectives Traceable Desk Check Consistent with Requirements and Functionality to be delivered Test Lead
Complete Walkthrough All functionality covered Test Lead
System Test Cases Traceable Desk Check Consistent with Requirements and Functionality to be delivered Test Lead
Complete Walkthrough Functional Coverage % (Positive/Negative/Boundary) Test Lead
Reportable Desk Check Mechanisms mus be place via Weekly Status Reports to facilitate reporting of Test Cases Status (i.e. numbers Planned,
Documented, Executed, Passed/Failed)
PM

113
Timetable
Day 1Day 1 Day 2Day 2
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
Introductions
Leadership Scenarios
What is a Programme?
Apollo 13
Spiders Web Exercise
LUNCH
Managing the levers of
RISK
Management
vs
Leadership
Team Drinks
Q&A
Creating a high
performing
ORGANISATION
Q&A
Day 3Day 3
Paper Tower Exercise
Managing the CLIENT
Business Case
Managing the CLIENT
Requirements
Programme Pitfalls and
Assurance
NineDimensions approach
to Programme Process
Q&A

Leading Successful Programmes (LSP) v2.8

More Related Content

What's hot

Viewers also liked

Similar to Leading Successful Programmes (LSP) v2.8

Recently uploaded

Leading Successful Programmes (LSP) v2.8