Enterprise Compliance Today

IT Temple of Doom II: Compliance Software Implementation Rules 1-5

Posted by Greg Carroll on Fri, May 31, 2013 @ 11:00 PM

10 rules to ensure a drama-free IT project

Part 2 of a series on successful rollouts (see Part 1)


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. Success depends in part on approaching implementation as a change management issue, not an IT project.

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. So with all the good intentions and enthusiasm what happened? Well here are my 10 rules to ensure a successful enterprise compliance software implementation. This week I will look at the first 5 rules that cover starting the project and next week I will cover rules 6-10 for running a successful IT implementation.

1. Don’t outsource requirement planning

Just as executives cannot outsource strategic planning, operational management must do their own requirements analysis and specification. The 80/20 rule is well accepted in systems development and with that, 20% relates to the exception requirements. It is also well recognised that this 20% will cause 80% of your future problems, and is where your outsourcing cannot help. 

Understanding the intricate fine details of exceptions comes out of experts (you) analysing your operations. Not only does it allow you to orient your selection criteria to those key items that will make a difference, but it is one of the best ways of getting operational staff to buy into the end product, which is another primary rule of success (see No 10).

2. With software vendors, big is not the best

The problem with the major suppliers is that they are jack-of-all-trades and experts in none.  With the high mobility of IT staff (Gen-Y), and the broad range of industries covered by large suppliers, you cannot get the same expertise from employed BAs as from a small niche company where the owner and topic expert is directly involved in your implementation. With large vendors having an average 18 month implementation project timeline, it is difficult to find staff who have experienced one full project implementation - let alone in your industry and type of business. 

Obviously you need to avoid cowboys, but there are loads of small niche providers built by professionals who earned their experience in a large firm. By far a small provider with a proven track record in formal project processes, familiarity with your industry, size of business and a proven solution, is more likely to produce a successful outcome than any large provider.

3. Choose a ‘people’ Project Manager

One of the best Project Managers I have worked with over my 30 years, and who managed the Fast Track installation for Yarra Valley Water, would say that Project Management is 80% art and 20% technical. Certainly, the 20% technical management of the process is important, but the 80% art of managing a wide range people with competing goals, egos and work ethics is key to a successful installation. There is always politics, the lazy, the overworked, those not interested, and those with want it to fail. The trick is getting them to work together to succeed.

Sadly today the IT industry is full of technically trained Project Managers. Worse than no project manager at all, they not only lull the sponsor into a false sense of security, their adversarial approach to the project will almost guarantee failure.

4. Have a living risk management protocol

Probably the bigger mistake in project management is how risk management is treated. It is rare that it is anything more than a tick in a box. Generic assessments, no mitigation planning, no periodic review make most project risk assessments a bureaucratic waste of time. I have lost count of the number of times I have sat in project meetings discussing how to handle issues that occurred during a project, or excuses for delays due to ‘unforeseen circumstances’.   

After identifying the project stakeholder, they should be trained in risk management principles and on writing risk assessments. All stakeholders should prepare practical risk assessments, including critical control points and mitigation planning, which need to be reviewed continuously. It is a method of management not a document to be completed and filed. It is not unusual to lose key personnel, to have IT technology changes, and to have contract variations. If comes back to preparing, identifying and handling these events, i.e. risk management.

5. Ensure all stakeholders have ‘skin’ in the game

Believe it or not, I was recently involved in an installation where, as the software vendor, we weren’t allowed to talk to anyone in the end-user business unit. We could only deal with IT Business Analysts. Conversely, I have been in projects where IT wasn’t consulted until the point in installation. I have also experienced the pleasure of attempting to implement systems imposed on users by an all-knowing IT department. When put on paper all these options look equally ridiculous, but it is more common than not that all stakeholders in an implementation are not even involved in the project.

But more than good coordination, having ‘skin’ in the game is ensuring all key players are equally assessed on the success or failure of the installation. This is counter to most projects that have a specific sponsor, which actively encourages internal politics. A small group of senior management working together should be held accountable, just as the Board is held accountable for the company’s performance.

Next week I will cover rules 6-10 for running an IT project.


Tags: Compliance Management, project management