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 a digital agency, Red Bullet 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. 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 as that. For us it is just an important step. We can’t possibly suggest a solution 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. They believe a 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 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 Brief, often in the form of Tenders
I’ll try 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 get 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, 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. 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 longer 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.
At Red Bullet, 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 piggy back off existing systems or act as a middle layer aimed at increasing efficiency.
The moral of the story
Simple really, spend some time up front 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.
A few highlights below:
Temple Legal Protection — A case management system for legal insurance clients http://redbullet.co.uk/portfolio/temple
European School of Osteopathy — Streamlining their admissions process through UCAS — http://redbullet.co.uk/portfolio/eso
Cormis — An online assessment tool to improve event management — http://redbullet.co.uk/portfolio/cormis