76
Programme Leadership Course Version 2.6 February 2009 Leading Successful Programmes

Maddison Ward Leading Successful Programmes Public

Embed Size (px)

DESCRIPTION

LEADING SUCCESSFUL PROGRAMMES - as I don\'t need this any more, I thought I\'d share it.

Citation preview

Page 1: Maddison Ward Leading Successful Programmes Public

Programme Leadership Course

Version 2.6

February 2009

Leading Successful Programmes

Page 2: Maddison Ward Leading Successful Programmes Public

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

Page 3: Maddison Ward Leading Successful Programmes Public

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

Page 4: Maddison Ward Leading Successful Programmes Public

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”?

Page 5: Maddison Ward Leading Successful Programmes Public

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)

Page 6: Maddison Ward Leading Successful Programmes Public

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!

Page 7: Maddison Ward Leading Successful Programmes Public

7Copyright © Maddison Ward 2006

Attributes of leadership

Upbringing

Uprising / Events

Vision (Outcome)

Motivation (Passion)

Mobilisation (Team-building)

Tenaciousness (Decisiveness)

CHARISMA

Page 8: Maddison Ward Leading Successful Programmes Public

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.

Page 9: Maddison Ward Leading Successful Programmes Public

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?

Page 10: Maddison Ward Leading Successful Programmes Public

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?

Page 11: Maddison Ward Leading Successful Programmes Public

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?

Page 12: Maddison Ward Leading Successful Programmes Public

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?

Page 13: Maddison Ward Leading Successful Programmes Public

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)

Page 14: Maddison Ward Leading Successful Programmes Public

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

Page 15: Maddison Ward Leading Successful Programmes Public

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

Page 16: Maddison Ward Leading Successful Programmes Public

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)

Page 17: Maddison Ward Leading Successful Programmes Public

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?

Page 18: Maddison Ward Leading Successful Programmes Public

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

Page 19: Maddison Ward Leading Successful Programmes Public

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...

Page 20: Maddison Ward Leading Successful Programmes Public

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?

Page 21: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Programme Dimensions

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

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

Page 22: Maddison Ward Leading Successful Programmes Public

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

Page 23: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Managing the levers of RISK

Page 24: Maddison Ward Leading Successful Programmes Public

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

Page 25: Maddison Ward Leading Successful Programmes Public

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

Page 26: Maddison Ward Leading Successful Programmes Public

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

Page 27: Maddison Ward Leading Successful Programmes Public

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

Page 28: Maddison Ward Leading Successful Programmes Public

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!

Page 29: Maddison Ward Leading Successful Programmes Public

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

Page 30: Maddison Ward Leading Successful Programmes Public

30Copyright © Maddison Ward 2006

Creating a high-performing ORGANISATION

Types of organisation

Matrix Management / Competency pools

Organisational cohesion & communications

Organisational performance

Page 31: Maddison Ward Leading Successful Programmes Public

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

Page 32: Maddison Ward Leading Successful Programmes Public

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”?

Page 33: Maddison Ward Leading Successful Programmes Public

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

Page 34: Maddison Ward Leading Successful Programmes Public

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

Page 35: Maddison Ward Leading Successful Programmes Public

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?

Page 36: Maddison Ward Leading Successful Programmes Public

36Copyright © Maddison Ward 2006

Organisational cohesion

Example of a programme booklet

Page 37: Maddison Ward Leading Successful Programmes Public

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)

Page 38: Maddison Ward Leading Successful Programmes Public

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!!!!

Page 39: Maddison Ward Leading Successful Programmes Public

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).

Page 40: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Managing the Client

Page 41: Maddison Ward Leading Successful Programmes Public

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

Page 42: Maddison Ward Leading Successful Programmes Public

42Copyright © Maddison Ward 2006

Managing the a difficult client

What kind of influencing styles can one deploy against a difficult client

Managing expectation

Page 43: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Managing the Client

THE BUSINESS CASE

Page 44: Maddison Ward Leading Successful Programmes Public

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.

Page 45: Maddison Ward Leading Successful Programmes Public

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

Page 46: Maddison Ward Leading Successful Programmes Public

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

Page 47: Maddison Ward Leading Successful Programmes Public

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?

Page 48: Maddison Ward Leading Successful Programmes Public

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.

Page 49: Maddison Ward Leading Successful Programmes Public

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!

Page 50: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Managing the Client

THE REQUIREMENTS

Page 51: Maddison Ward Leading Successful Programmes Public

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.

Page 52: Maddison Ward Leading Successful Programmes Public

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!

Page 53: Maddison Ward Leading Successful Programmes Public

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.

Page 54: Maddison Ward Leading Successful Programmes Public

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

Page 55: Maddison Ward Leading Successful Programmes Public

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!

Page 56: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Managing the Client

THE COMMERCIALS

Page 57: Maddison Ward Leading Successful Programmes Public

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!

Page 58: Maddison Ward Leading Successful Programmes Public

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!

Page 59: Maddison Ward Leading Successful Programmes Public

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

Page 60: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Managing a programme’s PROCESSES

NineDimensions approach

Page 61: Maddison Ward Leading Successful Programmes Public

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

Page 62: Maddison Ward Leading Successful Programmes Public

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.

Page 63: Maddison Ward Leading Successful Programmes Public

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)

Page 64: Maddison Ward Leading Successful Programmes Public

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

Page 65: Maddison Ward Leading Successful Programmes Public

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.

Page 66: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Managing a programme’s PROCESSES

A successful PMO

Page 67: Maddison Ward Leading Successful Programmes Public

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

Page 68: Maddison Ward Leading Successful Programmes Public

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

Page 69: Maddison Ward Leading Successful Programmes Public

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

Page 70: Maddison Ward Leading Successful Programmes Public

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

Page 71: Maddison Ward Leading Successful Programmes Public

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

Page 72: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

Programme Pitfalls and Assurance

Page 73: Maddison Ward Leading Successful Programmes Public

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”

Page 74: Maddison Ward Leading Successful Programmes Public

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

Page 75: Maddison Ward Leading Successful Programmes Public

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!

Page 76: Maddison Ward Leading Successful Programmes Public

Copyright Maddison Ward 2006

MADDISON WARD LIMITED