Leading Successful Programmes (LSP) v2.8

941 views
762 views

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
941
On SlideShare
0
From Embeds
0
Number of Embeds
52
Actions
Shares
0
Downloads
40
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Leading Successful Programmes (LSP) v2.8

  1. 1. Programme Leadership Course Version 2.7 February 2009 Leading Successful Programmes
  2. 2. 2 Copyright © Maddison Ward 2006 Course Objectives  What you will learn from this course  What a programme is, and how to lead it  What levers you can use to drive a programme to a successful outcome  How to maintain a high-performing delivery organisation  How to manage the client  What processes you need to have in place to monitor and control a programme  What you will not learn  Anything about methodologies, such as Prince, Agile, RUP etc.  What documents you need to produce when  How to use Microsoft Project
  3. 3. Copyright Maddison Ward 2006 What is a Project or Programme? The bus of success carries many passengers, but the bicycle of failure is ridden alone --Stuart Robb 2001 The bus of success carries many passengers, but the bicycle of failure is ridden alone --Stuart Robb 2001
  4. 4. 4 Copyright © 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”?
  5. 5. 5 Copyright © 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?
  6. 6. 6 Copyright © 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?
  7. 7. 7 Copyright © 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
  8. 8. 8 Copyright © 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
  9. 9. 9 Copyright © 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!
  10. 10. 10 Copyright © Maddison Ward 2006 What makes a programme successful? PROCESS PEOPLE TECHNOLOGY Collateral Knowledge Procedures Forums Terms of Reference Directory Structures Project Folders Signoffs/Acceptances Culture Behaviours Leadership Training Incentives/Reward Peer Reviews Monitoring Environment Milestone Management Risk/Issue Management Portfolio Management Financial Management Resource Management Knowledge Management Configuration Management Microsoft Project RAID Logs (Excel/MS Access) Timesheeting (Clarity) GOOD PROCESSES are no substitute for GREAT LEADERSHIP
  11. 11. 11 Copyright © 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?
  12. 12. 12 Copyright © 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!
  13. 13. 13 Copyright © 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
  14. 14. 14 Copyright © 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
  15. 15. 15 Copyright © 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.
  16. 16. 16 Copyright © 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!
  17. 17. 17 Copyright © 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?
  18. 18. 18 Copyright © Maddison Ward 2006 Empathy Gravitas What makes up leadership attributes? Charisma POWER Respect Openness Approachability Enthusiasm Empathy Body language Reward Coersion Referent Legitimate Expert Lead by example Influence positively Be Inclusive Be factual / knowledgable Be human Be honest Body Language AUTHORITY In what proportion do these need to be to make a great leader? How would you rate yourself? Virtue Dignity Integrity Solemnity Seriousness Substance Purpose Vision Drive Motivation Relentlessness Decisiveness
  19. 19. 19 Copyright © 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?
  20. 20. 20 Copyright © 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.
  21. 21. 21 Copyright © 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?
  22. 22. 22 Copyright © 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
  23. 23. 23 Copyright © 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).
  24. 24. 24 Copyright © 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
  25. 25. 25 Copyright © 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
  26. 26. 26 Copyright © 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?
  27. 27. 27 Copyright © 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)
  28. 28. 28 Copyright © 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
  29. 29. 29 Copyright © 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
  30. 30. 30 Copyright © 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)
  31. 31. 31 Copyright © 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…
  32. 32. 32 Copyright © Maddison Ward 2006 Leadership Example  Apollo 13...  Gene Krantz established a “tiger team”  What leadership characteristics did Gene demonstrate during the Apollo 13 crisis?
  33. 33. 33 Copyright © 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?
  34. 34. 34 Copyright © 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?
  35. 35. 35 Copyright © 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...
  36. 36. 36 Copyright © 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?
  37. 37. 37 Copyright © 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?
  38. 38. Copyright Maddison Ward 2006 Questions / Review of the day
  39. 39. 39 Copyright © 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
  40. 40. Copyright Maddison Ward 2006 Programme Dimensions Every obstacle yields to stern resolve. --Leonardo da Vinci Every obstacle yields to stern resolve. --Leonardo da Vinci
  41. 41. 41 Copyright © 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
  42. 42. 42 Copyright © Maddison Ward 2006 Four Essential Disciplines of Portfolio Management Plan Management Resource Management Financial Management Prioritised initiatives Project Estimation Inter-dependencies Are we doing the right thing, at the right time, in the right order to maximise business value? Resource (talent) pool BAU baseline Project Plans Do we have sufficient people, with the right skills, available at the right time Budget Business cases Project costings Can we afford it and does it make us any money? Change Management Project Plans Change Impact Map Training Needs Analysis Stakeholder Engagement Can the business tolerate the change footprint and is the business ready for it? Tools/Diagnostics Discipline Allows us to understand:- Underpinned by clear, accurate, unambiguous STATUS (through dashboard etc) PERFECTVIEW
  43. 43. Copyright Maddison Ward 2006 Managing the levers of RISK
  44. 44. 44 Copyright © Maddison Ward 2006 Page 44 Programme Dimensions REDUCE SCOPE INCREASE BUDGET INCREASE TIME LOWER QUALITY INCREASE SCOPE REDUCE BUDGET REDUCE TIME INCREASE QUALITY RISK There are four levers to play with – the challenge is to set each lever at just the right place that the programme is stable, deliverable and an equilibrium is established. 1. BUDGET 2. SCOPE 3. QUALITY 4. TIME Risk Balancing Act
  45. 45. 45 Copyright © 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
  46. 46. 46 Copyright © 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
  47. 47. 47 Copyright © Maddison Ward 2006 Page 47 Reducing quality results in... QUALITY Reduce Code Quality Higher Defect Rates & Re- work (increasing Development costs) Faster Coding Time (potential lower resource costs) Undertake Less Testing Lower Infratructure 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
  48. 48. 48 Copyright © 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
  49. 49. 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
  50. 50. 50 Copyright © Maddison Ward 2006 Creating a high-performing ORGANISATION  Types of organisation  Matrix Management / Competency pools  Organisational cohesion & communications  Organisational performance
  51. 51. 51 Copyright © 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
  52. 52. 52 Copyright © 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”?
  53. 53. 53 Copyright © 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
  54. 54. 54 Copyright © 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
  55. 55. 55 Copyright © 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?
  56. 56. 56 Copyright © Maddison Ward 2006 Organisational cohesion  Example of a programme booklet
  57. 57. 57 Copyright © 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)
  58. 58. 58 Copyright © 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!!!!
  59. 59. 59 Copyright © 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).
  60. 60. Copyright Maddison Ward 2006 Managing the Client
  61. 61. 61 Copyright © 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
  62. 62. 62 Copyright © Maddison Ward 2006 Managing the a difficult client  What kind of influencing styles can one deploy against a difficult client  Managing expectations
  63. 63. Copyright Maddison Ward 2006 Managing the Client THE BUSINESS CASE
  64. 64. 64 Copyright © 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
  65. 65. 65 Copyright © 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
  66. 66. 66 Copyright © 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.
  67. 67. 67 Copyright © 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?
  68. 68. 68 Copyright © 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
  69. 69. 69 Copyright © 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
  70. 70. 70 Copyright © Maddison Ward 2006 What is a benefit? Tangible Intangible FinancialNon-financial Reduction in costs Accommodation savings Better cash management Increased revenue Increased contribution Better quality of service Improvement to KPI targets inc. CSI Lower staff turnover Fewer customer complaints Improved productivity eg AHT Lower customer churn Increased people morale (Reflect) Corporate ‘image’ Better access to information Improved processes Increased competitiveness Access to markets Regulatory requirement Based on Deloitte ‘Types of benefits’
  71. 71. 71 Copyright © 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?
  72. 72. 72 Copyright © 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.
  73. 73. 73 Copyright © 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!
  74. 74. 74 Copyright © 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.
  75. 75. 75 Copyright © 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.
  76. 76. 76 Copyright © 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?
  77. 77. 77 Copyright © 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?
  78. 78. 78 Copyright © 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!
  79. 79. Copyright Maddison Ward 2006 Managing the Client THE REQUIREMENTS
  80. 80. 80 Copyright © 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.
  81. 81. 81 Copyright © 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!
  82. 82. 82 Copyright © 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.
  83. 83. 83 Copyright © Maddison Ward 2006 What are the “types” of requirements Business SME input Business Driver Research Industry Best Practice Customer Experience Lifecycle Customer Experience Definition Business Model Business Case Target To-be Processes Impacted Processes Process KPI’s & Volumetrics Process-led requirements Process Maps Hypotheses Business (People) Requirements Functional Requirements (Technology) Non-Functional Requirements (Technology) Business Environment Requirements Organisational Impact Assessment Systems Requirements “PEOPLE” “PROCESS” “TECHNOLOGY” Organisational Requirements Systems Functional Requirements Business Requirements Specification Prioritised Initiatives Traditional waterfall “requirements” breakdown – process led
  84. 84. 84 Copyright © Maddison Ward 2006 Business Requirements
  85. 85. 85 Copyright © Maddison Ward 2006 System Functional Requirements  “like”???? “etc”?????
  86. 86. 86 Copyright © 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!
  87. 87. 87 Copyright © 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
  88. 88. Copyright Maddison Ward 2006 Managing the Client THE COMMERCIALS
  89. 89. 89 Copyright © 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!
  90. 90. 90 Copyright © 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!
  91. 91. 91 Copyright © 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”
  92. 92. Copyright Maddison Ward 2006 Deriving the plan How do you arrive at a release schedule & plan
  93. 93. 93 Copyright © 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!
  94. 94. 94 Copyright © 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
  95. 95. 95 Copyright © 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)
  96. 96. 96 Copyright © Maddison Ward 2006 Work-package Descriptions What should be in a WDP? Should be completed by the person responsible for performing the work and signed off by the person accountable for it’s successful outcome • Purpose of the work-package • Approach to deliver it • Owner (and lead performer) • Inputs & Outputs (components) • Dependencies & Constraints • Reporting Requirements • Scope • Resources • Milestones • Costs • Acceptance Criteria • Reviewers & Sign-offs • Risks, Assumptions • Document Control
  97. 97. 97 Copyright © Maddison Ward 2006 Work-package Descriptions Example set of programme workstreams & work-packages LLD-I-P-WP Programme LLD-I-A-WP ACCELERATE LLD-I-C-WP CRUISE LLD-I-T-WP TEST LLD-I-CS-WP CS LLD-I-CH-WP CHANNELS LLD-I-F11 SOC Autodeploy UAT LLD-I-A01 Offer Strategy LLD-I-C01 KPI Reporting LLD-I-T01 AsIs Test Process LLD-I-CS01 Outbound UAT LLD-I-D01 UAT LLD-I-F12 XS/US Campaign 5 Free MMS LLD-I-A02 Campaign Offer Schedule LLD-I-C02 Process Measures LLD-I-T02 Quick Wins LLD-I-CS002 Pilot (Phase 1) LLD-I-D02 Pilot LLD-I-F13 Data Xfer £49.98 LLD-I-A03 Campaign & Offers for Indirect LLD-I-C03 BPCU Capability LLD-I-T03 BAU Test Process (Interim) LLD-I-CS03 Rollout (Phase 1) LLD-I-D03 Rollout LLD-I-F14 Campaigns for Direct LLD-I-A04 Resource Transition LLD-I-C04 Business Case (Full) LLD-I-T04 Long-Term Test Reqts LLD-I-I01 UAT LLD-I-F15 BPCU Campaigns LLD-I-A05 Campaign Reporting Reqts LLD-I-C06 Change Mgt Review LLD-I-I02 Front3 Launch LLD-I-F16 XS/US Campaign Web & Walk LLD-I-A06 Processes LLD-I-C06 Review Exit / Completion Criteria LLD-I-I03 Carphone Deployment LLD-I-A07 SOC Change Process LLD-I-C07 Facilitate Channel Launch LLD-I-I04 Channel Implementation LLD-I-A08 Handset Mgt Process LLD-I-C08 Business Review LLD-I-A09 Interim OMSE Solution LLD-I-A10 Housekeeping LLD-I-F-WP FIX LLD-I-F01 Campaign Design Review LLD-I-F02 XS/US Campaign Itemised Billing LLD-I-F03 CAP Rule Change LLD-I-F04 BIS Preparation LLD-I-F05 Outbound Campaign LLD-I-F06 WebReg/Domino Defects LLD-I-F07 SAS Model Prioritisation LLD-I-F08 VAT Solution LLD-I-F09 £90 Subsidy LLD-I-F10 Belnded Definition Soln LLD-I-A11 Marketing Reporting LLD-I-A12 OMSE / SAP Pricing LLD-I-T00 TestCTNs LLD-I-F17 INFO Campaign Direct Debit LLD-I-F18 INFO Campaign First Call Resolution LLD-I-F19 Business Support LLD-I-F20 End2End Testing Of ALL fixes LLD-I-A13 Campaigns for CS Outbound UAT LLD-I-A14 CCOS Bible LLD-I-A15 Campaigns for CS Renewals LLD-I-CS04 Outbound CAP Rule UAT LLD-I-CS05 Outsourcer Deployment LLD-I-CS006 Pilot (Renewals) LLD-I-CS07 Rollout (Renewals) LLD-I-P-WP Programme LLD-I-A-WP ACCELERATE LLD-I-C-WP CRUISE LLD-I-T-WP TEST LLD-I-CS-WP CS LLD-I-CH-WP CHANNELS LLD-I-F11 SOC Autodeploy UAT LLD-I-A01 Offer Strategy LLD-I-C01 KPI Reporting LLD-I-T01 AsIs Test Process LLD-I-CS01 Outbound UAT LLD-I-D01 UAT LLD-I-F12 XS/US Campaign 5 Free MMS LLD-I-A02 Campaign Offer Schedule LLD-I-C02 Process Measures LLD-I-T02 Quick Wins LLD-I-CS002 Pilot (Phase 1) LLD-I-D02 Pilot LLD-I-F13 Data Xfer £49.98 LLD-I-A03 Campaign & Offers for Indirect LLD-I-C03 BPCU Capability LLD-I-T03 BAU Test Process (Interim) LLD-I-CS03 Rollout (Phase 1) LLD-I-D03 Rollout LLD-I-F14 Campaigns for Direct LLD-I-A04 Resource Transition LLD-I-C04 Business Case (Full) LLD-I-T04 Long-Term Test Reqts LLD-I-I01 UAT LLD-I-F15 BPCU Campaigns LLD-I-A05 Campaign Reporting Reqts LLD-I-C06 Change Mgt Review LLD-I-I02 Front3 Launch LLD-I-F16 XS/US Campaign Web & Walk LLD-I-A06 Processes LLD-I-C06 Review Exit / Completion Criteria LLD-I-I03 Carphone Deployment LLD-I-A07 SOC Change Process LLD-I-C07 Facilitate Channel Launch LLD-I-I04 Channel Implementation LLD-I-A08 Handset Mgt Process LLD-I-C08 Business Review LLD-I-A09 Interim OMSE Solution LLD-I-A10 Housekeeping LLD-I-F-WP FIX LLD-I-F01 Campaign Design Review LLD-I-F02 XS/US Campaign Itemised Billing LLD-I-F03 CAP Rule Change LLD-I-F04 BIS Preparation LLD-I-F05 Outbound Campaign LLD-I-F06 WebReg/Domino Defects LLD-I-F07 SAS Model Prioritisation LLD-I-F08 VAT Solution LLD-I-F09 £90 Subsidy LLD-I-F10 Belnded Definition Soln LLD-I-A11 Marketing Reporting LLD-I-A12 OMSE / SAP Pricing LLD-I-T00 TestCTNs LLD-I-F17 INFO Campaign Direct Debit LLD-I-F18 INFO Campaign First Call Resolution LLD-I-F19 Business Support LLD-I-F20 End2End Testing Of ALL fixes LLD-I-A13 Campaigns for CS Outbound UAT LLD-I-A14 CCOS Bible LLD-I-A15 Campaigns for CS Renewals LLD-I-CS04 Outbound CAP Rule UAT LLD-I-CS05 Outsourcer Deployment LLD-I-CS006 Pilot (Renewals) LLD-I-CS07 Rollout (Renewals)
  98. 98. 98 Copyright © Maddison Ward 2006 Work-package Dependencies 98 LLD-I-A01 Offer Strategy LLD-I-C01 KPI Reporting LLD-I-T01 AsIs Test Process LLD-I-CS06 Outbound UAT LLD-I-A02 Campaign Offer Schedule LLD-I-C02 Process Measures LLD-I-A03 Campaign & Offers for Indirect LLD-I-T03 BAU Test Process (Interim) LLD-I-A04 Resource Transition LLD-I-C04 Business Case (Full) LLD-I-T04 Long-Term Test Reqts LLD-I-I01 UAT LLD-I-A05 Campaign Reporting Solution LLD-I-C06 Change Mgt Review LLD-I-I02 Front3 Launch LLD-I-A06 Processes LLD-I-C06 Review Exit / Completion Criteria LLD-I-I03 Carphone Deployment LLD-I-A07 SOC Change Process LLD-I-C07 Facilitate Channel Launch LLD-I-I04 Channel Implementation LLD-I-A08 Handset Mgt Process LLD-I-A09 Interim OMSE Solution LLD-I-A10 Housekeeping LLD-I-A11 Marketing Reporting LLD-I-A12 OMSE / SAP Pricing LLD-I-A13 Campaigns for CS Outbound UAT LLD-I-A14 CCOS Bible LLD-I-A15 Campaigns for CS Renewals LLD-I-CS07 Outbound Rollout LLD-I-CS09 Pilot (Renewals) LLD-I-CS10 Rollout (Renewals) LLD-I-A16 End2End Test A B LLD-I-CS08 Renewals UAT C LLD-I-F06 WebReg/Domino Defects LLD-I-D02 Pilot 31/2/07 3/4/07 28/5/07 30/7/07 LLD-I-T05 Interim Test Environment LLD-I-A17 Outbound PRP This is where Microsoft Project can really help – use it to manage & track dependencies between work-packages & identify the critical path
  99. 99. 99 Copyright © 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?
  100. 100. 100 Copyright © 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.
  101. 101. Copyright Maddison Ward 2006 Managing a programme’s PROCESSES A successful PMO
  102. 102. 102 Copyright © 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
  103. 103. 103 Copyright © 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
  104. 104. 104 Copyright © Maddison Ward 2006 Programme Management Office Organisation & Activities Programme Office Manager Programme Communications Analyst Programme Quality Assurance Programme Controller Financial Analyst Programme Controller Resources Programme Controller Plan Programme Administrator Programme Controller RAID/Change •Financial Controller •Order Management •Contract Management •Supplier Management •(Logistics Support) •(RAID Process) •(Change Process) •IT Work Orders •Workshop Support •Email Dlists •Logistics Support •Meeting Room Management •Senior Team Diary Mgt •Hotel Administration •Meeting Minutes •RAID Process Owner •Change Process Owner •(Financial Controller) •(Document Controller) •Stage Plan Delivery •PMO Processes Owner •Status Report Owner •Ad-hoc reporting •Quality Management •(Plan Manager) •Procedures Adherence •Audit Relationship •Governance •Integrated Plan Manager •Dependency Manager •Deliverables Tracking •Document Controller •Signoff Tracking •Future phase planning •(Quality Manager) •Programme Comms •Stakeholder Management •Steering Group Secretariat •Team Environment •Programme Brand •Workshop Support •Workstream Review/audit •Project audit •New starters •Organisation Maintenance •Performance Management •Contractor Roll-on/Roll-off •Resource Planning •Terms of Reference / RACIs •Role Description Management •Logistics / Desk Planning
  105. 105. 105 Copyright © 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
  106. 106. 106 Copyright © 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 weeks 6 weeks 1 day 1 day 10 days 2 weeks 2 weeks 2 weeks 1 weeks 1 day 2 days 1 day 1 day 7 days 1 day 100 years 10 days Never - tbc tbc Request SLA Primary Contact
  107. 107. Copyright Maddison Ward 2006 Programme Pitfalls and Assurance
  108. 108. 108 Copyright © 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”
  109. 109. 109 Copyright © 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
  110. 110. 110 Copyright © 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!
  111. 111. Copyright Maddison Ward 2006 Questions / Review of the day
  112. 112. 112 Copyright © 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 % PM Test Plan Traceable Desk Check Consistent with Requirements and High Level Design PM Complete Walkthrough Addresses all aspects of Testing as set out in Project Test Plan Test Lead Test Reports Complete Desk Check All testing covered, pass/failure rates and defects raised must be reported at the end of a test pass. PM Release Notes Traceable Testing All defects addressed in a particular release must be listed and outstanding known issues must be clearly spelled out! Test Lead Timely Desk Check Must be received along with an official release of code for Testing and/or Acceptance PM Weekly Status Reports Format Desk Check The nature of the Development Status should incorporate earned value as a mechanism for reporting completeness. Test Status should be provided showing number of Test Cases Planned, Documented, Executed and Passed or Failed. Defects Status and details should also be available for Review. Visibility of Keane risks and issues should also be provided. PM Timely Desk Check Must be received on a weekly basis PM All Guides and Manuals Understandable Walkthrough Content clear, understood and deemed acceptable by all relevant stakeholders Various Complete Walkthrough Content addresses all requirements and functionality being delivered Various Developers Guide Usable Walkthrough Content accepted by Architect(s) and Dev Responsible Stakeholders in Various User Manual Usable User Acceptance Testing Manual as used by System Users during UAT deemed usable and fit for purpose. No TBDs or critical/major issues/defects outstanding. Various System Administation Manual Usable Operations Acceptance Testing Manual as used by System Administrators during OAT deemed usable and fit for purpose. No TBDs or critical/major issues/defects outstanding. Various Design Quality Screens Design Traceable Desk Check Consistent with Requirements BA Usable Demonstration Mockups acceptable to Business Various Database Design Traceable Desk Check Consistent with High Level Design Architect Compliant with Standards Desk Check Adheres to MID Data Architect Low Level Design (LLD) Traceable Desk Check Consistent with High Level Design Architect Clear Walkthrough Design accepted by Architect(s) and Dev Responsible Stakeholders in Various Product (Code) Quality Application/System Compliant with Standards Code Reviews Adheres to Coding Standards Architect/ Dev Traceable Code Reviews Consistent with Low Level Design Architect Understandable Code Counting Tool Internal Documentation, e.g. Comments at acceptable % of Code PM/Architect Code Reviews JavaDoc's exist and are complete for all Java Code PM/Architect Code Counting Tool Code Complexity determined based on Average McCabe Metric per Function (Cyclomatic Complexity Number) at acceptable level PM/Architect Testable Site Acceptance Testing Code can be built and deployed on Test Environment and will run without blocking defects. Test Lead Reliable Performance Testing Defect Counts and Severities (specific to Performance) at an acceptable level Test Lead Usable Demonstration Defect Counts and Severities arising out of Screen Reviews (per Iteration) at an acceptable level Various User Acceptance Testing Defect Counts and Severities arising from UAT at an acceptable level Business Stakeholders Functional Testing (all Phases) Defect Counts and Severities at acceptable (and declining) levels Test Lead Installation "Kit" Complete Code Reviews Process/Mechanisms delivered as outlined in Low Level Design Architect Usable Site Acceptance Testing Defect Counts and Severities at an acceptable level Test Lead Database Setup Scripts Complete Code Reviews Process/Mechanisms delivered as outlined in Low Level Design Data Architect Usable Site Acceptance Testing Defect Counts and Severities at an acceptable level Test Lead Sample Templates Clear Code Reviews Content accepted by Architect(s) and Dev Responsible Stakeholders in Various Test Quality Unit Tests Complete Coverage Tracking Tool Code Coverage % arising from automated Unit Test using Junit at an acceptable level PM/Architect System Test Objectives Traceable Desk Check Consistent with Requirements and Functionality to be delivered Test Lead Complete Walkthrough All functionality covered Test Lead System Test Cases Traceable Desk Check Consistent with Requirements and Functionality to be delivered Test Lead Complete Walkthrough Functional Coverage % (Positive/Negative/Boundary) Test Lead Reportable Desk Check Mechanisms mus be place via Weekly Status Reports to facilitate reporting of Test Cases Status (i.e. numbers Planned, Documented, Executed, Passed/Failed) PM
  113. 113. 113 Copyright © 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 CLIENT Business Case Managing the CLIENT Requirements Programme Pitfalls and Assurance NineDimensions approach to Programme Process Q&A

×