HSEQ / WH&S / OH&S Software Roll Out – How To

Having undertaken many roll outs over the years from single seat to enterprise and multi-national deployments we understand the pressures organisations face.

One Size Fits All – Forget it!

Whilst there are definitely high level check lists involved in a migration there is no “one size fits all” play book to follow. This is because your intellectual capital exists in:

• Systems
• Paper records
• Documents
• Processes
• People & ideas
• 3rd party external factors

One of the early failings is to not include coal face stakeholders and external responsibilities in your thinking. Failure to do this means that when you promote your shiny new solution to internal stakeholders you will hear “that won’t work because…..”.

Apart from the lack of user buy in you will encounter problems that could have been avoided if you had taken a 360 degree approach from the outset.

Roll Outs Are Cheap – No they are not!

To build and execute a project plan requires in depth meetings to scope out detailed assessments of requirements and how the solution can deliver them. Some costs can be managed by taking work back from your vendor and bringing it in-house. This means the quality of your output must be comparable to that of the vendor.

An example would be providing employee details data. The vendor’s system may require a six digit BSB number. Many systems, including banks themselves add a dash in the middle, requiring the person entering or bringing on the data to sanitising and repair the data.

This example refers to one column in one table. There are thousands of columns and hundreds of tables in modern databases. If the data is wrong then it the roll out stops until it is fixed. As extractions often happen late in the week this means another extraction being required the following week, and the cycle continues, adding to costs.

We recommend having a budget for extensive scoping sessions with stakeholders prior to commencement of the project. The purpose of these sessions is to decide, “can that elegant solution be deployed” or “that solutions sounds great but will cause project challenges and financial blow outs”. Either way the scoping report will be your organisations project blue print for when you’re ready to move ahead – and it’s worth every cent.

The short answer is that if you try to roll out on the cheap with a plan on the back of a napkin then chances are that at best your project will drag on, potentially fail altogether and almost certainly end up costing you far more than an in depth scoping plan would have. Either way it won’t be a pleasant experience for you, your staff or your vendor.

A Basic Template

When you are committed to scoping with the goal of a new solution you should start to discuss a few relevant topics. These include:

• Who should be involved?
  • At least one representative from each user department
  • At least one representative for each job type in your core HESQ/OH&S/WH&S TEAM
    • There is no point just having the HSEQ Manager on the panel and leaving the HSEQ Administration team unrepresented. Do so and you are likely to end up with little buy in or worse still rejection.
• What are the specific problems you are trying to solve?
  • Bonus point: document the current solutions in place that mitigate these problems. A QA test post roll out should be the absence of these solutions. If they are still being used then something has gone very wrong.
• Rate the solutions or features you require at the component level into required, desired and nice to have.
  • If your compliance requirement is evidence of keeping accurate records then downloading a PDF or MS Word document is a nice to have. Say “but we can send it out and….” all you want but the source of truth is the system and not a Manager’s folder in Outlook. The more you leak data from a system then the more you are encouraging people to have processes external to it.
• Write a QA statement for each item on your list. For example:
  • This feature will be delivered when a user can do $x and $y happens
  • This feature will be delivered when a user can close out an action and the relevant stakeholders will be advised.
  • Any vendor will welcome these QA statements because they can validate their instance of the solution against agreed upon guidelines
• Pick your battles: All parties should have a time line for data migration and going live. Expect that all of the required features and a significant percentage of the desired features have been signed off before going live.
  • In defence of all vendors please take this on board: some of the desired and nice to have features will become irrelevant as users become more skilled with the offering. They will find better alternatives and implement them. Don’t waste your budget and the Developer’s time deploying features that have little value just because they were on the first spec. Be flexible and most likely your vendor will be too.

The examples and approach listed here really do (intentionally) paint things in a sobering light. All parties need to know that it takes a collective effort to make a roll out successful. It is prudent to set expectations early and ideally things will become easier as the roll out progresses. The alternative is far more costly and painful for everyone.

Our team at Inertia Technology are here not just to write Enterprise software but also to consult, advise and guide you through the process. You might not be across all of the pitfalls but don’t worry – we are the experts in this field. Drop us a line today so we can take the pain out of your transition and get you using our platform to get the best out of your business.