Over the last ten years the line between “website” and “application” has blurred significantly. As web browsers become more powerful, the tools and frameworks we use to build for the web continue to push the boundaries in a constant arms race that leaves us with better online experiences.
Wordpress theme marketplaces and hosted solutions like Wix and Squarespace have all but obliterated the market for small, simple brochure sites, leaving most digital agencies with no choice but to enter the software game.
However, actually selling, building, and profiting from software projects can seem elusive because of the difference in how the agency and client view the same thing.
I recently came across this graphic showing software development explained with cars.
Cars are a good analogy to explain the complexity involved in building software and the various methods teams have come up with to make the process run smoothly.
While there are no easy answers, I’ll share what I’ve learned over the years running a digital agency and by interviewing successful agency owners on our weekly podcast.
At the end of the day, it’s about getting the client what they need, making them happy, and making you money.
Size/uncertainty ratio
When selling projects, you and your salespeople need to understand the size to uncertainty ratio.
It’s a pretty simple concept, really.
The smaller the project, the more certainty. As the size of a project scales up, the complexity, and, therefore, the uncertainty scales exponentially.
For every feature you add, there are tens, maybe hundreds of variables that can increase the complexity, affecting both budget and timeline.
It could be that you and the client visualize the feature working differently. There could be technological constraints or usability issues that no one could have predicted. There could be defects that don’t get discovered until QA finds them.
There’s a lot that can go wrong, and it may seem like you’re at the mercy of the natural chaos of the universe.
So what is one to do?
Simply acknowledging reality is the first step.
As much as you’d like to tell the client, “Oh, that social mobile app you want to build? It will take 26 weeks and cost $259,435,” the reality is that you don’t know exactly how long it will take to build or how much it will cost.
As much as you want to make your client happy and add “just this one small thing”, you know it’s never, ever that simple, straightforward, or cheap.
And it’s not just clients who want the easy answer either.
Your account managers are going to want it too. Generally, they’re less technical than your designers and developers, so they’ll probe the production team for the magical answer: “So the client wants this social mobile app. How long will that take to build? I have to get this proposal out later this afternoon. Just give me a ballpark, I’ll pad it by 20% anyways”.
Just stop.
I can smell the money burning.
It’s like how in science you can’t base results on good old fashioned intuition. Sometimes the correct answer is completely counter intuitive, it’s not what you would necessarily think based on your gut.
In a similar way, even though common business sense may be telling you to guess how long something takes to build, come up with an estimate, and then pad that number, it’s completely the wrong way to scope out large projects. You’ll end up losing money and client confidence.
So, step one, get your salespeople on board with reality, and have them educate new leads on the same version of reality right from the start. The reality is: software is complicated and you don’t have the answers up front. Acknowledge it and move on from there.
Discovery is indispensable (but not a silver bullet)
I remember once our provincial Department of Education came to our agency looking for a quote on a project.
They wanted to build an app to encourage high school students to plan for their future careers and match their interests and skills with a profession.
Pretty cool, right?
The problem was that when I met with the group to discuss the project, they had no idea what the end product was going to be. The general consensus was that it needed to be a game, but no one knew what kind of game. Some mentioned “3D”. Others, “first person”. We had nothing.
So Kevin and I tried another approach. We came right out and said it: “How on Earth can we estimate the cost to build something if we don’t know what it is?”
Instead, we suggested selling them an upfront discovery session. It’s where everyone involved sits together and we map out what the final product needs to be. Then we’ll plan the features and functionality, design the screens, and create a rough interactive prototype to show people. Once everyone agrees on what we’re building, we can better estimate how much it will cost to code.
Heads nodded in agreement. This was the way to go.
(In hindsight, I’d also add in time to actually go out and talk to kids who would be the end users.)
The client agreed to proceed with the discovery project, and once we were finished everyone knew a little more about what the app was going to be, how it would work, and what technology we would use to build it.
Your discovery process should be similar, and any reasonable client should see the wisdom in moving ahead with it. It’s like hiring an architect before you start laying down bricks.
What went wrong
We ultimately ended up winning the final development project after it went out to tender. But the story doesn’t end there. We ended up losing money on the build even after we had “scoped it out”.
Here’s why:
The scope of the project was still too big to properly estimate.
We needed extensive illustration work that wasn’t understood in detail.
There was technology required that the team didn’t have experience using.
There were edge cases in the game we didn’t fully think through accounting for.
And overall, the project was just too damn big.
So while we had a much more defined idea of what we were building thanks to the discovery, it didn’t change the fact that big projects have too many unknowns to be precise, and we didn’t know what we didn’t know.
Here’s how I would do it now:
Sell sprints
In agile development, a sprint is a 2-4 week cycle where you can build a complete portion or feature of the software. By complete, we mean that the feature can be designed, coded, tested, and released within that cycle.
Thinking in sprints is a useful form of encapsulation because it forces you and the client to stop thinking about the big project being “done”, and instead think about all the smaller projects that fit together to make up the whole project.
Your challenge is to convince your client that the idea of software being finished isn’t realistic. No matter how much you plan, design, and test, as soon as it’s out there in the world and people use it you’re going to realize where you went wrong and want to change things.
Software is an ongoing process, like keeping yourself nourished. You are never really “full” until you’re dead. A sprint is just one meal.
With that in mind, I’d approach the Department of Education project differently:
Instead of writing out the entire project as one big, complete thing, I’d help the client figure out the most important first step. The minimal viable product. What’s the smallest thing we can build to start with that will get people using it and providing feedback?
Maybe it’s just a simple interest quiz to begin with. We could build a quiz within a sprint. Sprints cost $X and we’ll learn things along the way that will help build the foundation for the next sprint.
After each sprint you and the client can decide where to go next. You have the flexibility to change your mind after each sprint and focus on a different feature. You can send out what you have to users for testing. You’re both in control.
This enforces some discipline as well. The client may have five features they want built, but once they are face to face with a budget and a deadline for each feature, it forces them to decide what’s really important. That avatar feature is going to eat an entire sprint? Maybe we don’t really need it after all.
Sprints are easier for our simplistic chimp brains to process.
The beauty of this approach is that you get paid for every sprint with no need to work for months on end waiting for a cheque to arrive in the mail. The client buys a sprint, they pay for a sprint and you don’t start another one until you’re paid for the last one. Cash-flow? Yes, please!
Client rebuttals to overcome
This is a different approach than most clients are used to and it naturally raises some questions.
Clients like the comfort, as false as it is, of knowing exactly how much they are paying for something. This approach is a journey and they need to commit to accompanying you on the journey. That’s a hard pill for some to swallow.
Here is some common client pushback and an appropriate response for each:
“I have a fixed budget and I need to know how much I’m spending”
Great! Tell me the most you can spend so we know what we’re working with. Working in sprints will ensure we don’t go over-budget, and we can step back and see where the budget is after each sprint.
“We’re running TV ads in September so it needs to be completely done by that date. Can you commit to my deadline?”
We can definitely have something ready to go by then. Assuming we begin on X date and there are no delays on decisions or payments, we can get 5 sprints done by then. At that point you can decide if you want to keep iterating after the TV campaign or just run with what you have.
“The app needs to have this one feature in particular”
OK, it’s good to know what’s most important to you. We’ll be sure to schedule the sprint for that feature very early on so we make sure it gets done.
“What if I still find bugs or want changes after it’s launched?”
Within every sprint we have our QA team vet the development work done and run regression testing to make sure new changes don’t negatively affect old parts of the code. After the sprint is finished you have X number of days to test on your end and if you find a bug during that window we’ll fix it. Changes however, are worked on within sprints, so any new changes will be pushed into the next sprint.
“I need to put out an RFP so the winning bidder will have to spell out the price, timeline, and exact functionality for the whole thing before we even have a conversation”
We’ll pass, thanks. Good luck with your project.
How to work it into a proposal
So with all this in mind, when you’re pitching a client on a large software build I would outline the big lofty goal the client is trying to solve like, “We’re trying to help high-school students find a career path that matches their skills and interests.”
In conversation, I’d mention the problem with trying to estimate the work up-front and pitch the client on the agile process. Remember, it’s not just protecting your agency, it’s protecting the client as well. You’re carefully building a little bit at a time together and not trying to pretend you have all the answers.
The trade-off is the client can’t have that big shiny number and that exact list of deliverables right at the beginning. But they will get peace of mind knowing that they’ll be more involved in the process, and they’ll see smaller pieces of the product come together and evolve every couple of weeks.
Once you outline the approach and methodology you can outline the high-level goals of the project. The difference is that the scope needs to remain appropriately vague. You aren’t selling a destination (feature X, Y, and Z) you are selling the journey of building a little of X to find out if Z is even needed in the end.
For this process to work, there’s a few conditions:
- Sell the mandatory discovery to outline the big picture, but remember it’s not going to replace the need to build in small increments (sprints).
- Once a client buys a sprint, that’s all that team works on. Your designer, developers, and project manager all need to stay focused on their one sprint. You can’t have them bouncing around to different clients in the same sprint, so charge for the sprint accordingly.
- The project manager needs to keep a very tight reign on the scope to ensure it doesn’t change or grow too big mid-sprint. The project manager is there to protect the team’s time and the agency’s budget. The PM should be conducting daily standup meetings to make sure the project is still on the rails.
- QA testing is as important as designing and coding. You should have a dedicated QA person (not the project manager) and get them involved as soon as the first code is pushed so they can poke and prod. If you wait until the last few days for testing they’ll discover bugs too late and the developers won’t have time to fix them.
- User testing can’t happen within a sprint, but you could sell the client on the idea of sending it out for usability testing after the sprint is complete and the client’s had a chance to play around with the app.
What do you think? Have you tried this approach? I’d love to know what’s worked and what hasn’t in the comments below.
