How much ya got?
Seriously, and you’re going to hate this, development cost is more often a question of what you are willing to spend than what it will actually cost. That’s because the cost of doing everything that you actually want is always way more than what you are willing to spend. So start thinking in terms of “what can I get for what I have?”
You can get a rough idea of the overall cost. First work out all the numbers in a wee-hours spreadsheet. Make your most educated guesses about the people needed, technical tools, outside vendors, and business services; all of it. Show it to others, get their input. Make adjustments. Work on it until you think you have it all as buttoned-up as it can be.
Then triple it. In my experience, this will be closer to your real cost.
Why triple? On top of the actual costs of the development work, the additional costs come from:
One part “oops.” There are going to be things that go wrong. You may select a particular technology as the basic development environment, and then halfway through the development cycle, you realize that it can’t handle some important aspect of your application.
This happens to almost everyone. You’re lucky if it happens to you before you take the product to market; most people find out after it’s been out there for a little while and the technology just can’t keep up with demand, or customers reject the application because of a limitation imposed by the technology. In our “try before you buy” software economy, customers find out very quickly if they want to pay for the app they’ve just downloaded or obtained as a trial.
One part “what?!” Unanticipated costs can come from any quarter. The lead engineer you hired, who was a great fit, might be recruited away and the only viable candidates are 25% more expensive. Plus it will take time for the new lead to come up to speed. The integration between your application and another could turn out to be far more difficult than you first anticipated, adding months to your development cycle. You can’t know these things before you get started; they’ll pop up as you go.
Now that you’ve got some kind of budget in mind, there’s one last thing you need to know. You will never get everything you want for that. Software development just doesn’t work that way.
Yours will not be the first software project in history to come in exactly on time and on budget. Getting to the end of a development project is an exercise in compromise; the strength of Agile is it recognizes that. The key to being “Agile” is recognizing that you may have to give in on one thing to gain something else.
The Golden Triangle of software product creation
It’s a bit of a cliche, but it still applies: “Better, Cheaper, Faster: Pick any two.” It’s every bit as true in software development as it is in the pizzeria or other local business where you last saw that old sign.
The best way to deal with the reality that something’s got to give is to start with the tightest constraint.
- If budget is the most critical issue to you, adjust the time and feature expectations accordingly.
- If you must have certain features or the product won’t sell, make that your top priority and be willing to put in the time and money necessary to achieve that end.
- If you’re pressed for time, for whatever reason, you’ll have to pay extra (for more and better people) or cut some of the features to get the product out there, and be ready to make adjustments to the product minute it goes out into the market. (And pray that you can move quickly enough to make those adjustments before a bad reputation kills your market chances altogether.)
Cutting corners
If cost is a driver, one thing you may consider is whether to have the application developed offshore. We all know that the labor costs offshore are much lower than they are in the U.S., and there are plenty of talented programmers in other countries. Given that we are based in the States I am obviously biased, but what I can tell you is that we are often asked to re-develop an application that was originally taken offshore.
This is not a reflection on the technical skills of the offshore team, but rather on the appropriateness of the team to the particular application being developed. We’re speaking here of applications that touch your customers, build your reputation, and generate your revenue. The teamwork and communication discussed here are critical to that, and are not well-served by remote teams in other countries.
When will it be finished?
Remember what we said earlier: a software application of any value is never finished. If you’re lucky. So what you’re really asking is, “When can I ship something?” That’s an important distinction, because it’s a reminder that, to some extent, it’s under your control.
Most applications have some minimal set of capabilities that must be completed before they can be at all useful (you’ll hear developers speak of “minimal viable product,” or “MVP” because giving things acronyms makes them sound better). But beyond that, you have choices. Just as you can dial back features to save money, you can do the same to get the thing out the door.
Be wary of development by contract: if you promise features to your customers before knowing what can be done by when, you may be headed for disappointment. Development is a matter of trust and compromise, not contract.
Different stakeholders will argue (passionately, if they are good at their jobs) for particular features. As CEO it may fall on you to decide what is best for the business. I suggested earlier that you stay out of the day-to-day work of the team, even if you think you know the customer better than anyone. That’s true. But it is here, at these significant decision points, that your understanding of the customer, the market, and the business will come to bear on the success of the project. These are the decisions that need your input and direction.
How’s it going?
Now that you’ve accepted your role in determining when it can ship, you’ll want to know how to tell if the team is making progress towards that goal.
You rely on your team to report progress, of course, but if you’ve ever been the recipient of “progress reports” that detail “percent complete” as they color in the milestones on a Gantt chart, you’ve probably been frustrated. It’s fairly typical for developers to be “85% finished” within a week or two, and remain at that reported 85% for another month.
Here again, Agile helps. By agreeing to build your product in short sprints, each of which produces something that can be demonstrated, the team is making its progress apparent. You’ll have the list of everything that the team agreed should be in the application (they call them “stories”), and you can see that list being worked off in two- to three-week increments.
Of course there will be status reports (you’ll see “burn-down charts” and hear of “story velocity”), but just seeing those demonstrations every few weeks will help you get a feeling for how it’s going.
Your role in all this is to listen to the team, respond when they need your help, and watch to make sure they keep their eye on the big picture.
The requests for help will take many forms. You may be called on to resolve those feature conflicts between the developers and the user representatives (“they say they want X but that will take a month; if we do Y instead we can do it in a week”). Or you may be asked for resources (tools, people, money). Because you have constant visibility into their progress, those requests will make sense to you.
The downside of maintaining a focus on the needs of the user is that sometimes the “backend” things, such as integration with external systems, application security, or keeping audit trails, can be overlooked. Don’t let your developers be dismissive about these issues, which are always more complicated in reality than they are in theory.
“Saving that for the end” is not a good strategy. Integration complications are one of the main reasons that application development takes longer than anticipated. These factors should be factored into the development strategy right from the start.
This article was excerpted and adapted from The CEO’s Guide to Creating Great Software for Your Customers, When Software Isn’t What You Do, by Frank Zinghini. Click here to download the full guide for free.
hbspt.cta.load(2637494, ‘7be9b60b-533e-4a11-9fb1-d6f541024810’, {});
