VIRTUALISATION
How to make a software roll-out fail, part 2 | How to make a software roll-out fail, part 2 |
|
| by David Heath | |
| Wednesday, 16 September 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 the next common one.
Featured Whitepaper
5 Best Practices for Smartphone Support
At the moment, the conversion teams are preparing the data in our legacy (and not-so-legacy) systems ready for transfer into the New Era databases. This includes as much data-cleansing as possible. There have already been some trial conversions with 'interesting' results. It is the outcome of these conversions which leads us to the second part of our discussion on how to make a project fail. It is only now, 19 days from New Era's go-live, that some of the 'expert users' are being given advanced copies of the user manuals and asked for two things. Firstly these users are asked for edits of the manual based on both internal errors and mis-alignment with the software and secondly, confirmation of the workflow within the software, based generally on how it is described in the manual. 19 days??? Surely the workflow should have been confirmed weeks / months ago. Perhaps the bravery levels of the implementation team were so high that they could countenance no possibility of error. That's a pity. As I hear it, there are plenty of things to fix. Incorrect mandatory status on many fields; strange tab-order (most of the heavy users will be touch-typists); missing data fields etc. never mind the more-difficult-to-test business rule validity. This also exposes the second half of the issue. For some reason, the 'real' back-end servers are not yet available. This means that all training and testing is being conducted on temporary, highly under-powered hardware. Right now, this hardware is coping very poorly with the load. Work activities are running slow or timing out and the testing data is a very poor subset of reality. This strongly influences the level of commitment of the testers and thus the validity of their responses. So, what's the common failure action here? Simple; if the work of the implementation team goes over-time and the CEO-mandated go-live date can't be moved, the opportunity for user testing gets squeezed and what goes live probably won't work properly. Go-live day will be fun. Wish us luck. |
| < Next story in category | Previous story in the category > |
|---|





Tags




