Over and over, we hear the same thing from our clients… they’ve had horrible experiences getting an app or website built and out to market. We’d like to offer our Top Ten tips to help you get your brilliant app, platform or website built (and avoid being burned by digital projects!)
These tips have a slant toward development projects, but the general ethos applies just as well to all types of digital projects.
If you’d like a little more context to this post, you can read part one here – but it’s optional.
Tip One – Have Goals and Share Them
Every project needs a set of outcomes… really clear, honest, genuine ones – ordered by their priority. They don’t really even need to be that detailed, but they need to exist.
Lots of projects start with the business stakeholders defining these, writing them down, and then locking them away in a drawer. When they engage with a development team, these goals aren’t communicated… so the team starts off, usually with your best interests at heart, trying to achieve what they think you want them to achieve, not what you actually want to achieve. Good teams will ask, but good clients will also share.
For example – is your project trying to disrupt an existing marketplace? Is it simply a basic platform designed to ‘tick a box’ for your customers? Is this an idea you want to expand to be your own primary business – or just an additional revenue stream. All these goals are surprisingly relevant to your developers, as they’ll help them understand what drive you (and therefore the project.)
Simple tip then – share (relevant) project goals with your development team.
Tip Two – List Features and Prioritise Them
Another simple one that follows on from having goals – list the features you want to include within what is being implemented, and prioritise them to match the priority of your goals.
Everyone who loves their idea, loves thinking and talking about features. More often than not, you are designing the cool features in your head first, or on the back of napkins, long before you start thinking about the basic features like logins and registration. That’s fine, it’s what makes having an idea such a creative process.
To give the team delivering your digital project the best chance, list your features and give them a priority. This will make EVERYTHING that follows go much more smoothly. And if you have a delivery team that works using Agile methodologies, this will be part of their process anyway.
Tip Three – Be Flexible about Your Features
This next tip is a little bit less simple, mainly because it starts to overlap with agreed contracts and MONEY, the greatest frustration causer of all.
When you start a project, you probably have a list of 20-30 features you’d like to get into what is being delivered. Hopefully, they are (realistically) prioritised based on your desired outcomes.
From experience, if you begin your project with the intention of getting all 30 features delivered – and even worse, if you contractually agree that ALL 30 features are delivered in order for some or all of the payment to be made – your project will almost certainly fail. Every project drops a feature or two, features get absorbed into other features, the developers run out of time, something turns out to be way more complicated than they expected to achieve… etc etc.
If you hang everything on every feature being delivered, you are guaranteed to be disappointed – and that frustration (and fear of failure) you impose on your development team will most certainly not lead them to doing their best work. So… let a feature go, or… see our next Top Tip.
Tip Four – Phase Your Delivery
When you have your features prioritised, to match the priority of your outcomes, then you are in a good position to create realistic, achievable delivery phases.
At the same time as planning the features of your digital project, you’re likely to be thinking about the general strategy of how to get it out there. Phased sets of features should both align with and help drive your delivery strategy – as you match things like marketing and revenue plans to new feature sets becoming available for your users.
If you work in a Lean way (which is whatever that means to you) then you’ll likely be looking for a first phase of delivery called an MVP – a minimum viable product. This is a version of what you are delivering that contains the minimum number of features to make it viable. If you approach your project as delivery phases from the very beginning, then a handful of features moving from one phase to another really shouldn’t be too horrifying to you.
Tip Five – Plan a Demo Phase
Small, useful tip here – so you’ve defined what your MVP looks like, and it contains the absolute minimum amount of functionality, right? Maybe you have a cost for that MVP, say it’s £10k.
Imagine you could only raise half the money for the MVP, but you are still desperate to keep momentum going. What could you achieve with a £5k demo version of your £10k project, that would help you secure traction and/or funding? We’re talking basic designs, creative only screens (with no interaction), interactive wireframing… there are lots of creative ways to get something that at least looks like your final version, for when you’re not able to get it all completed in one go.
Tip Six – Create a Functional Specification
As I mentioned in my last post, I’ve been a Business Analyst for over a decade. My role has always been split 50/50 between gathering requirements and analysing them, and writing them down in functional specification documents. When I first moved to working for a web agency I was genuinely shocked to find that these documents didn’t really exist in any standardised or uniform way. How were agencies getting the requirements right without a spec? How were the clients taking the risk out of the project? How did they know they were paying the right amount of money?
It turns out that at (good) agencies there IS a spec, but it’s not usually in a single document – it’s in the wireframes, in the notes that the sales person writes, it’s in the time estimates the developers create for the features. The reason for this is that agencies traditionally don’t hire Business Analysts, especially not smaller agencies – but the elements of their job are still being completed piecemeal by creative directors, sales people, development managers, whoever cares the most usually.
In large corporate projects, you couldn’t dream of getting the budget for a project signed off without a spec – whereas most digital projects in web agency land are signed off, sometimes several £100k, on the basic of a 30 minute pitch and a few conversations. LightStart believe this is an incorrect approach – we always create a functional specification before we accurately provide costs and timescales. However you might not be able to apply this approach.
At whatever point you are able to – before or after you have already signed on the dotted line – make sure there is a functional specification document. This should be a living, breathing document containing all (non-technical) elements of your project. Good agencies will suggest or provide a version of this – if they don’t, ask. And if you want to see what a really great functional spec looks like, come speak to us! 🙂
Tip Seven – You are already an expert
It’s your idea. You came up with it, you are probably a bit in love with it. Great, that’s a good place to be. You are the one and only expert on that first version of your idea that lives in your head.
In terms of functionality, regardless of what designers and developers might tell you, ANYONE can be an expert – on day one. If you think something should swipe, or be clickable, or pop-out, or do some super genius bit of logic – why shouldn’t it? Your only requirement to get that thing achieved is to be able to explain it clearly to the people who are tasked with delivering it.
Don’t let your delivery team railroad your vision for what you want, unless there is a damn good technical reason why it’s not possible to achieve what you want. It’s their job to explain to you clearly, in the least technical way possible, if something can be achieved of not – and to suggest the closest alternatives (see the next tip.)
Challenge them (respectfully but directly) on any area of functionality they aren’t able to deliver. Good delivery teams will respond well to the challenges, without becoming overly defensive or frustrated. If they do this early, probably don’t work with them because that’s not going to go away really.
Tip Eight – Your delivery team are also experts
When you start a project, if you are looking for a 3rd party to work on it, it’s almost certainly because you don’t have the skills to create what needs to be created. So you’re usually looking for the cheapest expert you can find within your budget to create it for you.
Clichéd Analogy Time: You (probably) wouldn’t employ a mechanic to fix the engine of your car, and then stand over them pointing out and questioning their every action. If you did, you’d end up not getting your car fixed. At the same time though, you would approach a mechanic with as much detail as you can provide as to what symptoms you are seeing, and what you’d like the outcome to be. A good mechanic would listen, and not keep saying ‘that’s irrelevant’ to everything you mention. Similarly, a good mechanic would explain in non-mechanic speak exactly what has been achieved, what it cost and why. A good mechanic would call during the work if something was discovered that radically changed what they are doing, or the cost.
This is exactly what you should expect from a healthy relationship with your experts:
- To be able to provide clear requirements to your experts
- To have those requirements played back (or put in a spec!) by your experts, in a way that demonstrates your common understanding
- To let your experts get on with doing the bits you aren’t able to do yourself – the reason you are paying them.
- To have the experts explain to you exactly what has been done in plain language, both at the end of your project but especially during, when requirements or outcomes change
If all these activities are allowed to happen, then you have the best chance of a project running smoothly and avoiding a buildup of frustration and bitterness.
Tip Nine – To the best of your abilities, pay the right amount of money for your project
Digital projects can cost large sums to deliver. Behind buying a house or a car, if you are setting up your own business, paying for your digital project to be completed might be the single largest ‘big ticket’ item you pay for.
There are digital agencies out there who are trying to get you to pay too much money for your project – and if you go into a project without at least some spec, then you aren’t in a good position to call them a liar! However, almost all agencies are just trying to make a living – to pay their staff, to run a good project, to do your project justice. Time is money, and mostly people are asking for the time to deliver a project without killing themselves, you, or each other.
If a company tells you your project will cost £20k, and you have £15k – you really only have a handful of choices. You can find more money and pay the amount. You can try and haggle – it’s usually over-keen agencies that will agree to this, or agencies with fake inflated day rates. You can go and find someone else who will do it for £15k – which might be possible. Price is no indication of quality, that’s why it’s perfectly fine to ask for as many examples of previous and current projects as you need to feel reassured.
If you speak to ten delivery teams and they all say it’s £20k, and one says it’s £10k – if you pick that one, your project will almost certainly fail. They’ve not understood your requirements, or they are undercutting to just get the work.
Basically – wherever financially possible, pay the suggested amount, and accept the suggested delivery timeframe. We have a rule – we don’t work on projects where the money isn’t correct, we don’t work on projects with in-achievable timescales – and we don’t work with people we don’t like. Mostly, we like people who want to work on realistic projects where everyone is being paid the correct amount. Those projects naturally go smoother, and the quality of the output is naturally higher.
Tip Ten – When you break up, stay friends
Every relationship between a client and a digital service provider comes to an end eventually. Companies grow, companies fail, their requirements change. Those types of breaks in relationship happen naturally and organically, and while they can be sometimes devastating to a provider, they are more often than not, entirely unavoidable. Providers do their best to keep them, but sometimes it’s out of their hands.
The OTHER type of breakup is the one we are trying to avoid with our advice here. Communication breakdown > Frustration > Mistrust > Anger > Bitterness. If you are frustrated, that can be resolved. Mistrust is… reparable, but more difficult to address. By the time either side of the relationship is angry, it’s all over.
Knowing that these are the kind of stages you’ll go through means you can try and correct things. Be open, direct, honest. Stay calm, don’t become accusatory if you can avoid it. Write lots of things down together. But – and this is the important bit – you need to move on as smoothly, painlessly and as QUICKLY as is achievable. It’s hard, and a lot of projects that go to the bad have a very long tail while you try and extricate yourself from a contractual relationship. Regardless, it has to happen because its poison to your business, your motivation, your finances, your creativity. Whatever it is, it’s really not worth it.
A lot of time, as we said earlier, if you started working with a team who responded badly to challenge from day one, then it shouldn’t surprise you when this explodes when you have to talk about why you want to leave. If that hasn’t happened, then definitely do whatever you can to end things amicably – no one is every 100% to blame in these situations. The only way to feel better is to get on.
That’s our Top Ten Tips to avoid being burned by digital projects. We hope you find them useful – there’s a lot to take in, we know, but relationships are complicated! Being flexible, open, honest and amicable wherever you can – and having a spec – should help your projects to run as smoothly as they can.