Considering the WHOLE Spend

What I am going to write about here is not something groundbreaking and thankfully a lot of people already adopt this strategy.

Spend in relation to web application requirements

As an agency, we work on web projects across creative and development briefs. On development projects, where we’ll be creating a web application that solves a problem or improves a workflow, we’ll spend time upfront understanding how people currently do things (thats not just on the screen, it's offline tasks too). This understanding is vital as it helps guide our recommended approach and roadmap to achieve success. I guess this is consultancy although we never really sell it like that. For us, it is just an important step. We can’t possibly suggest a solution or cost from just a high-level brief or aim — it would be an educated guess at best.

Often, that high-level aim comes from management or director level. They know a particular workflow or task needs be done better. Or, they need to replace an ageing system. They believe a new piece of software or web application will achieve that. They will set a budget to achieve this. Quite often all of this happens without any communications with outside parties or end-users. So, even by this point a lot of guesswork has been done and arbitrary budgets assigned. There is already a risk applied to the outcome sought.

Are we consultants? We might just be.

Now, I am not an advocate of the other extreme where “consultants” are brought in at huge day rates to often state the obvious, but there is a middle ground. We don’t label ourselves as consultants, but in reality, a lot of our early work in a project is just that. We are gathering insight, consulting with users, analysing and making recommendations — I’d say that is consultancy. The difference is we do this in plain english and ensure everyone understands what we are doing.

The Brief, often in the form of Tenders

I’ll try to keep my ranting to a minimum here and not touch on the ridiculous nature of the tender world (I’ve done that here: https://medium.com/red-bullet/digital-transformation-tender-pain-does-it-need-to-be-like-this-a6db5447c64e ), I understand that the tender process is needed. What I don’t always agree with is the vague nature of web development tenders we see. The above goes some way to explain how this comes about. The organisation putting out the tender often has in their head that a piece of software is what they need. They’ll assume their problem is not a unique one and so there must be a bit of kit out there that does the job, after all, that must be the cheapest route. Understandably there will be a budget assigned. But how have they arrived at this budget?

The Wrong Way to allocate a budget

We have ￡x to spend this year, we need to improve a process or workflow. We’ll buy a piece of software and choose something that ticks most boxes within our budget.

So, why is this wrong? Well, for simple cases, perhaps it will work, but for more complex requirements you need to consider the overall spend as not just the money spent on the new application. For example, if an existing application or software exists and appears to meet most requirements, it’s likely to be an established tool. Yes, this means low risk, but is likely to mean that it’s cumbersome, bloated, complex to use and hard to tailor for your needs. Consider the end-users, the people using this application day-to-day to make their lives easier. If it takes them 10 minutes to complete a relatively simple task on the tool (something that could take 2 minutes) because the system provided is complex and not intuitive. Add to this time required on training for use of the system (often regular training), support questions, setup and adaptions for use. All of this is likely to add cost.

The End User — don’t forget them

Just thinking of one end-user (an employee of your organisation), focusing on that one task, it’s taking 8 minutes longer than it should. Let’s assume that task is something that is required to be done twice a day. So that’s 16 mins a day wasted. Add that up over a year… using some very crude maths and it equates to around ￡600 a year of wasted money for that one end user*. Say you have a team of 20 all doing the same, suddenly that pot of wasted resource is around ￡12,000. Then add in the time needed for training, likely large costs to support or adjust bits for need. This is not even considering the reduction in time that person has to do the job that they are employed for! You can probably see where I am going here. As I say, not rocket science. Selecting a provider purely based on ticket price is not always the most economically viable option long term.

*based on someone earning around ￡20k per annum

The right way to budget

Before putting out a tender or brief for a large application purchase or procurement, first, invest a small amount in some consultancy. Let someone impartial come in and work out, with you, what you are aiming to do, where your inefficiencies lie and most importantly understand how end-users do things now. The right person would be able to help map out more efficient workflows using digital technologies, present the options and most importantly involve the end-users in the process. This early engagement makes them feel part of the process and after all, if they can feed into the decision, you’ll be saving money in the long run because they’ll quickly adopt the new tool. When allocating a budget for the project, look at the upfront cost, ongoing cost and most importantly other costs or savings you’ll have based on your decisions.

And remember everything online can evolve, you don’t need to have it all in step 1. Start simple, focus on the most important bits and build up the application over time. Make decisions around usage and need. Look at a budget spread over 3-5 years, not all in one hit.

At Bullet Web Development, we’ll often use a mix of bespoke code and existing tools to build something that fits around an organisation’s need or workflow. It’s rare that there will be a one-fits-all piece of kit out there unless the need is common. The more niche your process, the less likely you’ll find something on the shelf that is affordable and suitable. In today’s web, it’s not as black and white as “off the shelf” or “bespoke”. Often the best solutions are the middle-ground, where bespoke applications piggyback off existing systems or act as a middle layer aimed at increasing efficiency.

The moral of the story

Simple really, spend some time upfront to understand what you are trying to achieve and get expertise in to help shape what you need. Consider the whole cost — savings and all — over a period, rather than just a ticket price. And finally, be clear about what you want to achieve — set some KPIs — and they might not just be figures based.

Over the last few years, we’ve had some great success working with organisations to shape web applications around their particular workflows. We’ve often been pitched against existing software solutions in the early stages and spent time with clients to help shape how they could reach their end goals.