leading successful programmes (lsp) v2.8
DESCRIPTION
TRANSCRIPT
Programme Leadership Course
Version 2.7
February 2009
Leading Successful Programmes
2Copyright © 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
4Copyright © Maddison Ward 2006
What is a Project or Programme?
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”?
5Copyright © Maddison Ward 2006
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?
6Copyright © Maddison Ward 2006
What is a Project or Programme?
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?
7Copyright © Maddison Ward 2006
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
8Copyright © Maddison Ward 2006
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
9Copyright © Maddison Ward 2006
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!
10Copyright © Maddison Ward 2006
What makes a programme successful?
PROCESS
PEOPLE
TECHNOLOGY
CollateralKnowledgeProcedures
ForumsTerms of ReferenceDirectory Structures
Project FoldersSignoffs/Acceptances
CultureBehavioursLeadershipTrainingIncentives/RewardPeer ReviewsMonitoringEnvironment
Milestone ManagementRisk/Issue ManagementPortfolio ManagementFinancial ManagementResource Management
Knowledge ManagementConfiguration Management
Microsoft ProjectRAID Logs (Excel/MS Access)
Timesheeting (Clarity) GOOD PROCESSES
are no substitute for
GREAT LEADERSHIP
11Copyright © Maddison Ward 2006
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?
12Copyright © Maddison Ward 2006
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!
13Copyright © Maddison Ward 2006
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
14Copyright © Maddison Ward 2006
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
15Copyright © Maddison Ward 2006
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.
16Copyright © Maddison Ward 2006
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!
17Copyright © Maddison Ward 2006
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?
18Copyright © Maddison Ward 2006
Empathy
Gravitas
What makes up leadership attributes?
Charisma
POWER
Respect
OpennessApproachability
EnthusiasmEmpathy
Body language
RewardCoersionReferentLegitimateExpert
Lead by exampleInfluence positively
Be InclusiveBe factual / knowledgable
Be humanBe honest
Body Language AUTHORITY
In what proportion do these need to be to make a great leader?
How would you rate yourself?
VirtueDignity
IntegritySolemnity
SeriousnessSubstance
Purpose
VisionDrive
MotivationRelentlessnessDecisiveness
19Copyright © Maddison Ward 2006
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?
20Copyright © Maddison Ward 2006
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.
21Copyright © Maddison Ward 2006
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?
22Copyright © Maddison Ward 2006
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
23Copyright © Maddison Ward 2006
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).
24Copyright © Maddison Ward 2006
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
25Copyright © Maddison Ward 2006
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
26Copyright © Maddison Ward 2006
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?
27Copyright © Maddison Ward 2006
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)
28Copyright © Maddison Ward 2006
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
29Copyright © Maddison Ward 2006
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
30Copyright © Maddison Ward 2006
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)
31Copyright © Maddison Ward 2006
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…
32Copyright © Maddison Ward 2006
Leadership Example
Apollo 13...
Gene Krantz established a “tiger team”
What leadership characteristics did Gene demonstrate during the Apollo 13 crisis?
33Copyright © Maddison Ward 2006
Leadership Example
Downfall...
Hitler lost control as a leader...
What characterises Hitler’s style that lost the confidence of those around him?
34Copyright © Maddison Ward 2006
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?
35Copyright © Maddison Ward 2006
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...
36Copyright © Maddison Ward 2006
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?
37Copyright © Maddison Ward 2006
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?
Copyright Maddison Ward 2006
Questions / Review of the day
39Copyright © Maddison Ward 2006
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
Copyright Maddison Ward 2006
Programme Dimensions
Every obstacle yields to stern resolve.--Leonardo da Vinci
Every obstacle yields to stern resolve.--Leonardo da Vinci
41Copyright © Maddison Ward 2006
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
42Copyright © Maddison Ward 2006
Four Essential Disciplines of Portfolio Management
Plan Management
ResourceManagement
FinancialManagement
Prioritised initiativesProject EstimationInter-dependencies
Are we doing the right thing, at the right time, in the right order
to maximise business value?
Resource (talent) poolBAU baselineProject Plans
Do we have sufficient people,with the right skills,
available at the right time
BudgetBusiness casesProject costings
Can we afford it anddoes it make us any money?
ChangeManagement
Project PlansChange Impact Map
Training Needs AnalysisStakeholder 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)
PER
FEC
T V
IEW
Copyright Maddison Ward 2006
Managing the levers of RISK
44Copyright © Maddison Ward 2006
Page 44
Programme Dimensions
REDUCE SCOPE
INCREASE BUDGET
INCREASE TIMELOWER QUALITY
INCREASE SCOPE
REDUCE BUDGET
REDUCE TIMEINCREASE QUALITYRISK
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
45Copyright © Maddison Ward 2006
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
46Copyright © Maddison Ward 2006
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
Lower Infrastructure Capital/Maintenance
Costs (Test)
Reduce Parallel Activities
Lower Infratructure Build/Support Costs (Test)
Reduce Management Overhead Costs
Lower Infrastructure Capital/Main Costs (Test)
Not all functionality delivered
Lower Infrastructure Build/Support Costs (Test)
Reduced Resource Costs for Complex Integration
47Copyright © Maddison Ward 2006
Page 47
Reducing quality results in...
QUALITY
Reduce Code QualityHigher Defect Rates & Re-
work (increasing Development costs)
Faster Coding Time (potential lower resource
costs)
Undertake Less Testing
Lower Infratructure Build/Support Costs (Test)
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
Lower Infrastructure 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
48Copyright © Maddison Ward 2006
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
Copyright Maddison Ward 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
50Copyright © Maddison Ward 2006
Creating a high-performing ORGANISATION
Types of organisation
Matrix Management / Competency pools
Organisational cohesion & communications
Organisational performance
51Copyright © Maddison Ward 2006
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
52Copyright © Maddison Ward 2006
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”?
53Copyright © Maddison Ward 2006
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
54Copyright © Maddison Ward 2006
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
55Copyright © Maddison Ward 2006
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?
56Copyright © Maddison Ward 2006
Organisational cohesion
Example of a programme booklet
57Copyright © Maddison Ward 2006
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)
58Copyright © Maddison Ward 2006
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!!!!
59Copyright © Maddison Ward 2006
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).
Copyright Maddison Ward 2006
Managing the Client
61Copyright © Maddison Ward 2006
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
62Copyright © Maddison Ward 2006
Managing the a difficult client
What kind of influencing styles can one deploy against a difficult client
Managing expectations
Copyright Maddison Ward 2006
Managing the Client
THE BUSINESS CASE
64Copyright © Maddison Ward 2006
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
65Copyright © Maddison Ward 2006
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
66Copyright © Maddison Ward 2006
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.
67Copyright © Maddison Ward 2006
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?
68Copyright © Maddison Ward 2006
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
69Copyright © Maddison Ward 2006
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
70Copyright © Maddison Ward 2006
What is a benefit?
Tangible Intangible
Fin
an
cia
lN
on
-fin
an
cia
l
Reduction in costsAccommodation savingsBetter cash management
Increased revenueIncreased contribution
Better quality of serviceImprovement to KPI targets
inc. CSILower staff turnover
Fewer customer complaints Improved productivity eg AHT
Lower customer churn
Increased people morale (Reflect)Corporate ‘image’
Better access to informationImproved processes
Increased competitivenessAccess to markets
Regulatory requirement
Based on Deloitte ‘Types of benefits’
71Copyright © Maddison Ward 2006
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?
72Copyright © Maddison Ward 2006
Business Case Levers
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.
73Copyright © Maddison Ward 2006
Business Case Levers
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!
74Copyright © Maddison Ward 2006
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.
75Copyright © Maddison Ward 2006
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.
76Copyright © Maddison Ward 2006
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?
77Copyright © Maddison Ward 2006
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?
78Copyright © Maddison Ward 2006
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!
Copyright Maddison Ward 2006
Managing the Client
THE REQUIREMENTS
80Copyright © Maddison Ward 2006
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.
81Copyright © Maddison Ward 2006
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!
82Copyright © Maddison Ward 2006
Requirements pitfalls
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.
83Copyright © Maddison Ward 2006
What are the “types” of requirements
Business SME input
Business Driver
Research
Industry Best Practice
Customer Experience Lifecycle
CustomerExperienceDefinition
Business Model
BusinessCase
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
SystemsRequirements
“PEOPLE”
“PROCESS”
“TECHNOLOGY”
Organisational Requirements
Systems Functional RequirementsBusiness Requirements Specification
PrioritisedInitiatives
Traditional waterfall “requirements” breakdown – process led
84Copyright © Maddison Ward 2006
Business Requirements
85Copyright © Maddison Ward 2006
System Functional Requirements
“like”???? “etc”?????
86Copyright © Maddison Ward 2006
Requirements pitfalls
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!
87Copyright © Maddison Ward 2006
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
Copyright Maddison Ward 2006
Managing the Client
THE COMMERCIALS
89Copyright © Maddison Ward 2006
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!
90Copyright © Maddison Ward 2006
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!
91Copyright © Maddison Ward 2006
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”
Copyright Maddison Ward 2006
Deriving the plan
How do you arrive at a release schedule & plan
93Copyright © Maddison Ward 2006
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!
94Copyright © Maddison Ward 2006
Managing the Processes
The NineDimensions Approach
RAID Management
Change Management
Financial Management
Status Management
Deliverables Management
Planning & Estimating
Resource Management
Quality & Governance
Stakeholder Management
95Copyright © Maddison Ward 2006
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)
96Copyright © Maddison Ward 2006
Work-package Descriptions
What should be in a WDP?
Should be completed by the person responsiblefor performing the workand 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
97Copyright © Maddison Ward 2006
Work-package Descriptions
Example set of programme workstreams & work-packages
LLD-I-P-WPProgramme
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-F11SOC Autodeploy
UAT
LLD-I-A01Offer Strategy
LLD-I-C01KPI Reporting
LLD-I-T01AsIs
Test Process
LLD-I-CS01Outbound UAT
LLD-I-D01UAT
LLD-I-F12XS/US Campaign
5 Free MMS
LLD-I-A02Campaign
Offer Schedule
LLD-I-C02Process
Measures
LLD-I-T02Quick Wins
LLD-I-CS002Pilot (Phase 1)
LLD-I-D02Pilot
LLD-I-F13Data Xfer£49.98
LLD-I-A03Campaign &
Offers for IndirectLLD-I-C03
BPCU Capability
LLD-I-T03BAU Test
Process (Interim)
LLD-I-CS03Rollout (Phase 1)
LLD-I-D03Rollout
LLD-I-F14Campaigns
for Direct
LLD-I-A04Resource Transition
LLD-I-C04Business Case
(Full)
LLD-I-T04Long-TermTest Reqts
LLD-I-I01UAT
LLD-I-F15BPCU Campaigns
LLD-I-A05Campaign
Reporting Reqts
LLD-I-C06Change Mgt
ReviewLLD-I-I02
Front3 Launch
LLD-I-F16XS/US Campaign
Web & WalkLLD-I-A06Processes
LLD-I-C06Review Exit /
Completion Criteria
LLD-I-I03Carphone
Deployment
LLD-I-A07SOC Change
Process
LLD-I-C07Facilitate
Channel Launch
LLD-I-I04Channel
Implementation
LLD-I-A08Handset Mgt
ProcessLLD-I-C08
Business Review
LLD-I-A09Interim OMSE
Solution
LLD-I-A10Housekeeping
LLD-I-F-WP
FIX
LLD-I-F01Campaign Design
Review
LLD-I-F02XS/US CampaignItemised Billing
LLD-I-F03CAP Rule Change
LLD-I-F04BIS Preparation
LLD-I-F05Outbound Campaign
LLD-I-F06WebReg/Domino
Defects
LLD-I-F07SAS ModelPrioritisation
LLD-I-F08VAT Solution
LLD-I-F09£90 Subsidy
LLD-I-F10Belnded
Definition Soln
LLD-I-A11MarketingReporting
LLD-I-A12OMSE / SAP
Pricing
LLD-I-T00TestCTNs
LLD-I-F17INFO Campaign
Direct Debit
LLD-I-F18INFO Campaign
First Call Resolution
LLD-I-F19Business Support
LLD-I-F20End2End Testing
Of ALL fixes
LLD-I-A13Campaigns for
CS Outbound UAT
LLD-I-A14CCOS Bible
LLD-I-A15Campaigns for CS Renewals
LLD-I-CS04Outbound
CAP Rule UAT
LLD-I-CS05OutsourcerDeployment
LLD-I-CS006Pilot (Renewals)
LLD-I-CS07Rollout (Renewals)
LLD-I-P-WPProgramme
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-F11SOC Autodeploy
UAT
LLD-I-A01Offer Strategy
LLD-I-C01KPI Reporting
LLD-I-T01AsIs
Test Process
LLD-I-CS01Outbound UAT
LLD-I-D01UAT
LLD-I-F12XS/US Campaign
5 Free MMS
LLD-I-A02Campaign
Offer Schedule
LLD-I-C02Process
Measures
LLD-I-T02Quick Wins
LLD-I-CS002Pilot (Phase 1)
LLD-I-D02Pilot
LLD-I-F13Data Xfer£49.98
LLD-I-A03Campaign &
Offers for IndirectLLD-I-C03
BPCU Capability
LLD-I-T03BAU Test
Process (Interim)
LLD-I-CS03Rollout (Phase 1)
LLD-I-D03Rollout
LLD-I-F14Campaigns
for Direct
LLD-I-A04Resource Transition
LLD-I-C04Business Case
(Full)
LLD-I-T04Long-TermTest Reqts
LLD-I-I01UAT
LLD-I-F15BPCU Campaigns
LLD-I-A05Campaign
Reporting Reqts
LLD-I-C06Change Mgt
ReviewLLD-I-I02
Front3 Launch
LLD-I-F16XS/US Campaign
Web & WalkLLD-I-A06Processes
LLD-I-C06Review Exit /
Completion Criteria
LLD-I-I03Carphone
Deployment
LLD-I-A07SOC Change
Process
LLD-I-C07Facilitate
Channel Launch
LLD-I-I04Channel
Implementation
LLD-I-A08Handset Mgt
ProcessLLD-I-C08
Business Review
LLD-I-A09Interim OMSE
Solution
LLD-I-A10Housekeeping
LLD-I-F-WP
FIX
LLD-I-F01Campaign Design
Review
LLD-I-F02XS/US CampaignItemised Billing
LLD-I-F03CAP Rule Change
LLD-I-F04BIS Preparation
LLD-I-F05Outbound Campaign
LLD-I-F06WebReg/Domino
Defects
LLD-I-F07SAS ModelPrioritisation
LLD-I-F08VAT Solution
LLD-I-F09£90 Subsidy
LLD-I-F10Belnded
Definition Soln
LLD-I-A11MarketingReporting
LLD-I-A12OMSE / SAP
Pricing
LLD-I-T00TestCTNs
LLD-I-F17INFO Campaign
Direct Debit
LLD-I-F18INFO Campaign
First Call Resolution
LLD-I-F19Business Support
LLD-I-F20End2End Testing
Of ALL fixes
LLD-I-A13Campaigns for
CS Outbound UAT
LLD-I-A14CCOS Bible
LLD-I-A15Campaigns for CS Renewals
LLD-I-CS04Outbound
CAP Rule UAT
LLD-I-CS05OutsourcerDeployment
LLD-I-CS006Pilot (Renewals)
LLD-I-CS07Rollout (Renewals)
98Copyright © Maddison Ward 2006
Work-package Dependencies
98
LLD-I-A01Offer Strategy
LLD-I-C01KPI Reporting
LLD-I-T01AsIs
Test Process
LLD-I-CS06Outbound UAT
LLD-I-A02Campaign
Offer Schedule
LLD-I-C02Process
Measures
LLD-I-A03Campaign &
Offers for Indirect
LLD-I-T03BAU Test
Process (Interim)
LLD-I-A04Resource Transition
LLD-I-C04Business Case
(Full)
LLD-I-T04Long-TermTest Reqts
LLD-I-I01UAT
LLD-I-A05Campaign
Reporting Solution
LLD-I-C06Change Mgt
Review
LLD-I-I02Front3 Launch
LLD-I-A06Processes
LLD-I-C06Review Exit /
Completion Criteria
LLD-I-I03Carphone
Deployment
LLD-I-A07SOC Change
Process
LLD-I-C07Facilitate
Channel Launch
LLD-I-I04Channel
Implementation
LLD-I-A08Handset Mgt
Process
LLD-I-A09Interim OMSE
Solution
LLD-I-A10Housekeeping
LLD-I-A11MarketingReporting
LLD-I-A12OMSE / SAP
Pricing
LLD-I-A13Campaigns for
CS Outbound UAT
LLD-I-A14CCOS Bible
LLD-I-A15Campaigns for CS Renewals
LLD-I-CS07Outbound
Rollout
LLD-I-CS09Pilot (Renewals)
LLD-I-CS10Rollout (Renewals)
LLD-I-A16End2End Test
A
B
LLD-I-CS08Renewals UAT
C
LLD-I-F06WebReg/Domino
Defects
LLD-I-D02Pilot
31/2/07 3/4/07 28/5/07 30/7/07
LLD-I-T05Interim TestEnvironment
LLD-I-A17Outbound PRP
This is whereMicrosoft Project can
really help – use itto manage & track
dependenciesbetween
work-packages &identify the critical
path
99Copyright © Maddison Ward 2006
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?
100Copyright © Maddison Ward 2006
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.
Copyright Maddison Ward 2006
Managing a programme’s PROCESSES
A successful PMO
102Copyright © Maddison Ward 2006
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
103Copyright © Maddison Ward 2006
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
104Copyright © Maddison Ward 2006
Programme Management Office Organisation & Activities
Programme Office
Manager
Programme Communicatio
nsAnalyst
Programme Quality
Assurance
ProgrammeControllerFinancial Analyst
Programme ControllerResources
Programme Controller
Plan
Programme Administrator
ProgrammeController
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
105Copyright © Maddison Ward 2006
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
106Copyright © Maddison Ward 2006
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 weeks6 weeks
1 day1 day
10 days2 weeks2 weeks2 weeks1 weeks
1 day2 days1 day1 day7 days1 day
100 years10 daysNever
-
tbctbc
Request
SLA Primary Contact
Copyright Maddison Ward 2006
Programme Pitfalls and Assurance
108Copyright © Maddison Ward 2006
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”
109Copyright © Maddison Ward 2006
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
110Copyright © Maddison Ward 2006
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!
Copyright Maddison Ward 2006
Questions / Review of the day
112Copyright © Maddison Ward 2006
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 % PMTest 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 LeadTest 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 PMWeekly 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 PMAll 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 VariousDevelopers Guide Usable Walkthrough Content accepted by Architect(s) and Dev Responsible Stakeholders in VariousUser 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 BAUsable Demonstration Mockups acceptable to Business Various
Database Design Traceable Desk Check Consistent with High Level Design ArchitectCompliant with Standards Desk Check Adheres to MID Data Architect
Low Level Design (LLD) Traceable Desk Check Consistent with High Level Design ArchitectClear 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/ DevTraceable Code Reviews Consistent with Low Level Design ArchitectUnderstandable 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/ArchitectCode Counting Tool Code Complexity determined based on Average McCabe Metric per Function (Cyclomatic Complexity Number) at
acceptable levelPM/Architect
Testable Site Acceptance Testing Code can be built and deployed on Test Environment and will run without blocking defects. Test LeadReliable Performance Testing Defect Counts and Severities (specific to Performance) at an acceptable level Test LeadUsable 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 LeadInstallation "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 LeadDatabase 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 LeadSample 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/ArchitectSystem Test Objectives Traceable Desk Check Consistent with Requirements and Functionality to be delivered Test Lead
Complete Walkthrough All functionality covered Test LeadSystem Test Cases Traceable Desk Check Consistent with Requirements and Functionality to be delivered Test Lead
Complete Walkthrough Functional Coverage % (Positive/Negative/Boundary) Test LeadReportable 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
113Copyright © Maddison Ward 2006
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 CLIENTBusiness Case
Managing the CLIENTRequirements
Programme Pitfalls and Assurance
NineDimensions approach to Programme Process
Q&A