Welcome to our second topic post. In this article you will learn how to create a rough plan based on your defined goal. You will learn why it is important to have a plan and how you can create one.
First of all, why is planning useful?
As with defining goals, planning is about using your resources wisely, i.e. efficiently and effectively (see Defining Goals). Planning seems to be an additional effort in the first step. Often you already have many ideas how to realize your goal. That’s good! But just starting to implement these ideas leads often to the “onion” problem.
What is the onion about?
A project can be divided into different phases. According to A. Hemmrich these are the definition phase, planning phase, realization phase and implementation phase. There are many other classifications and approaches. Important is the following thought: If you invest insufficient time in the definition and planning phase, you will need more resources in later phases. A. Hemmrich represents the effort as a pyramid. You start from top to bottom and go through the individual phases. The pyramid shows that the phases become more effortful the further down the pyramid you go. If you invest not enough time in the first two phases, the next two phases will take much more time and the pyramid will become an onion. The consequences are: the effort increases, deadlines cannot be met and resources are not used efficiently.
How can you avoid the onion?
Roughly speaking, three steps are important.
1. Think about your goals and define them (see Defining Goals).
2. Create an appropriate plan for your task.
3. Stick to your plan but correct it if necessary (more about this in another article).
When I started as a project manager, I put a lot of time and effort into planning. In principle, this is a good approach. However, there is a reasonable level of planning, an optimum, if you will. The picture above shows that if too much time is spent on defining goals and planning, then the slim pyramid becomes a coarse block. This is another thing to avoid.
Another reason why a detailed planning at the beginning of a project can be disadvantageous is the uncertainty. On the one hand, the uncertainty of what the goal is exactly, e.g. which functionality is really necessary. On the other hand, the uncertainty in the estimation of effort and duration. To avoid these uncertainties there are agile methods, which will follow in a later article. The consequence of an early detailed planning is that the plan has to be adjusted very often, which is not very efficient. Therefore, it is important to note that a detailed planning in this step is not recommended.
Create an appropriate plan
To explain the term “appropriate” it is important to first ask yourself what the goals of planning are. As stated, you want to be efficient and effective with your resources. That is, neither to work on tasks that are not necessarily needed, nor to invest in tasks more resources as needed to fulfil the goal. So appropriate planning is one from which you can derive the information of when to work on what topic and what is the desired outcome of your work. I am intentionally avoiding the time aspect of a task at this point i.e. effort. There will be an article about this later. At this point it is sufficient to think about necessary steps and results.
Planning step by step
Note on point three, that there are different approaches to effort planning, which will be explained in a later article. Therefore, in this third step, try to focus only on whether you could fully understand the task or not. Keep the goal of your planning in mind. It is about developing and understanding the necessary steps you need, to reach your goal.
A practical case study
In the following, I would like to explain the theory to you using our example. In the last article, Mia has already defined her goal and now wants to start on planning her video chat tool. With her goal definition in mind, she starts to think about intermediate goals. One intermediate goal is, for example, the creation of the infrastructure i.e. setting up servers, communication between clients and so on. A second intermediate goal is the application itself, which consists of a user interface and background services. Next, the definition and writing of software tests is needed. And, even if she doesn’t want to do it herself, creating a marketing strategy is another intermediate goal. In this area she can at least already enter the work package “find a partner”. In all other areas, she now begins to break down the intermediate goals even further.
Mia wants to build the user interface as a single page application (SPA). The services should run in a container. For the creation of her code, she needs a code management. For the containers she needs a CI pipeline, and she has to take care of the container hosting. So, she already thought about a few rough working areas for her infrastructure topic. For now, this is sufficient for Mia to understand what she needs to do in which area. However, she breaks down her intermediate goals one or two more times.
Regarding the intermediate goal “Define tests” for example, she considers the tests for the user interface, the background services and the infrastructure to be necessary. She briefly estimates the number of tests in each area and leaves it at that.
Her next step is to plan in detail for the user interface and background services. Mia wants to try a method she knows from her work: “Eventstorming”. More about this in a later article.
She thinks through her intermediate goals and tasks and can already imagine well the work she has to do in each field of work. Now it’s easy for her to put the work packages in a logical order and also estimate the effort required. But before she gets on with that, she first wants to look for a partner for marketing. More about that in the next article.
<< blogs