Keep it simple and short. Ultimately, that’s what a minimally viable product does. It keeps your software development project on task, which is true no matter what your budget or schedule looks like. Your bottom line should center around creating that MVP.
Your developer is there to help you solidify that MVP idea. Whether you have a fixed budget or schedule, make sure you can paint a clear picture of your vision. That way, your developer can take your ideas and help you identify the highest valued thing they can work on.
When a prospective client first approaches us, they usually have this grandiose idea. It can be difficult to narrow down that idea into a minimally viable product. Don’t get us wrong; big ideas are great, especially for when you’re ready to scale up. But from the get-go, you should be able to scale down that idea. Be ready to figure out the smallest part you can sell and start making money right away.
Think about it this way: All businesses function kind of like a snowball. To grow your business, first figure out what’s the smallest snowball you can make. Then, start rolling right away so that your snowball can start accumulating.
The only way your developer can help you identify your MVP is if they stay in lockstep with you. This is especially true during the initial stages of your product. That’s why solid, open communication with your developer is key to a successful project.
A clearly-defined MVP will help your developer stay within your budget. It also keeps everything on schedule. (For us, your budget and schedule are heavily intertwined because we charge hourly.) Understanding how critical your MVP is toward your bottom line will turn your idea into the truly valuable product you had imagined.
Planning for contingency makes your bottom line a top priority
We need to make sure we can deliver something valuable that you can make money with. Planning for contingency allows us to focus on that bottom line.
What if you started spending money before you identified your minimally viable product? Your project could end up hosed. It’s risky because you never planned for things that might go wrong. Understanding your project, budget and special features is a good start. Yet planning for contingency is also critical because something can always go wrong. That’s why a good developer will give you project cost estimates based on a wide range of scenarios.
Think of contingency in software development like building or fixing a house. When you renovate your home, you have to budget for contingency. Let’s say you want to redo the kitchen, the bathrooms and the bedrooms, and you also want to paint the walls. You need to figure out what things you absolutely need to have when renovating.
What happens if you decide to demolish the kitchen and find out that all the pipes busted? Now you’ve found 40 years of water damage that you need to fix. It sets you back right now, but you still have a fixed budget. What do you want to give up? Can you live with pink walls in the bedroom?
Planning for contingency allows you to adjust your vision, budget and/or schedule. With that, you can focus on your new bright idea and your bottom line. It’s about managing expectations for your project.
A quick summary of our approach to project cost estimations
If a hard and fast budget/schedule for your project is top priority for your business, we’ve got good news and bad news. The bad news is many developers struggle with being able to give you a project cost estimation. This is even more true for intrinsically or inherently complex projects. (Think building a rocket, for instance.)
The good news is some developers who did their math homework will be able to give you a reasonable ballpark number for your cost estimate. In our case, we use a three-point estimation technique. It includes a “most likely” cost, an “optimistic” cost and a “pessimistic” cost.
Our three-point estimation technique is a modified version of the PERT method that was first developed in the 1950s by the U.S. Navy Seals. PERT — or, Program Evaluation Research Task — was a methodology for evaluating objectives of the Fleet Ballistic Missile program.
A 3-point cost estimation gives you the good, the bad and the most likely
- We first learn your business needs and how you envision using your system.
- Then, we break it down into all necessary subsystems and further break those down into individual tasks. Those tasks are necessary to implement the system.
- We then estimate each task using three points of reference on the basis of complexity: Most likely, optimistic and pessimistic.
We also use reference data from previous projects to translate complexity into an approximate number of hours. We then multiply the number of hours against our hourly rate. The result: an estimated most likely cost, optimistic cost and pessimistic cost.
Finally, we calculate the weighted mean of these three estimated costs to produce the total expected cost to the system. The final result gives you a project cost estimation on a bell curve of probability for the cost to fall within a given range.
Software development is inherently unique. So cost estimates are hyper-individualized and tailored for each client’s project.
Finding curve balls in your project exposes risks and unknowns
You might think your project cost estimate will look like a standard bell curve. That means you think the project is as likely to fall under cost as it is to run over cost. That’s not always the case in software development and, actually, in all engineering.
Suppose you ask your developer to execute a task. They may have an idea how much time and money it will cost to do that. Using our three-point estimation technique, we can estimate the complexity and determine that: In the best case scenario, this project will be really easy; most likely, it’ll be pretty easy; but… there might be something that throws off the whole project, in which case it’ll be really hard. In this case, you don’t have a standard bell curve anymore.
“So you get a curve that is individual to the entire project, and it’s almost never a standard bell curve,” said Dustin Ewan, vice president of software development at illumisoft.
Developers usually have a lot of certainty that a project cost will fall in the easy range, but there might be something that throws it off. If we do hit a couple of snags, it can go way, way beyond the budget we had anticipated. Or, even worse, it could be catastrophic to your business. That’s why part of our project cost estimation includes a cone of uncertainty.
At the start of the project, the “cone” is very wide because there are so many unknowns about the project. It’s difficult to claim that the project will cost X number of hours/dollars because of all the uncertainty.
Over time, the cone narrows as your developer goes through the project because they’re eliminating those unknowns. That means the “cone” will start to converge on expected costs for the project. And if somewhere in the middle, your developer hits a snag, then the cone starts to converge at a higher projected cost. We know then that the project will go over budget.
Estimating project costs takes a day or two to create.
How all this ties into budget and schedule
Even if you have a large budget, almost nobody plans for contingency.
Once you receive a project cost estimate, don’t be tempted to focus only on the most likely, or expected, cost. Sure, we estimated that the project will land within a certain range of costs. And we came back with a project cost estimate for both best and worst case scenarios. But try to avoid focusing only on that expected cost.
“You might say, ‘Oh, you can do it for this much money; I heard what I needed to hear,’ Ewan said. “And you might think at that point that we should just start building. But we really need to figure out where the value lies and what your minimally viable product is, because we have such a wide cone of uncertainty at the beginning.
“If something goes wrong, we need to make sure we can deliver something valuable to you, that you can actually turn around and make money with.”
By identifying upfront your minimally viable product, we can focus on delivering the highest valued part of your project. That way, if something goes wrong, we can still deliver something of value within your budget.
If you have a fixed budget, that means it’s even more critical to identify your minimally viable product. If something goes wrong, you could end up one mistake away from going belly up on the project.
On the flip side, if you don’t have a fixed budget, the project has more wiggle room to pivot from your original idea.
Illumisoft utilizes time and materials contracts. To us, your budget and schedule are the same. Our total cost estimate is based on the number of hours it takes for one developer to complete your project.
Time and materials contracts make your schedule more flexible
That’s not to say your schedule is inflexible with time and materials. In fact, we can speed up your schedule somewhat by adding more developers to a project than we factored in the estimation.
While your schedule is relatively flexible with time and materials, your budget is rather fixed. In other words, we can’t lower costs by adding more developers to a project. In software development, this is the “mythical man month.” To speed up your timeline, it’s going to cost more. Why? Because communication overhead takes time (and money).
For example, the formula of adding one more developer to your project looks like this:
(2 x the amount of work) + communication overhead = total project cost for the period of time the developers worked
“So, the faster that you move on your project, the more it will cost because you’re paying in overhead,” Ewan said. “If you have a fixed schedule and you don’t have a fixed budget, it’s totally worth it.”
But, if your schedule and budget are both fixed, the only thing your developer can do is remove features. Again, this is why having a minimally viable product is critical. You can scale down the project to focus on delivering a product to sell right off the bat.
What if your project’s schedule is pretty loose, but you’re operating on a strict budget? In that case, we recommend hiring one developer who can fully commit 40 hours a week to your project.
“That’s really the optimization of using your budget wisely,” Ewan said.
If your developer fully commits to your project, then your developer avoids context switching. With more than one project on their plate, they start the day working on one project and end working on another. So, each time they switch tasks, they have to unload everything they were thinking about that other project and get back on track.
The problem? Now you’re paying for overhead for the developer to get himself back up to speed with what he was working on. The more you reduce the complexity, the less effort the developer must exert to reorient.
Developing an MVP protects you from contingency
Having a minimally viable product is critical, even when your budget and schedule are flexible. In fact, identifying and developing a minimally viable product naturally creates contingency around unknowns.
“A lot of people have such a naive view of the project,” Ewan said. “They think, ‘Nope, this is what I’m going to buy. This is how much money I have. They said this is how long it’s going to take.’”
That kind of strict attitude toward your project sets you and your developer up for failure.
“If we don’t set the stage for the possibility that there’s going to be something we don’t expect, then we have very dissatisfied customers,” Ewan said. “But, if we talk about these things and we get them to focus on what an MVP is — you know, what’s critical and what’s the nice-to-haves, then we can deliver value and certainty within their budget.”
Got a project in mind? Let’s set up an appointment and talk about what we can do for you.