VIRTUALISATION
How to make a software roll-out fail, part 7 | How to make a software roll-out fail, part 7 |
|
| by David Heath | |
| Thursday, 15 October 2009 | |
|
Rolling out a major project (ERP for instance) requires that a lot of complex factors are brought together harmoniously. However, such a project can be brought down by more mundane choices; here's my next insight.
Featured Whitepaper
5 Best Practices for Smartphone Support
The project has been over five years in development and it is becoming very clear that the project team has missed one fundamental, crucial part of any project delivery (aside from the all-too-obvious functionality gaps). All around me, I hear people trying to come to grips with the new system; cursing all the while that everything is different; that the workflow doesn't make sense; that previous data has been mis-converted; that existing well-established business rules no longer apply; that large chunks of it plain don't work. Now, putting aside the bugs and other errors in the system, the project team has clearly violated Rule 1 of "Change Management 101." Get buy-in from the users. There has been no program to capture the "hearts and minds" of the people most affected by the changes. If time and resources had been spent on explaining "what's in it for them," the front-line staff would have approached the new system with much less anger and scepticism. Note that I said "hearts AND minds."
Those are two very different targets for the education campaign. It is a pity that neither has been addressed to any significant degree. Unfortunately, you can rest assured that senior management are STILL being assured that the roll-out is progressing smoothly. However, to counter this, plans are afoot to go to “Plan B;” re-start the old systems to get some product flowing to increasingly irate (nay, angry) customers. We are definitely living in interesting times! |
| < Next story in category | Previous story in the category > |
|---|





Tags




