Will your programme fail?
This article is based on the authors’ experience in running projects and programmes in service industries. Aspects particular to other industries, for example major infrastructure projects, are not dealt with here.
In this article I’ve tried to distil some of the lessons learnt from 30 years of project and programme management experience into Ten Top Tips which, in my experience, determine whether or not any programme succeeds. That’s quite a challenge. Programme management is a complex multi-faceted discipline. But I believe these are the key factors which make the difference between success and failure.
1. Make sure that all your stakeholders support the programme.
If you are running a big multi-stream programme in a large organisation this may not be straightforward. Different stakeholders will have their own objectives and vested interests. If your programme is expected to deliver substantial change then it is very unlikely that they will all give their wholehearted support to it.
One way to test this is to ask each of them individually whether they would be prepared to compromise on either time, scope or cost. If a stakeholder refuses to accept any of these options then this is clearly a Red flag. Either he’s under unreasonable pressure or he doesn’t want you to succeed. Most business managers will take a pragmatic approach and recognise that you may need some leeway.
2. Are the programme goals clear and achievable?
Again, this can be far more difficult than it sounds. I’ve worked on several programmes where the objectives were not entirely clear. For example, the goals of the Solvency II programmes currently under way at vast expense in the insurance industry are determined by EU legislation which has not yet been finalised. At the time of writing (December 2012) the roll-out timetable is uncertain and the detailed requirements are still not clear in several key areas.
3. Think benefits. Make sure that, wherever possible, they are tangible and evident.
It is very easy, in the midst of all the pressures of developing systems and overcoming resistance to change, to lose sight of the benefits side of the equation. But without this focus you’re becoming a hostage to fortune. You’re running the risk that the opponents of change could undermine the perceived value of the whole programme.
4. Are you in control of the programme scope?
Like most programme managers in these austere times, you are probably stuck with a fixed cost budget and tight timescales. In these circumstances the only thing you can flex, if delays creep in, is the scope of your programme delivery. But you can only do this if you have a close involvement in the systems and process design and understand the time/cost/benefit equation for each delivery component.
5. Organise the programme team in an appropriate way.
No two programmes are the same. The set of issues and risks you are currently facing are unique and you have a unique, and limited, resource pool at your disposal. Keep it simple. Don’t implement an overly complicated structure. Your team need clear boundaries and stable objectives they feel they can deliver. Are you sure that responsibilities and ownership are clearly defined across the programme? Are the governance processes and lines of authority straightforward and transparent to all involved? Is the team adequately resourced?
6. Do your team members have the skills and competencies required?
Quite often it’s not in the best interests of employees to be assigned to your change programme. It may not contribute positively to their profile within their home department and they may be exposed when the programme (and their work) finishes. It can be difficult to get good people assigned to a project under these circumstances.
7. Can the Users complete their side of the bargain?
Many companies now run lean processes and even leaner departments in which every head is a precious resource. No resource is set aside for project work and there may already be a queue of other projects ahead of you, all demanding time from the users. I worked once in a Japanese bank where the users worked from 8am until 6pm on the programme and then went back to their “day jobs”, finishing at around 2am! In reality they had no spare capacity for the programme at all.
8. Wherever possible, avoid using unproven technology.
Unless you need to take the risk. I’ve been involved in systems development for the last 25 years and during that period we’ve gone through at least the same number of technology “flavours of the month”. Most of these have fallen by the wayside. On the other hand, adopting the right technology at an early stage can pay dividends in extending the useful life of a system.
Today, it is comparatively easy for the IT department to choose established platforms which will not suffer from early obsolescence. There have to be strong reasons for adopting new technology because the risks associated with it are normally very high.
9. Make sure the IT methodology is appropriate.
Few IT departments make a clear distinction between the approach they would follow in: a) developing a website; or b) implementing an accounting package; or c) developing a complex risk management system. Yet each of these projects should be delivered in a different way.
It is vital to get this choice of methodology right because the stages in the approach the IT team intend to follow, and the documentation standards they intend to meet, are the only milestones and quality checks you can insert into what could be a very long development plan. The worst IT departments prefer not to be tied to a particular methodology but it is very important to make sure that this choice, and the standards which come with it, is clear. Otherwise you are walking on sand.
10. Will the third party suppliers deliver what you need?
This could include offshore developers, internal IT teams or independent software houses. Issues normally revolve around the suppliers’ inability to match their delivery capacity to the current market demand. This usually means that they cannot deliver what you need within your programme timescales. Even then, the question is whether you can depend on them to deliver on the dates they promise.
Article by John Lancashire – Blue Alumni