I admit… I am a big fan of tech. The clue’s in the title.
The developer inside me relishes using the latest frameworks, refactoring existing code to use best practice design patterns, and creating systems that automate and facilitate. There’s a big part of me that wants to use cutting edge technology to deliver an innovative solution to a business problem, even (or especially) when the business doesn’t know it needs solving.
But there’s another part of me that knows that this sort of pure tech-led process only really works in a world where there are no such things as budgets, time constraints, and legacy code.
In the real world it makes more sense to build a system using tried and tested methods – to deliver a solid solution that does the job simply and elegantly without the fuss or mess.
You see, tech for tech’s sake can be dangerous. Tech is a tool and a means to an end but, more and more, we seem to see it as a goal in-and-of-itself. We celebrate tech and digital without focusing on the end goals. Left to our own devices we can often over-engineer things and produce bloated and unwieldy solutions.
Here are three key questions to consider when scoping out a technical project.
Do you really need it?
During a short scoping session with one of our clients we sat and watched as they mapped out a bewildering array of third party applications, libraries and processes they had in mind for their business platform. They had already decided on an array of systems that would support their product and let them scale.
I stopped them half-way through their presentation and asked them a simple question… why?
After all, their core idea wasn’t particularly complex. It wasn’t even tech related. A large, technical build could solve many of their problems, but at such an early stage – and still pre-investment – a short and small-scale validation process would help narrow the focus and refine the project scope.
So the first question you should ask yourself when scoping out a project is “do I really need the tech?” We live in a world where tech is everywhere and we often assume that we’ll need some sort of app, system, or online store to be a success.
But do you really need tech to get your product up and running? Could you benefit from doing a little more leg-work to begin with before investing in the development that would allow you to scale?
Do you have the budget?
It is really important to set a budget for your project.
Now this may sound like a super obvious thing to say but this regularly gets overlooked (especially for internal development projects).
Set your goals for the project and then decide on a budget. Communicate this budget to your team. Workshop the solution with the architects and developers and make sure everyone understands all the factors involved in meeting these goals –
- What sort of existing systems are in place that you may need to work with (or around)?
- What the load is likely to be?
- What would be the ideal tech stack?
- What expertise does your development team have?
- Are there any potential issues or blocks to the process?
If it turns out that the goals aren’t achievable within this budget, either adjust the budget or adjust the goals. Either way, at the end you should focus on architecting a realistic solution.
If you don’t make sure everyone understands and accepts the budget and goals of the project then there are two likely scenarios. In the first, your development team works long hours to deliver something that could have taken half the time if they’d really understood what you were trying to achieve. In the second, the project overruns, overspends, and might even fail completely.
Can you maintain it?
Having the perfect system developed using the right technologies and frameworks is really only half the battle. Even the best system quickly becomes worthless if you don’t have the ability to update and maintain it in the long term.
So when you’ve decided on a technical solution to a project, make sure you’ve got the team in place to support it in the future. Be confident that the code is easy to update and maintain. Make sure you’ve used frameworks, languages, and solutions that are supported by a community and are widely considered to be industry standard.
If you do this then, if the worst happens and your development offices are hit by a meteor (it happened to me once), then you can take some solace in the fact that you should be able to find other developers who can manage and support your platform.
In conclusion
Here at Fablr we have a detailed scoping process which aims to understand the requirements of a project before we get anywhere close to suggesting a technical solution. We make sure we understand what existing systems are in place, as well as the budget and organisational constraints and requirements connected with the project.
Equally we are always learning and growing – developing new business analysis tools, learning about scalable technologies, expanding our knowledge of existing frameworks and technical solutions, and working with other organisations to refine our toolset.
Walking the fine line between a well built platform and a sensible solution is always a tightrope walk. With a little common sense and a bit of perspective you should be able to find something that delivers your goals in an elegant and sensible fashion.
Or you could just give us a call and we’ll be happy to lend our hard-won expertise. 😉