Software Development Planning Basics

In this article, I will explain the essentials of planning for IT software projects.

Before we start, let’s make things clear. Good planning is possible, and by good planning, I mean planning with deadlines met and no overworking or team burnouts. And now I will give you a few basic steps to make it happen. So, without further adieu, let’s get into it.

So, first thing’s first, you need to choose a planning methodology. Two very popular methodologies in the modern software world are waterfall and agile. In waterfall methodology, the planning is done for the whole project in a detailed way.  In agile methodology, detailed planning is done only for a fraction of the project or the initial phase of the project. The rest of the project is planned on a high-level without diving deep into details. Agile methodology is popular for its flexibility, and waterfall for its clear expectations. If you want a detailed comparison of those two methodologies, let me know in the comments to this article.

Second thing you may want to do is to select a term or a planning horizon for your planning process. Let’s say, for example that you decided to plan using Agile methodology. In that case, you need to essentially break down the planning into two parts. First part is high-level planning for a long term. Let’s say, for a year. Second part is detailed planning for a shorter term, such as the next quarter or even the next week. Those two parts should be completely separate processes, which will have their own goals, schedule, and planning horizons as variables. Choosing the right planning horizon is important and will drive a lot of decisions further in the process.

All right, step number three. Now that the planning horizon is selected you need to understand which features you want to build for it. At this phase, you may already want to consult with a software engineer who is working with you on this project. You may want to communicate the planning methodology and planning horizon you selected, tell about the business idea you want to implement and the features you want to include. At this point, the feedback from engineers may not be 100% accurate, but it will give you a high-level idea of which features you can include into the potential timeline. You write down the list of all business features that you deemed required and feasible from the feedback and what’s important, and then write down business requirements against every feature on the list. The requirements can be either detailed or high-level, depending on the accuracy of planning results you are expecting. High-level business requirements will always result in a high-level planning with low accuracy, so keep that in mind.

Step number four: the software engineer performs a decomposition of the project. You present all of the requirements and the list of features to the engineer who will now take a much deeper look into it. Decomposition is a process of representing business requirements and features in a form of system building blocks. The blocks themselves will then form applications and services. Decomposition must be performed by an experienced engineer who knows the specifics of a particular platform or technology and is capable of designing systems of such scale and complexity. The output of decomposition would be a system design document that features a list of technical components, level of effort required for each component, and the teams and specializations necessary to perform the work.

Now, after that document is ready, the project manager, product manager, or other stakeholders must carefully look at it. First, they need to define how much of the required resources they have to accommodate the technical requirements. Essentially, they need to draw a timeline and start including the components one-by-one to it, almost like in a Tetris game. The component which requires more effort and time will be bigger on the timeline, whereas the low effort components would require a smaller slot. There are a few differences from Tetris, though. First, availability of teams and dependency between components must be strictly followed. And second — and this is very important — the amount of teams you assign to a single component can be limited. Often it is just a single team. So, please, carefully review those limitations with your engineer.

Once you fill in this schedule, it becomes your sharable document, which you can then send to your teams and stakeholders. It is an important blueprint for future development and can serve as a point of coordination between all parties. Further down the line you can add more items or adjust it following the same process we outlined today.

More Information about Planning and Helpful Insights

To subscribe to new content use links in About Us page. Also check out this blog for other articles related to Software Development planning!