Nobody spends money on new business software expecting it to fail - but failures do happen. Systems don`t work, or they do work but not in the way that was expected, or users flat-out refuse to change the way they do things, or everything ends up taking much longer and costing much, much more than it was supposed to.
If you`ve been around for a while, chances are you`ve seen at least one of these outcomes. And in that case, you probably know your software vendor much, much better than you would like to. Because let`s face it, a software supplier is a bit like a builder - if they`re still hanging around a few months after the project was supposed to have been finished, it`s a sign that things have gone badly wrong.
To put it another way: As one of the people who actually implements software for clients, I know we`ve succeeded when we never hear from the client again afterwards, except for the routine check-in calls. When nobody ever needs to call for help, things are working the way they should be.
The scary thing is that, most of the time, we can tell in advance when we`re only going to get a Christmas card, and when we`re going to end up moving in. If any of these things are true about the project scoping meeting, alarm bells start to ring:
1. There is not a single member of senior management at the meeting.
2. There is nobody at the meeting who is actually going to use the software in their daily work.
3. One or more of the departments that will use the software is not represented.
Any of these omissions can lead to key requirements of the software being left out of the project scope. In this case, everything will sail along smoothly until, somewhere near the end of the project, someone will say: "Oh, by the way, it needs to do X as well" - and the heart of the consultant will freeze and sink to the bottom of his shoes.
It all comes down to one word: ownership. Whose project is it really? If it`s the IT department`s baby, but the people who need to use it are all in finance, you have a problem. You also have a problem if it`s finance`s baby and they want the business to use it; or, just as bad, if IT isn`t involved at all. As in all things, if the people who use and look after something are not the same as the people who own it, it`s going to end up neglected.
So, if you`re about to implement a software system, protect your investment and do it right. Make sure that the implementation team includes user representatives from every department that will be affected - and that those users have been released from other work so they can participate properly. Make sure that your senior executives not only know what is happening, but actively support and endorse it. Let the users select the software, but enlist the support, help and advice of your IT specialists. Identify your champions, and treat them like champions.
Or, you can leave it all to the consultants. Isolate them from the business, avoid the project meetings, pass all the decisions on to someone else and don`t tell any of the users what is happening until they get booked for training. Then spend the next year on the phone to the consultant`s support staff, moan about how inadequate the training was and finally, quietly, write the project off as a disaster and move on. The choice is yours.
Share