Post on 28-Nov-2014
description
transcript
Programme Leadership Course
Version 2.6
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 Programme?
The bus of success carries many passengers, but the bicycle of failure is a vehicle made for one
--Stuart Robb 2001
The bus of success carries many passengers, but the bicycle of failure is a vehicle made for one
--Stuart Robb 2001
4Copyright © Maddison Ward 2006
What is a Programme?
What is a programme
What are the characteristics of a programme?
How does this differ from a project?
Does “size” matter?
What is the difference between a “project” and a “workstream / workpackage”?
What makes a programme “successful”?
5Copyright © 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)
6Copyright © Maddison Ward 2006
What is leadership
Origins of leadership
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!
7Copyright © Maddison Ward 2006
Attributes of leadership
Upbringing
Uprising / Events
Vision (Outcome)
Motivation (Passion)
Mobilisation (Team-building)
Tenaciousness (Decisiveness)
CHARISMA
8Copyright © Maddison Ward 2006
Examples of great leaders
Alexander the Great
Boudica, Queen of the Iceni
Napoleon Bonaparte
Admiral Lord Nelson
Mohandas Ghandi
Adolf Hitler
Winston Churchill
John F Kennedy
Margaret Thatcher
After a great height, comes a great fall!
CONDISER: 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.
9Copyright © 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?
10Copyright © 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?
11Copyright © 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 Charismar?
12Copyright © Maddison Ward 2006
Power
What is power? Why is it important?
How do you get power? Are you “given power”?
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)
Power under (given)
Power sharing (consensus)
Can you deliver a programme without Power?
13Copyright © Maddison Ward 2006
Leadership style
If you use consensus 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
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”
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 with the “prom queen” – Sean Connery (The Rock)
14Copyright © 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
15Copyright © 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
16Copyright © Maddison Ward 2006
Using psychology to lead
Have empathy with the client & the organisation
I understand and acknowledge your point of view, but...
Have you thought of... Might it be possible to...
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)
17Copyright © 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 programme management and not in project management
Consider about the following statement.
Managers manage tasks?
Leaders manage people?
18Copyright © Maddison Ward 2006
Common scenarios
The following are very common for programme managers coming onto a new programme. What do you do about them?
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
19Copyright © 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...
20Copyright © 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?
Copyright Maddison Ward 2006
Programme Dimensions
Every obstacle yields to stern resolve.--Leonardo da Vinci
Every obstacle yields to stern resolve.--Leonardo da Vinci
22Copyright © Maddison Ward 2006
Programme Dimensions
Risk - likelihood of a successful outcome
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
ORGANISATION PROCESS
RISK
OUTCOME
Copyright Maddison Ward 2006
Managing the levers of RISK
24Copyright © Maddison Ward 2006
Page 24
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
25Copyright © Maddison Ward 2006
Page 25
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
Cost Reduction Levers
26Copyright © Maddison Ward 2006
Page 26
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
Cost Reduction Levers
27Copyright © Maddison Ward 2006
Page 27
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
Cost Reduction Levers
28Copyright © Maddison Ward 2006
Quality is key!
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!
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
30Copyright © Maddison Ward 2006
Creating a high-performing ORGANISATION
Types of organisation
Matrix Management / Competency pools
Organisational cohesion & communications
Organisational performance
31Copyright © 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
32Copyright © 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”?
33Copyright © 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
34Copyright © 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
35Copyright © 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?
36Copyright © Maddison Ward 2006
Organisational cohesion
Example of a programme booklet
37Copyright © 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)
38Copyright © 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!!!!
39Copyright © 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
41Copyright © 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
42Copyright © Maddison Ward 2006
Managing the a difficult client
What kind of influencing styles can one deploy against a difficult client
Managing expectation
Copyright Maddison Ward 2006
Managing the Client
THE BUSINESS CASE
44Copyright © Maddison Ward 2006
Why is a business case important
It answers the question for the client “Why am I doing this”
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.
45Copyright © 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
46Copyright © 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 & Appendicies
47Copyright © 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?
48Copyright © 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.
49Copyright © Maddison Ward 2006
Business Case Levers
Is the business case “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!
Copyright Maddison Ward 2006
Managing the Client
THE REQUIREMENTS
51Copyright © Maddison Ward 2006
What are requirements
They are what the client “wants you to deliver”
They are unambiguous statements of 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.
52Copyright © 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
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!
53Copyright © Maddison Ward 2006
Requirements pitfalls
Be careful of the distinction between a “BUSINESS REQUIREMENT” and an IT FUNCTIONAL 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.
54Copyright © 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
55Copyright © 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
– In addition to the regular vehicle gauges, the car must have a differential temperature gauge, a gearbox oil temperature gauge and a tilt meter.
– 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!
Copyright Maddison Ward 2006
Managing the Client
THE COMMERCIALS
57Copyright © 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!
58Copyright © 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!
59Copyright © Maddison Ward 2006
COMMERCIALS GOLDEN RULES
If you MEASURE the wrong things, you create the wrong BEHAVIOURS which leads to the wrong OUTCOMES
Software fix process example
CHEAPEST ISN’T ALWAYS BEST
Copyright Maddison Ward 2006
Managing a programme’s PROCESSES
NineDimensions approach
61Copyright © 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
62Copyright © Maddison Ward 2006
Processes and controls
There should be no need to describe how to fill out a load of forms/logs for Programme control. There are plenty of courses (MSP/Prince courses) that can teach you that!
There’s a spreadsheet included with the pack that has a RAID log that has everything I’ve ever needed to run a programme.
If you don’t know what your status is, you don’t know whether you’re going to be successful
Misreporting work as complete when it isn’t is a FIRING offence.
63Copyright © 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)
64Copyright © 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
65Copyright © 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
67Copyright © 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 managing a 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
68Copyright © 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
69Copyright © 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
70Copyright © 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
71Copyright © 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
73Copyright © 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”
74Copyright © 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
75Copyright © 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
MADDISON WARD LIMITED