If so, you have many challanges ahead and pitfalls to avoid. It is essential that you spend time setiing things up correctly. Check out the advice below, which is based on our real-life experience and learnings. Please contact us if you would like us to help you establish or deliver your change programme with you.
| Getting Started |
| Make your Vision clear |
- Define a clear vision and purpose and any guiding principles at the outset and ensure these are kept visible and adhered to through the life of the programme.
- Encapsulate these in a single, clear document, which can then be provided to all new team members.
- Use the MSP (Managing Successful Programmes) methodology — it is particularly strong on programme initiation and definition, and should be followed where helpful.
|
| Don't promise when you can't deliver |
- Do not quote timescales until at least some initial and realistic planning has taken place. Even then, allowance must be made for the fact that a significant proportion of tasks inevitably hit snags and delays. At least 25% contingency should be added for timescales. It is more appropriate to quote a range of dates or less precise dates (e.g. “mid 2008”).
- The programme team can commit to end-of-stage dates a few months ahead, but must resist pressure to commit to unsupportable and optimistic end of programme dates until proper plans are in place with a supporting risk assessment.
|
| Make a realistic business Case |
- Define a detailed business case at the start of the programme, and maintain this throughout its life. Use the business case to assess all significant decisions e. g. around sourcing, timescales, scope etc.
- TIt needs to be crystal clear whether benefits are baked into the budget, or incremental to it. The former is recommended where the benefits are tangible and confidently achievable, and the budget can be updated to include them.
- The Programme Steering Group should insist on regular reporting of costs, benefits and ROI/NPV progression, and regularly check that the remaining programme costs are justified by the remaining benefits.
- Large, long-term, infrastructure and service transformation programmes should be approved based on strategic, enabling, cost-avoidance and risk-mitigation grounds. Financial justification should form part of this, but should not be “make or break” requirement, and certainly should not require a three year ROI.
|
| Leading your team |
| Build the Best |
- Identify resource needs upfront, and do not progress with inadequate or sub-optimal resources. Whilst this is easier said than done, it does underline the criticality of a programme being fully resourced with the necessary skills and experience. Cutting corners on this is always a false economy. Ensure plenty of contingency in the budget for internal resources, and agree how and when these will be cross-charged to the programme.
- Define and agree clear roles and deliverables for every team member. Only mix responsibilities between programme work and “Business As Usual” work where it is in the interests of both.
|
| Keep it On Top |
- Rapidly replace under-performing team members. There is no time to carry passengers. They only absorb management effort and distract focus, and are rarely fulfilled in their roles.
- When working with a 3rs Party, have a regular customer-only meeting to ensure alignment across the team. This also provides the forum to raise internal resource or funding issues, or issues related to the supplier.
- Ensure regular meetings are held with key internal BAU teams, to keep them onside and engaged.
|
| Keeping the Important People Happy |
| Manage your Stakeholders |
- Agree and follow a stakeholder and communication plan for all senior managers (including IT ones). Each key stakeholder should be assessed and have a person within the programme team, or senior IT management, who keeps them informed and engaged. Again MSP provides strong support for this.
- Agree a plan for all meetings where the programme could or should be discussed – from board level through functional or regular IT meetings.
- Ensure feedback is fed back into the programme team from all such meetings or engagements.
|
| Make the Steering Group Effective |
- Ensure Steering Group members are well aware of their responsibilities, the importance of engagement and book meetings well in advance. Keep them engaged between meetings.
- Ensure Steering Group Meetings are focussed, non-technical and couched in business terms, focussing on the business impact and the decisions or opinions required from the business representatives.
|
| Communicate, Communicate, Communicate |
- Engage the Company Comms team and use its resources and expertise. Develop a communications plan with them and incorporate this into the programme plan around key milestones.
- Elect Change Champions across the affected business areas – define their roles, pick good ones and meet with them regularly./li>
- Have a brand, a logo, a strap line. Use this on all communications. Use posters, leaflets, bulletins, intranet pages, but be aware of sensitivities around paper.
- Keep all communications brief and business-focussed and based on “what they need to know” rather than “what you want to tell them”.
- Keep a level of communications at all times, even when there is a period of uncertainty. In the absence of communications, people assume nothing is happening, or make up their on stories.
- Communications need to be carefully worded to avoid setting hares running and be sensitive around periods of redundancy. Responsibilities need to be very clear and people treated with honest and respect. Early communication is necessary through the correct channels, before it is pre-empted by demotivating communication through the wrong channels
|
| Staying in Control |
| Plan Professionally |
- Deliverables-back (product based) planning is highly recommended to ensure the plan is complete and focussed. For clarity every task should be a verb and a noun.
- Plans need to be kept in a project planning tool, with all tasks, all dependencies, and resources specified.Resource pools may only be specified where there is a genuinely available and flexible resource pool.All resources in plans need to be agreed with line management and be levelled on the basis of realistic availability. Holidays must be included
- If separate workstream plans are helpful, they need to be automatically linked and rolled up to a summary plan. Cross-workstream impacts need to be highlighted and managed at the Programme Board.
- All plans need to contain contingency, which should start high and reduce over time. Estimatiopns of effort and timescales should reference previous projects and experiences and explicitly allow for business constraints, risk and requirements. Avoid optimism!
- Plans need to be demonstrably followed, tracked, monitored and updated at least once a week, rather than created and then ignored. The supplier PMO needs to highlight where this is not complete (e.g. incomplete tasks in the past etc). Dashboard reporting needs to take milestone dates directly from these plans.
|
| Monitor, Meet and Report |
- A structure of Steering Group, Programme Executive and Programme Board is a good one, tailored to the needs of the individual programme. Within this, accountabilities and escalation routes need to be crystal clear and transferred as new managers come on board. Where third-parties are involved, an additional regular “relationship” meeting is recommended, plus a separate “customer-only” meeting.
- Meetings should have an objective, a clear chair, agreed attendees, and be kept within scope of the meeting. Meetings should be cancelled and rearranged if any key attendees are missing. Unnecessary attendance by management should be avoided. All formal meetings should be minuted, and those minutes issued to all parties. We would recommend this is done by the customer to ensure they protect the customer’s interests.
- A formal and consistent upward pyramid reporting mechanism is recommended, around dashboard and exception reporting, ensuring it is all-inclusive but concise.
- Workshops are particulary effective for making key decisions, or designing key outputs. They need to be planned and prepared well, have clear inputs and outputs, a defined process, a string leader, and all decision-makers and experts need to be there!
- Daily meetings should be used in short bursts at key points in the programme. They can be particularly useful leading up to particular milestones, or for an intensive period of cross-team activity (such as replanning or contract formulation), or when there is a need to refocus into one-team and re-invigorate the programme. But beware- they can lose momentum and get clogged up after about 3-4 weeks.
|
| Be tough on issues and risks |
- Issues must be clearly defined, evaluated, owned, and driven through, and escalated if they get “stuck”. Rapid resolution of issues is essential for a major programme. This requires the drive and focus of workstream and programme mangers on the supplier and customer sides
- Risks need to be identified, refreshed and actively managed, before they become issues. Draining the swamp is inherently more successful and more pleasurable than wrestling with the alligators.
- Issue logs and risk logs are essential and must be maintained and used actively.
|
| Run a Tight Ship |
- Write a PID (Project Initiation Document) and ensure it is fully agreed and signed-off by all parties before the programme starts. Review it every six-months at least.
- Ensure there is a PMO role with the supplier from the start, who monitors and manages governance and quality.
- All actions and decisions should be recorded onto an Action and Decision Log, showing clearly who is accountable, by when and where the action is to be tracked. A change log should be maintained for all change requests.
- A shared portal or document repository is essential for all project documentation. Standards for document control need to be agreed and consistently followed.
|
| Build in and Insist on Quality |
- Quality must be built-in to all that the team does. Getting it right first time saves rework, is more satisfying and gets it right for your business. Poor quality means delay, demotivation and endless issues.
- Quality Gate meetings are recommended prior to each stage of delivery. The ideal pattern is to have an initial meeting to agree the criteria, and then one or more meetings to ensure the final QG is passed.
- Agree and follow a V model for testing, simplified and/or adapted as necessary. This will lead to agreed test plans matching the programme requirements. Ensure the supplier tests properly to this model, before handing over to the customer for UAT.Ensure both the supplier and customer have adequate testing resources and management in place
- Agree a test strategy and approach for each key area, which is a pragmatic balance between effort and risk. Needless to say (or it should be), testing needs to include unit, system, environment, interface and performance testing and allow for all varieties of legacy data.
|
| Balancing the Books |
| Manage Your Money |
- Provide monthly tracking of costs and benefits, based on the currently agreed plans and scope. Ensure you have sufficient time or resources to do this, with support from the finance function and access to financial systems.
- There needs to be a clear and frequently maintained link to the IT budget, which is agreed between the Programme Manager and the IT manager with responsibility for the budget, plus functional managers where benefits are realised in other functions.
- Set up a clear approval process for all expenditure from the outset agreed by all approvers.
|
| Make Benefits Happen |
- Put in place a benefits realisation plan and ensure named individuals have clear accountability for the achievement of benefits. The MSP Methodology provides strong support for this.
- Report progress regularly to the Steering Group, alongside strategic and user benefits. If benefits are not being realised, or costs are escalating, the business case should be re-examined and the corrective action taken.
|
