When a client encounters a problem with their existing system, or has new business process implementation planned (thanks to growth of technology or the scope for innovation), it’s often tempting to look for an immediate solution and rush into implementing it. Taking a slower, more considered approach can prevent future issues arising and ensure the client is happy with the end result.
Defining a problem or an ask, both in technical and functional terms – from the client perspective as well as from the team’s own understanding, is crucial to nailing down exactly why a certain solution didn’t work, or what the new solution needs to achieve. Finding out as much as possible about what went wrong or what needs to happen will help the team identify future goals for the new system being built.
If the solutioning process is successful, the client should not hit the same problem again. The key is to make sure the solution is future proof so that the same issues don’t recur.
Finding effective software solution requires an Agile approach: breaking tasks down into smaller chunks makes it easier to check in with the client at each stage to ensure issues are detected whilst they can still be easily changed.
Throughout the process the team must be mindful of time, skillset and cost, being careful not to make quick, ill-thought-out decisions that will negatively impact the build.
If a problem can’t be solved because of the technology stack itself, a better solution needs to be found.
This should be chosen carefully; just because there’s a flashy new technology on the market, doesn’t mean it will be suitable. The solution must solve the client’s problem, and the team must be capable of doing the job.
Cost and time implications for each decision must be factored in, as well as the team’s capabilities and whether it can deliver the proposed stack. Think about:
Cost
Assess the client’s budget/pricing. Are they happy with the proposed licensing costs, or should the team be looking at an alternative, technology option? Are they happy with the model, or would they prefer a cloud platform that offers immediate solutions once they purchase the license?
Time
The time that the tech stack takes to implement is an important consideration for the client. They should fully understand the time involved in commissioning a Java, .NET solution, or website build, compared to a solution using Dynamics or Sales Force for example, that would take less time to implement.
Remember to factor in time for the resource to explore the proposed technology and learn how to implement it. These delays are often not accounted for.
Skillset
The technology might be great – fancy, affordable, exactly what the client wants, but irrelevant if the team doesn’t have the right skillset to be able to deliver it.
Getting this wrong and committing to something the team doesn’t have the capability of fulfilling in-house, adds to the overall cost significantly.
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.
Documentation
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.
The more time spent planning the new solution, the more chance there is of getting it right.
Decisions on which stack or system to use should be influenced by multiple factors. Thinking more widely about how the change will address the growth of the organisation, or the data the system is holding, will result in a much more robust solution that stands the test of time.
The benefits of Agile can be significant to a business, particularly in the current era and upcoming turbulent times we’re likely to be facing. Scrum master and Agile Lead, Tom Clark shares the benefits of ‘real Agile’ and how to avoid the buzzword version.
Headforwards founding director Toby Parkins shares his thoughts about how Agile approach can help businesses innovate in challenging times.
Unique to Headforwards, technical sprints offer valuable time for analysis, reflection, and upskilling. Product Manager Owen Hodge explains the wide-ranging benefits for all.
Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770