How difficult is your automation project?

Before you embark on that next automation project, understanding the size of the challenge you are about to face can help you make better decisions around workload planning.

How do you know if your automation project is going to be a molehill, or a mountain? These are some areas that will help you figure this out:

1) Technical Skillset

If you are a control freak (a trait existing in a lot of high performers), having all the technical skillsets to get hands on with the project implementation is a tremendous advantage. I am talking about taking an off-the-shelf product, configuring and setting this up onto your work environment without any external help. You can reduce implementation cost, call vendors out when they misquote you, be able to identify the actual cause of roadblocks when they happen, all which help propel you towards your go-live date.

On the flip side, if you are going into this project with minimal knowledge of the subject matter or the technical skillset, do you have a reliable vendors or consultants you can trust to deliver you with accurate and honest project updates? Will they exploit your lack of technical knowledge with out-of-scope billables hidden behind that wall of technicality? Heavy reliance on other parties increases your risk of drowning in follow-up emails and calls, or battling issues that you have little to no understanding on, all which would cause significant delays and frustrations in your journey.

2) Budget

This goes without saying, that a project’s budget size has a direct correlation with the amount of work required to get buy-in from the budget holders providing it to you. This involves business cases, cost saving analysis, anticipated benefits, full process and context maps of the solution, even before a single cent has been approved for the project.

The best scenario is when you can select products where the skillsets involved in implementation already exists in the organisation (or yourself). This will keep implementation costs internal or close to nil, with only licensing costs to factor in. Eliminating third party reliance for implementation will significantly flatten your budgetary challenges.

If this is not possible, choose a product with multiple ‘resellers’, as it enables you to send the project out for a range of quotations to get an accurate market-place view on both implementation, and ongoing costs. You should also be using this process to review vendor integrity via their current and past clients. A common practice with external vendors is to push in additional bills that were not part of the original scope during implementation, deeming these to be necessary functions. When these ‘scope creep’ bills occur, you need to dedicate effort to pushing back on these costs, all while managing a delayed timeline. If you cannot win this battle, you need to revert to your budget holders to request additional budget with a full explanation. These additional efforts can significantly delay go-live.

3) Scope

Depending on your organisation’s culture, a wider stakeholder group affected by the change, may also be met with much more resistance, which increases the amount of engagement you need to do before-hand. A higher number of affected stakeholders also increases the expectation of timely updates throughout the implementation process.

Constant communication is good, however being able to maintain some discretion around the timing of interim milestones doesn’t hurt to navigate around unforeseen issues, that may otherwise be exaggerated by that overly cautious stakeholder when they catch wind of a delay. You should therefore expect more time dedicated towards communication with a wider project scope.

4) Governance

Your manager, or company policy may require you to the seal of approval from the digital team. This process could significantly add to the work involved, especially if digital requires detailed diagrams and have security concerns they need resolved prior to approval. I am not critiquing this process, in fact this process of governance helps safeguard your project against failures from a number of aspects, as it adds a second set of skilled expertise to examine your project build, and potentially identify important areas you may have overlooked.

Not so long ago, I developed an automation product within 3 months, production-ready to be rolled out, only to spend another 3 months drafting out contextual, data, and security diagrams