money-bank
saving you time saving you money saving your sanity!

How to save money on your next project

: 760 words, 3-minute read

Companies can burn through obscene quantities of cash building IT systems. Consider government projects: how many are successfully delivered on-time and on-budget?

Fortunately, there are ways to minimise your initial outlay and get the best-value solution in the shortest possible time. But it will involve some effort on your part…

Identify the outcomes

Who knows more about your business? Is it you or a random developer you contacted on Twitter?

if you fail to plan, you are planning to fail Benjamin Franklin (probably)

Projects often fail because no individual in the client organisation fully understood the problem before a solution was devised. The reasoning is vague so the result is poorly-conceived.

Step one: identify your business objectives. For example, you want to:

Ideally, write a high-level requirements document which identifies essential outcomes before consulting anyone. Nothing is set in stone and some objectives may be impractical, but it’ll give you a solid starting point for discussions and estimates.

…but stop thinking about solutions!

An objective may lead to the development of a new website or application but that is not an objective in itself.

A good developer will recommended solutions consisting dozens of technical and non-technical options with their own risks, time scales, costs and benefits. For example, keyword research and online advertising could increase turnover within a few days. That could lead to longer-term options such as optimising the information architecture before releasing a redesigned website.

we want an app! everyone since 2007

Unless you’re a developer with up-to-date knowledge, avoid considering the technologies your project requires. Suggesting use of DatabaseX or LibraryY is a distraction at best and a costly mistake at worst.

The best system architects will recommend cost-effective technical implementation options based on your requirements. That’s what you are employing them to do.

“How much?” is a question for you

Would you enter a car showroom and ask to buy a vehicle without revealing how much you want to spend? You could, but while you may be considering a Ford, the sales person is thinking about a Ferrari. Revealing your budget saves considerable time for everyone.

The same is true for IT projects. A five-page website could cost £500 or £50,000; both do much the same thing, but one could be slicker, faster, have more functionality, bespoke imagery, works on more devices, can be installed, works offline, is heavily promoted, has after-sales service etc. Would either satisfy your business objectives?

your budget and schedule determines what can be achieved

If you want the best-value fixed-price solution, your budget and schedule determines what can be achieved. Base it on the desired outcomes, e.g. if product support costs X but there are opportunities to halve that, a budget below X/2 has a clear benefit. With this information, a developer can suggest cost-effective solutions. There will still be caveats because it’s an estimate and every project is a step into the unknown.

Forget revenue share options

I have a fantastic idea: you develop it and we’ll share the millions! doomed start-ups

Perhaps you have an amazing idea but, if that’s the case, you should risk your own money or seek investment. Why offer a percentage of your business to a random developer who may not be capable and or committed to delivery?

You’re actually asking a developer to invest their time: a far more valuable commodity than money. While they’re working for you for free, they cannot charge for other projects or work on their own applications. It’s a double hit.

Only consider a revenue share if you know the developer well and you are willing to offer them a legal partnership, team, salary, bonuses, etc.

Perfection is futile

No system is perfect. Applications can always be better, faster, easier, more attractive etc. Even if you reached perfection today, tomorrow’s technologies can improve your system further … or make it obsolete.

Presume your new application was 80% completed within one month. The core functionality is implemented and the product is usable. Would you wait another year for the last 20% of features? That’s a year without users, feedback or revenue? Many organisations do exactly that.

The best approach:

  1. Identify essential functionality to satisfy business objectives.
  2. Develop a Minimum Viable Product (MVP) and launch as early as possible.
  3. Evolve the application in response business objectives and user feedback.

If you do nothing else…

Stop reading this, clarify your idea, write that requirements document, then contact us to discuss it further!

Best of luck.