Minimal IT - Use job descriptions to check business acceptance

9 August 2005

Use job descriptions to check business acceptance

IT projects fail when systems are not accepted by the business. You can reduce this risk by writing job descriptions to explain what the system will do.

Even good systems can fail to be bedded into the organisation. There are three problems:

Ownership. The system needs to have an owner or owners, who will champion its use and drive its benefit.
Understanding. The system owners and users must understand the system. There's no value in the bits they don't understand and don't use.
Acceptance. The users must trust the system. The owners may need to make other business changes, such as changing people's responsibilities. Without this, the system will bring no benefit.

You need a way of identifying these problems before you start the IT project. You can then change the project to avoid the problems. If the problems are really hard, you can abandon the project and avoid wasted cost.

These problems are often analysed with models of current and future processes. But most people don't think in terms of processes. You need to make the IT relevant to their day-to-day work, so that they can really understand its impact.

To do this, consider the IT system as one or more team members. For each system or part, write a job description. This should cover:

Responsibilities. IT systems store, transforms and communicates information. State what needs to be stored, what transformations are applied, and what all communications mean.
Links. State with what people and other systems this system will communicate.
Authority. State what authority the system has to apply rules to make business decisions, and what it needs to pass back to be authorised by people.

Write the job description in plain language, with nothing technical. Don't include anything that IT can't do, such as making value judgements, or enabling change.

Now the fun starts. You've got to find a system owner to sign off each job description as a member of their team.

Make it clear that sign off means:

They accept this system as if it were a member of their team.
They understand all the system responsibilities.
All the system responsibilities are a subset of their own responsibilities.
They accept responsibility for data accuracy, the outcome of rules, the meaning of outgoing communication, and actioning incoming communication.
That all links do or will exist, including those required to maintain data.
That they will manage the overlaps with existing responsibilities, and fill in any gaps in responsibilities.

System owners will raise objections. You will need to rewrite, divide and merge job descriptions to get agreement. You might also need to create or change real human job descriptions.

If you succeed in getting sign off, you will have a specification of an IT system that can be owned, understood and accepted by the business.

You may well fail to get sign off. You might not be able to find owners for all parts of the system. Owners might not accept responsibility for providing input, or managing overlap with existing responsibilities. But knowing this is a huge advantage. It may even give the clarity to cancel a doomed project before it starts, which is the ultimate saving in IT costs.