This emerged from the recent BCS "thought leadership" debate, held under a rule of anonymity to enable senior people from IT user companies, suppliers, government and universities to air their views frankly.
The debate heard that, in complex business change programmes, the management must come from the top, because such programmes threaten the entire organisation. Such leadership is especially important if some stakeholders are less than enthusiastic. Stakeholders must be kept engaged throughout, especially the end-users.
The need for "hybrid" managers who can build communication bridges between tech- nologists and the board was identified some years ago. They can cope with the business, are experienced in IT, and have the personality to talk to a wide range of people, be credible to users and technologists, and get their co-operation.
A clear vision of what must be achieved is needed at the outset. Such vision also clarifies what the programme is not going to do, which is an important issue.
The business outcomes must be agreed. Programmes need a business reason for progressing, not a technology reason. The overriding factor is money: if we do this, with these stakeholders, where will the financial benefit be? It could be increased revenue, or ideally increased profit, but it must have true monetary value.
The stakeholders who will benefit financially must be committed, and there must be a contract with them, otherwise the work will be seen as an IT project, and should be abandoned.
The business process at the heart of the programme or project should be simplified if possible before IT development starts. Practice has shown that this can account for 80% of the benefit of a programme.
Technology develops quickly but there is a need to think about how fast an organisation and its staff can cope with major change. Companies should identify the technology involved and consider if it is new, or a first for the organisation: this increases the risk and needs to be allowed for.
Programmes should be broken into manageable chunks to help people understand what is happening and to cope with it. This gives them conviction and commitment. As well as system development chunks, there might be tasks such as training users or negotiating with unions.
Companies should make sure the people needed are available or can be bought. Hiring a third party might be an answer, but the user organisation must have programme management skills.
The contract must lay out clearly who has the responsibility to make which decisions, and it must be managed. Who has to be kept informed? Who is managing the costs? Is there a work breakdown to show how many analyst-programmers are being used, what the function points are, and what the contract programmer costs are?
Projects and programmes should be reviewed constantly. Is this still the right thing to be doing? If it is taking more than 12 months, what is changing in the company that might affect it? Are the people changing, especially the sponsors or stakeholders?
There could be gateway reviews or peer reviews but there should also be someone, perhaps independent of the programme, who can ask telling questions, and kill a project or programme if the answers are not forthcoming.