How to make your digital tool a success

Effective stakeholder and community engagement

 
Lots of people don’t like change, and engineers are no exception to this. We rely on our rational, logical brain and we are slow to trust ‘black boxes’ of technology. Therefore, when trying to develop tools to automate and enhance the engineering workflow, it’s essential to get the people who are going to be using them engaged early.
 
There are several ways I’ve tried to do this, all with mixed success. The key is to use as many channels as possible. This makes the development and vision of your tool or methodology so much easier to implement.
 
 I’ve found the following works well:

• Briefings before, during and after development. This can help with getting volunteers for testing and people who are interested in guiding the tool. During these briefings it’s essential that you show how your tool or methodology fits in the current workflow. You must also demonstrate how the tool will impact on the lives of the users
• Specific user focus groups with testing and feedback right from the start of development. I’ve traditionally run these with one or two users at a time. I get feedback on how they would use a tool on a specific project or in a specific situation
• Post-release project support, initially offering specific projects dedicated support to use as case studies and presentations

It’s important to limit the problem space

 
Often when developing tools for the structural engineering community, the problem you are trying to solve is massive. With these types of problems, you are also dealing with numerous requests from the community.
 
During the development of my new methodology, I constantly faced comments such as ‘it looks great, but it would be even better if we could add x’. These comments are fantastically helpful, but your scope can quickly spiral out of control.
 
In order to combat this, I suggest forming a robust steering group for your tool or methodology. This should be formed of people whose opinion you trust, and will guide the project to a mutually beneficial development.
 
I filled mine with the technical and project leaders from my company, to ensure I had a technically sound, yet useful tool. Using this steering group, I could make use of agile project management methodologies like Scrum to prioritise requirements and handle the constantly evolving problem space.
 
 

The value of diverse development teams

 
When I start working on a tool, it often takes a few days to develop an idea or principle before I can show it off. During this phase, it can be tempting to isolate yourself to get your thought processes in order and think through the tool. However, you need to do the opposite of this.
 
To build robust and useful tools, it’s important to have a diverse development team, or at least a diverse steering group. This ensures you have considered the proper range of requirements, and that your logical flow is not siloed.
 
The benefits of this are:

• Your tool will consider a wide enough range of variables and parameters to be useful for project teams to implement
• If you leave or hand the tool to someone else, it’s not just a black box. Whilst code commentary or producing documentation is never particularly fun, it does allow for collaboration which enhances anything and everything you do  

Ultimately, if you want your tool to be a success, you need to focus on people. The users will make or (quite literally sometimes) break your tool and its acceptance within your business.