How to plan for development projects

In a previous post (How to Budget for Development Projects), we talked about the importance of building a budget for your development project overall and for planning specifically. Now we want to look at what's actually involved in planning.

Understanding your business

Clients often come to us and say here's what I want to tackle, now what do I do? Prepare to give it some time. We're going to have to ask a lot of questions in order to figure out:

1. Is the problem you've identified really the true problem, or is something else in the chain causing that problem
2. What are the key contributors that are making that problem so big?

We need to ask questions because we don't want to make any assumptions. We could look at how your website works and study your processes all the way down to how you fulfill orders, but we're not necessarily going to know what element is costing you what. We won't know the skill set of your staff, how you box your product, or where you ship. We have to ask the questions so that we can better understand the intricacies of your business.

Finding the right solution

Next, we can look at what others in your industry are doing and see if there's anything we can mimic, or look at past problems we've solved and see if there's anything we can borrow from that. And in some cases, we can take our expertise from different tech stacks and suggest a solution.

In any planning, the very first step is stakeholder interviews. You don't necessarily have to round up a bunch of different people from your company; often we can prepare agendas with questions and you can figure out who the best people are to answer those questions. In many cases, it will be you yourself. But it can be helpful to bring in other people, particularly if you have a stakeholder who is really feeling the pain of whatever issue you're trying to solve.

Architecting and prototyping the solution

We eventually get to a point where we want to start prototyping and architecting how to fix the problem. This assumes that we've done our homework to get the buy-in and that you've agreed that the steps we're going to take are appropriate. Then we start figuring out how that actually works.

What we mean by architecting is looking at your current tech stack and actually helping you see the flows of where the technology is going to move, the actual steps that are going to take place, whether there will be back-end dashboards that will let you manipulate the data, etc. All those steps are going to be done through mockups and wireframes. You don't want to just start coding and go way too far when you're not even totally sure if everything's going to work well together. 

This is a very fast-paced, iterative step that involves lots of feedback from you. By the end, you get a wireframed prototype of the back end and the front end as well as behind-the-scenes flowcharts and mappings. Now we'll have a clear landscape of the actual solution we (or your tech team) need to build.

Believe it or not, at no point in that whole process are you building the actual solution. That can shock some people. We're in an industry in which everyone is so excited to give the glossy mockup and start coding right away. After all, you can make something and then just change it, right? Well, sure, you can, but it's going to cost you an arm and a leg. Don't just jump into development. 

The solution becomes clear

At the end of this planning, we should have a clear picture of everything we want to tackle, everything we want to fix, and the ways we're going to go about doing that. Then we can actually start planning what the UX and creative teams are going to do, and what the developers are going to do. We can even determine if we need to bring in outside third parties. All in all, the solution is clear and we can now implement the solution.

TL;DR: When you plan, don't expect any coding to happen. Expect to invest time and energy in answering a ton of questions and giving plenty of feedback.