Business 2 Community3 Assumptions You Need To Avoid While Planning To Build Your Next App
Over the past few years there have been multiple platforms and devices delivered to the market by the major players (Apple, Samsung, HTC, and Google just to name a few) in the mobile world. As a result, mobile app development has become a bit like changing a tire on a moving car. But, we can do it; we have the technology!
Unfortunately, when you’re trying to keep up with changing demands and tight timelines, you end up making some dangerous assumptions – and you know what they say when you assume….
(Bad) assumptions can ruin everything. It can be alluring to rely on previous experience and gut checks, but doing the due diligence beforehand will very frequently save you time and money in the long run. Of course there are good assumptions that can be a godsend to your timeline, the problem is figuring out which is which. To that end, I’ve outlined a few common dangerous assumptions below that management and developers alike tend to make. Avoid these like the plague, or at least like a bad head cold.
Assumption: Your app must be built with a specific technology/toolset.
Reality: Be flexible. Evaluate your technology stack on a per project basis instead of having a set platform for all projects. Developers should be smart, flexible, and adaptive, but it’s projects that should determine the tools.
You should begin by evaluating your project and finding out where your team’s expertise is. It’s important to take the entire team’s input into the process, as a good team should have an idea of where its strengths and weaknesses are.
Seperately from working out the team’s technological center of gravity, a similar exercise should happen entirely at the project level. It’s much easier to figure out what a project looks like if you have unlimited talent, time, and resources, but take those factors away and find out just how much you need to deliver and when it has to be delivered by. Is this a quick and dirty one-shot, or a logic-heavy enterprise app that needs to be functional and maintained for years to come?
Finally comes the not-so-exact science of marrying the two. You know what you need to build and when it needs to be built by, now it’s time to sit down with your tech team and bang out the best path between now and deadline (depending on your needs, “best” may or may not be equivalent to “shortest”). From here you can plot out a some (very) rough timelines for each approach, referencing high level functionality and architecture with a focus on potential time sinks, and make an informed decision.
This comparison should help give you a clearer picture of how to get to the finish line, but also remember that an important takeaway from this exercise is “can we do this?” Don’t be afraid to answer “no, this is impossible.” Sometimes it is.
Assumption: You know the overall cost (in both time and money) it will take to build your app.
Reality: This is the big one. There is a general perception that an app “doesn’t take long” to build (which tends to translate to around 2-4 months). That can certainly be true, but this is possibly the most dangerous assumption – for both your bottom line and your stress level.
The fact of the matter is that the tools and available knowledge for building apps has come a long way since the days of the first iPhones. App development has become more streamlined (though there’s still a ways to go), and this can save you a lot of time and money.
However, researching the how – not the what – of building your app before you actually dive in should always be your first step. This research should include the kind of features, frameworks, interfaces, and back-end/service integrations that will be needed. Ask yourself as many questions as you can think of. Even the stupid ones. Should this be cross-platform app (iOS/Android/Windows)? Do I want each platform to look different (spoiler alert: yes you do, but that’s a different article)? What about tablets? Offline access? How much security does this need? Did I leave the oven on? What about a marketing plan? Is this app even something people really want?
Once you’ve nailed down the functional requirements, architecture, and integration points, you can start to get a clearer picture of the level of effort involved in building your app. (Bonus, these artifacts will help speed up the actual implementation process.) Now you can start to get idea of just how much effort – and thus how long and how much cash – it will take to build your app.
You may still be wrong, but you’ll be less wrong, and that’s a great first step. This brings us to…
Assumption: Everything will go according to plan.
Reality: Nope. There’s always a monkey wrench – whether it be a last minute requirements change, faulty code that needs to be rewritten, or a big chunk of functionality got missed while defining the project.
It’s going to happen, and it has the potential to completely derail your project. You can try to overplan up front and account for every possible scenario, but that significantly increases the level of effort of defining the level of effort, and that simply doesn’t scale well. Not to mention you’re still likely to miss something.
The best thing to do is be ready for it. Leave little windows of time at regular intervals throughout your project to check that everything is running smoothly and that you don’t have to redefine anything. More importantly, don’t be afraid to redefine if you need to.
Sound familiar? It should – regularly redefining (or evolving) your requirements is a core tenet of Agile software development and one of its big strengths. But just because your project isn’t being run as an Agile project doesn’t mean you can’t reap (at least a little bit of) the benefits.
The moral of the story is that every project is different and should be treated as such. Even if you’ve done this a hundred times before, it’s important to be wary of the pitfalls of assuming you know what you want or what you’re doing going in. It’s important to use your previous experience as support for your implementation, not as a crutch. Your best bet is to make sure every project – in the immortal words of Foreigner – feels like the first time.
*This post originally appeared at DOOR3
This article was syndicated from Business 2 Community: 3 Assumptions You Need To Avoid While Planning To Build Your Next App
More Technology & Innovation articles from Business 2 Community:
