Responsibility for implementing an enterprise system can either advance or damage a career. You can have a big impact on your company and your career if you do it successfully.
Like Indiana Jones' fear of the mysterious, booby-trapped Temple of Doom, your wariness of IT implementations is justified. And like Indy (Harrison Ford), you can avoid the booby-traps. The 10 rules outlined in this series of blog articles will help you be successful.
Learn more in the free 10 Essentials handbook »
In this three-part series we are looking at some of the ways an IT implementation can go awry, and some of the ways to ensure success. IT implementations have a 40% failure rate: 25% fail to get to production, and 15% of those that do still fail to achieve their objectives. Throughout my 30 years in IT, I have seen this exact scenario played out time and time again, with little change even given the improvement in management techniques and training. Good intentions and enthusiasm obviously aren't enough.
In Part 2 we went into detail on the first five rules:
- Don’t outsource requirement planning – You know better than outsiders what really counts
- With software vendors, biggest is not always best – Small specialist vendors are your best shot
- Choose a ‘people’ project manager – Have process, but understanding people is the key
- Have a living risk management protocol – Don’t just file. Review and update continuously
- Ensure all stakeholders have ‘skin’ in the game – make them all responsible for success
Now, in the last part of the series, we look at the remaining five rules
6. Use an ‘agile’ implementation technique
Agile methodology is a reiterative process of implementation. Put simply, the client can review progress early on. This helps identify system flaws early, when they are easier to fix. Often they need only minor adjustments that produce a far more user-oriented solution.
Obviously, control and flexibility do not coexist kindly. When using agile techniques in controlled environments, control invariably wins out. That leads to end users not seeing the solution until they are past the point of no return. Long ago IBM figured out that it costs 20 times more to change something in the delivery phase than in the set-up phase, so of course the vendor will resist change once it starts delivering.
Just remember, if users don’t like the system, it will be considered a failure no matter how good it really is. IT has to give agile implementation equal importance with environmental controls. It can be done!
7. A quick game is a good game
Any general will tell you the key to a quick victory is good planning and preparation. But once fighting commences, flexibility and quick reactions to changing circumstances take over. So plan for a short implementation and prepare for possible problems, but ensure your project structure allows fast reporting supported by quick decision-making.
Finish the implementation in less than 12 months. Six months is even better. Don't try to build a perfect solution from Day One. Just as training programs include basic, intermediate and advanced classes, plan three projects. One will handle 80% of the requirements. The second will refine the requirements. The third will deal with the final 20% of the requirements once you have the basics well grounded.
Don't change any requirement or implementation until the refinement phase, regardless of how good it would be. You'll need to think the changes through, as you did with the initial requirements and implementation plans. That can take several months at a minimum. So put off the change, shelve the requirement to phase 2, or develop a work around.
8. Plan your testing
There are books written on it and an industry built around it, but in the end it is up to you to ensure the solution will handle your business. This means firstly knowing your business and secondly that the solution will work in your processes. Don't outsourcing testing. Doing so removes this vital process of integrating the new software into the way you operate.
Unless your vendor is incompetent, the problems will be in the exceptions and handling of micro detail. Develop test plans as you define your requirements. Focus on variations and exceptions and build in real-world problems. Prepare step-by-step process tests that are repeatable for regression testing. Professional testing concentrates on nit picking instead of complex real-world analysis.
9. Training: Sell the benefits
We are all assessed on our performance, not how good we look. Likewise, the success of an IT system is judged on what it does for the business. This, in turn, is the result of how well it is used by those who drive it. Training should invest as much time into selling the personal benefits to operational staff as in telling them what buttons to push. Show them how it can reduce conflict, eliminate boring work and enhance careers. Then target training at common role types so benefits cans be leveraged. Change is always hard, so motivate early adopters first.
10. Treat as a change-management issue not an IT project
In summary, treat it as you would a non-IT project. It is amazing how successful businesspeople with a long record of success in other areas of their business suddenly abdicate management of IT projects to an industry with such a poor track record.
For every dollar you spend on the solution budget, spend two dollars on change management within the organisation. Good modern enterprise systems are not just the computerisation of manual (or automated) systems. They provide a quantum leap in process and delivery and can revolutionise an industry. Just look at the banking sector over the past 10 years, and the effect on their bottom line. You’ll be surprised how much is doable, but to achieve it be prepared for big changes internally.
As I said in Part 1 of this series, responsibility for implementing an enterprise system can either advance or damage a career. You can have a big impact on your company and your career if you do it successfully.