Detailed Project Planning: Step-by-Step Guide to Effective Project Management
Detailed Project Planning: Step-by-Step Guide to Effective Project Management
In the previous articles, we discussed how to gain a good overview of the tasks to be completed through goal definition (Defining Goals), rough planning (Creating a Rough Plan), and a workshop (Plan an Online Workshop). In this article, you'll learn how to consolidate your many ideas into a detailed plan.
Understanding the Minimum Viable Product (MVP)
Before we dive into detailed planning, we'd like to introduce you to the concept of the Minimum Viable Product (MVP) from Lean Startup methodology. An MVP is a product with minimal functionality that already provides value to the user.
It serves to realize your ideas quickly and reflect them against user needs. Keep this thought of realizing a minimal functional scope in mind as we proceed to derive the detailed plan.
What we're sharing in this article is our approach and our experiences with it. We deliberately don't start with classic methods but show you what has worked well for us. Ideally, you can use many of these approaches for yourself or adapt them to your needs.
What Does Agile Mean to Us?
Agility is often mistakenly equated with not planning. Compared to the classic waterfall model, that might seem the case. However, the onion principle (Creating a Rough Plan) isn't invalid just because you're working agilely. For us, being agile means being able to adapt quickly to changes, communicating a lot, and critically evaluating what has been achieved.
What Is the Waterfall Model, and Can You Be Agile with It?
The waterfall model means that project steps are carried out linearly, i.e., one after the other. Analogous to a process, you move to the next step only after the previous one is completed. Iteration isn't intended.
The project plan is created once, and after a certain time, all project phases are completed, and the project is finished. Changes are only reacted to at the end with a new project plan. You can think of it like a train running on a track. That's the classic view, and there are, of course, variations.
In contrast, agility means reacting to changes. So, if you take a car instead of a train, you can flexibly adjust your route and, for example, avoid a traffic jam—unlike the train, which can't evade a blocked track.
Is Agility Always Better?
Clearly, no! Different methods are tools to solve a problem. Just as problems can be diverse, solutions need to be diverse too. If your goal and the way to achieve it are uncertain, an agile method might be better. If you know exactly who needs to do what and when, and it's about achieving the project goal quickly and predictably, you might use a method that leans towards the waterfall principle.
Try not to strictly separate the methods but rather assemble the principles that fit your requirements. Now, let's get to detailed planning.
Choosing the Right Planning Scope
In the last step, you derived many possible and useful features from both brainstorming (Perform a Virtual Brainstorming) and event storming (Perform a Virtual Event Storming). Now consider which ones are absolutely necessary for your idea. To achieve this, it's helpful to simplify your goal so that the core idea remains just intact.
For example, we want to make it easier for people to find open-source projects quickly and easily. The core idea is searching for and finding open-source projects. In the simplest case, this is a search bar on a website (Open Source Search).
Now categorize your features according to which ones:
- Are absolutely necessary to create the product,
- Provide your user with an advantage over other solutions,
- Are great ideas to further improve your product.
It's clear that you need to implement point 1 first—without it, there's no product. For point 2, it's important to pick the one advantage over other products that you believe brings the most benefit to users. Look at other products, use them, read user opinions and forum discussions. Try to get a clear picture of what might appeal to your future users. You can put all other advantages from point 2 into point 3 and save them for later.
Once you've decided on the minimal set of functions, you can start planning these functions.
Effective Project Planning: How to Proceed
How would you proceed if you wanted to move several cabinets from one room to another? If you're alone, probably by emptying, disassembling, transporting, reassembling, and refilling the cabinets. Similar here: you need to portion the big problem.
Take a function from the intended functional scope and ask yourself: How long will it take me to develop, test, and get this function operational? If you can't give a good estimate yet, that shows the task is still too big. Think about the sub-steps you need.
For example, if you want to build a garden shed, consider the necessary steps: create a drawing, plan and purchase materials, cut the boards, etc. For each work step, try again to estimate the effort. If it's easy for you, you've probably reached the right planning depth.
The purpose behind estimating effort is to imagine the work concretely. To estimate how long a task will take, you need to know what's involved.
At WeValCo, we simplify this a bit. Instead of an exact time estimate, we evaluate the effort based on predefined criteria. The following time units have worked well for us:
- A few hours (1 point)
- A few days (7 points)
- More than one week but less than two weeks (20 points)
Anything that takes more than two weeks, we break down into further subtasks. It's also important that we don't break down the entire functional scope into work packages from the beginning.
In the first step, we arrange the individual functions in a logical sequence, if there is one. For example, installing windows before a wall of the garden shed has been completed isn't possible. There doesn't always have to be this logical sequence, and especially in software development, many tasks can be processed in parallel. But consider which areas should sensibly be developed before others.
In the second step, we begin to break down one of the functions into work packages, as described above. If the corresponding work packages already occupy us for the coming weeks, we end the planning. If not, we take another function and break it down. For us, it's sufficient to create work packages for the next 4–6 weeks.
Keep in mind: the further you plan into the future, the more likely it is that you'll have to adjust the plan again. The less you plan, the fewer connections between the work packages you notice, and you may have to adjust the implementation. Try to set a planning horizon that suits you.
The Sprint: Agile Planning in Practice
Once you've found a rough sequence of functions and worked out enough work packages, you can actually start. But it makes sense to set a period after which you look back and reflect on what you've accomplished. We do this in so-called sprints that last two weeks.
At the beginning of a sprint, we determine who will work on which work packages. Each work package is in an effort class, and each effort class has points. We accomplish about 20 – 25 points per person per two-week sprint. Accordingly, each person takes on that many work packages at the beginning of a sprint.
At the end of a sprint, you can reflect on whether you've met your set goals well or not. Also consider why something worked well or less well. Are the work packages still too big, or were you too optimistic about how many work packages you can complete in your set timeframe? Iterate towards a system that suits you.
Reflection at the end of a sprint is essential. Only through reflection will you get better at planning and more efficient in your work. Always ask yourself:
- What went well and why?
- What went poorly and why?
Be self-critical, but also be proud of what you've accomplished! You can incorporate your experiences with the current sprint into the planning of the following sprint.
At the end of each sprint, we check if enough work packages are planned and plan new ones if necessary. Then we fill the following sprint with work packages again, and the cycle begins anew.
For tracking our tasks, we use Kanban. On a Kanban board, you can see, for example, which tasks you've planned for the current sprint, which are being worked on, which are finished, and which are completely completed. You can find free Kanban solutions in our open-source-searce.
We discuss the current progress of tasks in short, daily meetings of a few minutes. This way, everyone keeps an overview of the others' tasks and can quickly get feedback on problems. But make sure it really remains a short exchange! Extensive discussions can be held afterward and in a smaller circle.
Practical Example: Mia's Detailed Project Planning
Mia, Peter, and Zou have also developed ideas for their functional scope in the last articles. First, they want to describe the truly necessary functions and agree on a special feature.
For the video chat, they definitely need video and audio transmission of at least two participants. One participant must have the option to invite another, and the other participant must have the option to accept or decline the invitation. They categorize all work packages related to this basic functionality as "absolutely necessary."
They discuss the one outstanding feature extensively. Zou finds a contact list important, Peter wants notifications on the phone, and Mia wants video chat rooms with predefined topics. Since they don't immediately agree, they read forum entries and ask their circle of friends. They realize that their unique selling point is that their video chat is open source and anyone can easily install and operate it on a server. They decide to save all three ideas for later and focus on the necessary functions.
Through event storming (Perform a Virtual Event Storming), they already have a good understanding of what their video chat could look like. They mirror the interface against the established functional scope and remove all interaction options that aren't needed. They arrange the functions in a logical sequence.
They want to start with marketing and backend development simultaneously. For these areas, they begin to estimate the implementation duration. The video chat is to run as a web application. For this, they need a basic framework of the web interface, which they will create later. To set up the web interface, they need a test server and appropriate options to launch applications. They think through step by step until they reach plannable work packages for the backend area.
For the marketing area, Zou wants to learn more about their target group. She wants to apply the "Personas" method (more on this in a later article), and research is necessary for that. Zou can already estimate the effort. In a few days, she should have collected and evaluated enough statistics. She assigns 7 points to the work package.
In this sense, the three work through the areas of backend development and marketing. Three things are always important to them:
- Always keeping the minimal functional scope in mind,
- Setting up a rough plan for the next months,
- Detailing only as many work packages as needed to fill the next 4–6 weeks.
They determine what each will work on in the coming two weeks. They want to exchange brief updates on work progress every two days. With that, the three begin their first sprint.
Note: This article is part of our series on effective project planning. Check out our other posts to learn more about agile working, project management, and self-organization.
Do you have questions about detailed planning or want to share your experiences? Leave a comment or discuss with us on X or LinkedIn