We all know that the purpose of a project is to deliver some sort of benefit to the business. For many projects, the real benefit is that the end result is being sold. But what about projects that are purely internal? What about projects that are trying to change the business?

I’ve run across a few of these in my time. One thing they all seem to have in common is that they are driven from the top – they are designed to deliver a benefit to the senior management. That’s not surprising – senior management are the only ones who can commit to spending money on them!

But that also causes problems for a project manager. When the project is being put together, it’s always a good idea to make sure that there are also benefits to the people who are going to be affected by the changes. Without their support, the project is very unlikely to be successful.

Let’s look at an example. Quite a while ago, I was working at a fairly large and bureaucratic public body. Their whole reason for existing was to pay for and support projects to support and grow the local economy – business support, infrastructure building, that sort of thing.

Naturally, this meant they needed a lot of information. This information was going to be particularly useful to the senior management who had to report upwards to government. But getting this information could be difficult. So naturally, a knowledge management solution was proposed.

Now, this solution was going to use simple techniques – tagging of all documents with keywords, imposing a defined directory structure, and so on. For the senior management, the promised benefits were great: they would be able to drill down into any area, and all the information would naturally flow into a dashboard view.

But the benefits for the other users were minimal, at best. They already had developed their own directory structures. They knew where all the information was. The problem senior management had simply wasn’t a problem for them.

But senior management’s solution, well, that became a huge problem for the staff! Suddenly they had to start adding keywords before they could save their files, they had to try and fit their documents into a structure they couldn’t control, and so on. There was now a new barrier to them doing their work, without any benefit to them!

When the poor soul put in charge of this project ran the concept past me, I was sceptical. It seemed fairly clear the project was going to be horrendously unpopular, and difficult to get finished due to the resistance it would encounter. But my colleague didn’t want to say anything to senior management – he believed that the staff could be made to use the system through coercion, rather than choice.

Maybe he’s right – but you’re not going to get the real benefits out of a system people don’t want to use. Keywords would be selected poorly, missing out a number of useful ones. The directory structure would get filled with files in the wrong places. The expected benefits wouldn’t be delivered.

Not surprisingly, the project hit difficulties almost as soon as it was started, with resistance from all sides, and pressure from above to get it implemented quickly. It dragged on for far too long, before finally it was scaled back, and the business actually talked to staff about what they wanted to get out of the system.

Always remember that to implement an internal change project, you need to make sure you deliver benefit to everyone affected, if possible. If it isn’t possible, minimise the pain as much as it can be, and realise it is going to cause you problems and delay.

What do you think? What barriers do you run across when implementing change? How do you get the buy-in of the various groups? Let me know!