During this three-part series, we’ll be discussing some of the more important aspects of going from idea to reality.
So you have an idea. You’ve worked out how your application is going to change the world, or help your company, or make a bazillion dollars, or that it just sounds fun. Now the real work begins: you’re ready to start coding. But wait! There is more fun ahead.
Before you even begin, you need to plan the whole thing out. Nobody likes planning; not real detailed planning anyway. And this is understandable. It’s time consuming, requires real rigor, and doesn’t produce anything fun to play with. However, it is the most important phase in the development process by far. Especially if you’re dealing with contract engineers. What we’re going to cover in this first post is a very general overview. In fact, I could write an entire book on this phase quite easily. Which brings me to another good point: Read everything you can about software planning before engaging with developers. This is, after all, the first and last part of the development process that you will have ultimate control over.
I cannot emphasize how difficult it may be to get the ideas and visions out of your brain and into the brain of a programmer. I don’t think this is because developers are difficult people (although they often are), or that product managers are bad communicators (most of the time they’re really not.) However, there is a cultural divide that is invisible to both parties normally. Programmers work in a world of abstractions and concretes. What you need to get across to them is the actual concretes, and let them handle the abstracts. Telling an engineer “I want you to build me a chair” probably makes perfect sense to you. However, when the engineer brings you back their three-legged stool with one leg shorter than the other because they thought it would be better for tilting you towards your desk, you’re probably going to want your money back.
On the flip side, you want to stay flexible to a certain extent. Cost considerations are one issue: A common phrase around our office is, “I can make a brick fly if you have enough time and money”. Another age old adage is, “I can do it quick. I can do it well. I can do it cheap. Pick any two.” In essence, the features you want included will directly effect the time, quality, and cost of the entire project.
One useful way to think about it is that software is a process, not a product. By that I mean it can constantly be shaped and adjusted, and probably will be, for the life of the actual end product. So the first question you should ask when approaching your initial plan is, “What do I want to get out of this FIRST version?” This is not something to be taken lightly. Now, most of the purchasing decisions you’ve made up until now when getting something custom built probably didn’t work this way. Let’s face it: almost no one hires a construction firm to build their house with just a kitchen and a bedroom, with the plan of adding a bathroom later on. However, most engineers are the exact opposite. I’m not sure why, but it may be because they’re not often brought into the conceptual phase of a product. If you are always dealing with the end results of a sales persons conversations with a client, you probably think that all clients are idiots, and “Why didn’t they tell me this at the start?” becomes a mantra.
Unfortunately, most contract development companies aren’t going to give you direct access to their developers. This is due to a number of factors, including 1) companies don’t trust their developers to have the people skills to interact with paying customers, 2) companies don’t trust their clients not to try and hire their valuable programmers away, and 3) a lot of developers don’t want to work with clients – they enjoy their protected environment. So if you’re not working directly with a developer, hopefully you can work closely enough with a technical project manager who can navigate having one foot in each world.
Even if you do find a good company, or single developer to work with, that does not let you off the hook with the planning process. Most development companies these days will start out the project with a detailed needs analysis and scoping process (hopefully!) If they don’t, that’s a red flag. As little as anyone likes spending money, you want to find a company that will charge you for this. I know that sounds crazy (looking for someone who will bill you for planning work), but you wouldn’t want to pay a construction company to build an office building for you without first hiring an architect. In a similar fashion, you want to find a development firm that takes planning as seriously.
A good development firm (or single developer for that matter) will have at least two rough phases in the planning process to guide you through. These are very general areas, and the bigger the company, the more formalized these will be, but you should at least be expecting a Scoping phase and a Wireframing phase (which may be rolled into one in some cases.)
So as you can see, starting a web development project of any sort can prove to be time consuming and costly if you’re not prepared. Proper planning and research can ensure the ball is in your court. Stay tuned in for the next two posts: Where I’m going to dive even deeper in to the initial planning processes of a web development project, including scoping, wireframing and prototyping, why ‘management portals’ are necessary, and so much more.
