Leading Successful Programmes (LSP) v2.8

113
Programme Leadership Course Version 2.7 February 2009 Leading Successful Programmes

description

 

Transcript of Leading Successful Programmes (LSP) v2.8

Page 1: Leading Successful Programmes (LSP) v2.8

Programme Leadership Course

Version 2.7

February 2009

Leading Successful Programmes

Page 2: Leading Successful Programmes (LSP) v2.8

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: Leading Successful Programmes (LSP) v2.8

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

Page 4: Leading Successful Programmes (LSP) v2.8

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

Page 5: Leading Successful Programmes (LSP) v2.8

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?

Page 6: Leading Successful Programmes (LSP) v2.8

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?

Page 7: Leading Successful Programmes (LSP) v2.8

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

Page 8: Leading Successful Programmes (LSP) v2.8

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

Page 9: Leading Successful Programmes (LSP) v2.8

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!

Page 10: Leading Successful Programmes (LSP) v2.8

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

Page 11: Leading Successful Programmes (LSP) v2.8

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?

Page 12: Leading Successful Programmes (LSP) v2.8

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!

Page 13: Leading Successful Programmes (LSP) v2.8

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

Page 14: Leading Successful Programmes (LSP) v2.8

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

Page 15: Leading Successful Programmes (LSP) v2.8

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.

Page 16: Leading Successful Programmes (LSP) v2.8

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!

Page 17: Leading Successful Programmes (LSP) v2.8

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?

Page 18: Leading Successful Programmes (LSP) v2.8

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

Page 19: Leading Successful Programmes (LSP) v2.8

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?

Page 20: Leading Successful Programmes (LSP) v2.8

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.

Page 21: Leading Successful Programmes (LSP) v2.8

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?

Page 22: Leading Successful Programmes (LSP) v2.8

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

Page 23: Leading Successful Programmes (LSP) v2.8

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

Page 24: Leading Successful Programmes (LSP) v2.8

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

Page 25: Leading Successful Programmes (LSP) v2.8

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

Page 26: Leading Successful Programmes (LSP) v2.8

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?

Page 27: Leading Successful Programmes (LSP) v2.8

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)

Page 28: Leading Successful Programmes (LSP) v2.8

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

Page 29: Leading Successful Programmes (LSP) v2.8

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

Page 30: Leading Successful Programmes (LSP) v2.8

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)

Page 31: Leading Successful Programmes (LSP) v2.8

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…

Page 32: Leading Successful Programmes (LSP) v2.8

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?

Page 33: Leading Successful Programmes (LSP) v2.8

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?

Page 34: Leading Successful Programmes (LSP) v2.8

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?

Page 35: Leading Successful Programmes (LSP) v2.8

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

Page 36: Leading Successful Programmes (LSP) v2.8

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?

Page 37: Leading Successful Programmes (LSP) v2.8

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?

Page 38: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Questions / Review of the day

Page 39: Leading Successful Programmes (LSP) v2.8

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

Page 40: Leading Successful Programmes (LSP) v2.8

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 41: Leading Successful Programmes (LSP) v2.8

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

Page 42: Leading Successful Programmes (LSP) v2.8

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

Page 43: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Managing the levers of RISK

Page 44: Leading Successful Programmes (LSP) v2.8

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

Page 45: Leading Successful Programmes (LSP) v2.8

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

Page 46: Leading Successful Programmes (LSP) v2.8

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

Page 47: Leading Successful Programmes (LSP) v2.8

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

Page 48: Leading Successful Programmes (LSP) v2.8

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

Page 49: Leading Successful Programmes (LSP) v2.8

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 50: Leading Successful Programmes (LSP) v2.8

50Copyright © Maddison Ward 2006

Creating a high-performing ORGANISATION

Types of organisation

Matrix Management / Competency pools

Organisational cohesion & communications

Organisational performance

Page 51: Leading Successful Programmes (LSP) v2.8

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

Page 52: Leading Successful Programmes (LSP) v2.8

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

Page 53: Leading Successful Programmes (LSP) v2.8

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

Page 54: Leading Successful Programmes (LSP) v2.8

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

Page 55: Leading Successful Programmes (LSP) v2.8

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?

Page 56: Leading Successful Programmes (LSP) v2.8

56Copyright © Maddison Ward 2006

Organisational cohesion

Example of a programme booklet

Page 57: Leading Successful Programmes (LSP) v2.8

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)

Page 58: Leading Successful Programmes (LSP) v2.8

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

Page 59: Leading Successful Programmes (LSP) v2.8

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

Page 60: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Managing the Client

Page 61: Leading Successful Programmes (LSP) v2.8

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

Page 62: Leading Successful Programmes (LSP) v2.8

62Copyright © Maddison Ward 2006

Managing the a difficult client

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

Managing expectations

Page 63: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Managing the Client

THE BUSINESS CASE

Page 64: Leading Successful Programmes (LSP) v2.8

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

Page 65: Leading Successful Programmes (LSP) v2.8

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

Page 66: Leading Successful Programmes (LSP) v2.8

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.

Page 67: Leading Successful Programmes (LSP) v2.8

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?

Page 68: Leading Successful Programmes (LSP) v2.8

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

Page 69: Leading Successful Programmes (LSP) v2.8

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

Page 70: Leading Successful Programmes (LSP) v2.8

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’

Page 71: Leading Successful Programmes (LSP) v2.8

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?

Page 72: Leading Successful Programmes (LSP) v2.8

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.

Page 73: Leading Successful Programmes (LSP) v2.8

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!

Page 74: Leading Successful Programmes (LSP) v2.8

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.

Page 75: Leading Successful Programmes (LSP) v2.8

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.

Page 76: Leading Successful Programmes (LSP) v2.8

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?

Page 77: Leading Successful Programmes (LSP) v2.8

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?

Page 78: Leading Successful Programmes (LSP) v2.8

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!

Page 79: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Managing the Client

THE REQUIREMENTS

Page 80: Leading Successful Programmes (LSP) v2.8

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.

Page 81: Leading Successful Programmes (LSP) v2.8

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!

Page 82: Leading Successful Programmes (LSP) v2.8

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.

Page 83: Leading Successful Programmes (LSP) v2.8

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

Page 84: Leading Successful Programmes (LSP) v2.8

84Copyright © Maddison Ward 2006

Business Requirements

Page 85: Leading Successful Programmes (LSP) v2.8

85Copyright © Maddison Ward 2006

System Functional Requirements

“like”???? “etc”?????

Page 86: Leading Successful Programmes (LSP) v2.8

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!

Page 87: Leading Successful Programmes (LSP) v2.8

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

Page 88: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Managing the Client

THE COMMERCIALS

Page 89: Leading Successful Programmes (LSP) v2.8

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!

Page 90: Leading Successful Programmes (LSP) v2.8

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!

Page 91: Leading Successful Programmes (LSP) v2.8

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”

Page 92: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Deriving the plan

How do you arrive at a release schedule & plan

Page 93: Leading Successful Programmes (LSP) v2.8

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!

Page 94: Leading Successful Programmes (LSP) v2.8

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

Page 95: Leading Successful Programmes (LSP) v2.8

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)

Page 96: Leading Successful Programmes (LSP) v2.8

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

Page 97: Leading Successful Programmes (LSP) v2.8

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)

Page 98: Leading Successful Programmes (LSP) v2.8

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

Page 99: Leading Successful Programmes (LSP) v2.8

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?

Page 100: Leading Successful Programmes (LSP) v2.8

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.

Page 101: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Managing a programme’s PROCESSES

A successful PMO

Page 102: Leading Successful Programmes (LSP) v2.8

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

Page 103: Leading Successful Programmes (LSP) v2.8

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

Page 104: Leading Successful Programmes (LSP) v2.8

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

Page 105: Leading Successful Programmes (LSP) v2.8

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

Page 106: Leading Successful Programmes (LSP) v2.8

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

Page 107: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Programme Pitfalls and Assurance

Page 108: Leading Successful Programmes (LSP) v2.8

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”

Page 109: Leading Successful Programmes (LSP) v2.8

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

Page 110: Leading Successful Programmes (LSP) v2.8

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!

Page 111: Leading Successful Programmes (LSP) v2.8

Copyright Maddison Ward 2006

Questions / Review of the day

Page 112: Leading Successful Programmes (LSP) v2.8

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

Page 113: Leading Successful Programmes (LSP) v2.8

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