IT success depends not on technology or systems skills but
on executive leadership and managers with both IT and business
experience and clear business vision.
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.