Software Engineering – the build itself
Any proposed solution should be broken into multiple components that can be delivered independently, tested independently, and addressed independently.
This Agile approach means the client has enough time to review the ask and respond, helping the team build a better version of the component. It also avoids developers having to go back to work on bits and pieces once the whole process has been built.
Make the solution as light as possible
Where deliveries and the deployments are concerned, the solution should be light by nature; if you end up with a heavily customised solution, it can lead to a risky deployment. You should be looking at clear, simple customisation and easy integration points for each component.
Don’t over engineer
Brainstorming is very important, but it can sometimes lead to overthinking, creating unnecessary work. Not everything that’s good to have, needs to be there; it’s important to know when to stop and move on to the next stage to avoid over engineering the solution.
Keep your ear to the ground
As a developer, it’s important to stay abreast of what’s happening with respect to the tech you are using – or planning to use. Make sure you’re not using anything that’s being deprecated.
Microsoft Dynamics for example publishes what will be deprecated in the next few months – keep an eye on updates of this kind.
Ensure maintenance is shared
When building the solution, keep in mind that the client should take on some of the maintenance to avoid them having to call on you for every small change. Giving the client control over simple management of the system avoids them hitting roadblocks when trying to do something and improves customer satisfaction.
For future maintenance – any increments or versioning that needs to be done, the document of the initial solution build will be needed.
All parties need to have documentation at the right time at every stage of the solutioning, whether customer, development teams, or functional needs.