About Planning

Delimitation: PM deals with requirements (scope, requirements), costs, risks, quality, changes, procurement, personnel and more. Planning mainly focuses on the time factor. By planning is meant here exclusively “time planning” in the sense of the “schedule”. Screen hardcopies are completely omitted in favor of length.

There are many definitions of what planning is — I like this one best:

Planning is the mental anticipation of future actions

What is the purpose of a plan? It is the realistic assessment of the situation in relation to the achievement of a goal. Can I reach the goal in the desired time? If not, what is lacking or when will I get there? If these questions are not interesting because you have enough money or resources, you don’t need to plan.

How do you create a good plan? The instructions are on the next pages. Substantial is the good knowledge of the products and the processes that lead to these products. If there are dependencies between work steps or teams, these must be identified and integrated in good time.

What happens if I do not plan? If I do not plan, then problems only become visible during the work and not before. An acceleration by parallelising or by using additional resources is then not possible. Also a better design of dependencies can no longer be mapped afterwards. Planned deadlines can then no longer be met.

What happens if a plan is not kept or not kept precisely enough?

• The notified target date cannot be met

• Higher costs are incurred,

• Idle times and

• Demotivation.

From the PM point of view, poor planning is therefore simply a risk. Additional effort is required to justify the project or to procure additional funds or resources. The reputation of the project manager also suffers.

What happens if the plan is adhered to? Nothing. It is an accurate reflection of reality. The goal is achieved on time. The reputation improves.

How much effort does planning require? With good knowledge of product and process, the effort is basic and one-time. Afterwards, the plan can be used again and again as a template — it becomes an “asset”. In the beginning the effort is higher and in the course of the project it decreases steadily.

Microsoft Project

From here on, the guide to building a solid plan in begins using Microsoft Project. Any other tool can be used as well.

The magic triangles

Everyone knows the “normal” triangle:

• Scope

• Cost

• Time

In Microsoft Project, however, the thinking is a bit different. You have to think of MS Project like the spreadsheet Excel with fixed formulas in the cells. And the implicit triangle has the following three sides, which differ from the PM standard:

• Duration : Duration of a task in hours, days, weeks …

• Work : the work behind an operation, in man-hours

• Units : The people, also called resources

Inside the program, the rule is: One of these values is fixed, the second is entered (can change) and the third value is calculated automatically. In most cases, “Fixed Duration” is used at the beginning — because the work cannot be estimated yet. Then, when the fog clears, “Fixed Work” is used — that is, the work is entered in man-hours.

To then plan with Fixed Work, there are two possibilities:

• Change the duration — then the resource is used with correspondingly less or more percent load.

• Change the number of resources — then the duration will be shortened or lengthened.

How the calculation is done can be entered per task in the “Properties+Extras”. Newly created tasks are created with the calculation type stored in these options. It makes sense to use only one calculation type in the entire plan, because otherwise some calculation results are very difficult to interpret.

A good plan does not develop by itself. It takes several steps to be taken individually to develop a “maturity.” Not all steps need to be done at once. What is important is that the steps are done in sequence and not in a jumbled fashion.

A plan is formed when the actions described below take place in that order. The further “through” the planning is done, the more “mature” the planning is.

Identifying the result

As mundane as it sounds, what is the end result of the plan? A product. This can be a system, a component, a document, an acceptance or approval. The product can be the end of the plan, or it can be an intermediate step that is handed off to someone else. In any case, a sub-plan always has a single end result. The entire project has an end result and an end date.

The partial products are defined by a “Work / System Breakdown Structure”. An important document as a basis for goal setting is the “SoW” (Statement of Work) or a “Requirement Document”.

The S.M.A.R.T. rule applies to objectives: Specific, Measurable, Acceptable, Realistic and Terminated.

If all these attributes are present, then it is a “good” goal.

Setting an end date

For this outcome, we first set a desired end date. This is the date we are “planning” toward.

Listing the actions until the result

Now mental work takes place: the individual steps for achieving the result must be written down in the form of a list. This list should be as self-explanatory as possible. The entries should NOT look like this:

• Sawing

• Hammering

• Screwing

But they should contain the product in each case, so that it can be clearly identified. If it should be quite good, then subject and verb are added:

• Sawing boards for the log house

• Procure hammers for the carpenters

• etc.

The result would then be “handing over the log house to the client” as the “final milestone”. To avoid thousands of useless individual activities appearing here, the granularity should not be too high, but also not too low. A maximum duration of the individual task of 4 times the reporting period has proven to be a good reference value. So, if the schedule is reviewed every week of status, then a task should have a maximum length of 4 weeks.

This ensures a minimum grid. In order not to let the number of planning steps become too high, one can either introduce summary tasks or be guided by which intermediate products are recognisable. These actions are particularly important with regard to future performance progress measurement.

It is expedient to base the individual steps on an already existing (development or manufacturing) process. The better this is known, the easier and safer the list can be created. If it is not known, the focus should be on a realistic description of the individual steps. Once these considerations have been completed, a list of required activities and a list of products, i.e. completion milestones, are available. These lists can then be easily transferred to the “Name” field in MS Project — even with copy+paste from the word processor.

Sequencing the tasks

Once this task list is complete, the pending work can be sequenced. This is done expediently via “Finish-to-Start” links. To do this, first select the predecessor in MS Project with the mouse and then select the successor by holding down the Shift key. Then press the chain part at the top of the toolbar. The predecessors of a task can be displayed in the properties or in the “split screen” (chart area + right mouse button + split).

Planning is always based on the predecessors....The first predecessors are the prerequisites after which the project can be started in the first place. If these predecessors are created in other projects, we speak of “external” predecessors or “external links”. A plan is only complete when all tasks have predecessors and successors. Milestones, if they are prerequisites, have successors only; result milestones have predecessors only.

The longest sequence of activities between the beginning and the end without slack time.

Any change to one of the tasks on this critical path changes the completion date.

Parallelising the tasks

When all tasks have been put in a sequence, usually a chain has been created whose end date is much too late. Now you can try to perform individual task chains in parallel with others. This is possible by allowing two tasks to have the same predecessor and thus start in parallel.

But care must be taken here: If these parallel sections are to be performed by the same person(s), then either time delay or overload will occur as a consequence.

Estimating the duration

If initially planning with fixed duration, then you can now estimate and enter the length of the tasks. The column with the resources remains empty in this step. The work is automatically calculated based on the standard calendar used — i.e. with 8 hours per day.

If the plan has reached this stage, then a lot can already be seen and it can already be used for some tasks. Up to this point, the minimum requirement for a plan is met.

Estimation of the effort

To make the planning more realistic, you can now enter the effort in man-hours per task. The resource column still remains empty for the time being. For this step you should set the task type in the task properties to “Fixed Work”, otherwise MS Project will automatically recalculate the duration. The estimation of the effort can be done by analogies to previous tasks. If this is not possible, simply consult an expert. If the effort cannot be estimated, this usually indicates that the subgoal has not been broken down into enough individual tasks. So take two steps back and think again.

The plan is much better afterwards and can be used for initial effort estimates.

Assigning resources

Planning with resources requires more practice than the first steps. It is best to try it out with a test plan before adding to the “real” plan. The moment something is entered in the “resources” field in this plan, it can be related to the work and duration.

If simply a name is entered, MS Project assumes that this person is working 100% on the task. If “fixed work” is set, then the duration of the task will automatically change depending on the previously entered working hours (see below).

For example, if in this situation the bar is “dragged longer”, i.e. more time is scheduled, the “usage” of the resource will automatically decrease accordingly. This behavior is very helpful later when adjusting the resource load. Caution is advised when entering multiple resources for the same task. Here, the calculated results are correct, but usually difficult to understand. For this reason we advise to use a “simple” resource planning.

To get an overview of the load distribution resulting from the specification of the work, MS Project offers three “resource views”. By the way, the scaling of the table on the right side can be changed (as in the GANTT view) simply by holding down the “Ctrl” key and using the mouse wheel.

Mapping of vacation times

A question that comes up again and again is: If employee X takes vacation now, does that affect the critical path and does he thus “drive” the project?

MS Project knows several calendars. The “lowest” one is the project calendar. This is usually loaded (if available) from a Project Server and contains the standard working hours and the holidays incl. bank holidays. By the way, these “bridge days” often lead to “leaps” in the calculations of final milestones. So in case of this effect first consult the calendar.

Additionally there is a calendar behind every task and every resource. The task calendars are very unwieldy and create a huge memory requirement. It is better not to use them — especially since they make tracking very difficult. The calendars stored in the resources contain a field for “non-working time”. Vacations can be entered there, which are then also directly and automatically included in the calculations. Unforeseen illness can also be entered here in order to recognise the influence on the project.

Resource balancing

In the resource load view you can see whether a resource is overloaded or not. Overload occurs, for example, when the same person is scheduled 100% in two simultaneous tasks. The reduction of these work peaks is called resource balancing. MS Project offers a function for this, which also provides results that are difficult to understand (but nevertheless correct). Please do not use this function, but reduce the overload consciously and manually. This way you will keep the situation under control.

The overload can be identified using the resource assignments (view). If it is clear which task is creating the overload, it can be extended until it becomes critical. This will reduce the “usage” of the person (“Unit”) according to the load. The newer Project versions show a small green triangle after the duration has been changed. If you click on this, then a prompt will appear asking if you would rather adjust the work (i.e. more) or decrease the resource load (our choice here). It works the same way the other way around, if we change the deposited work.

Assigning costs

Costs are almost never calculated in our schedules. This may be due in part to the fact that only people are scheduled and not machines. With a flat hourly rate, personnel costs can be conveniently calculated by multiplying by the hourly total.

Recalculation of a realistic deadline

Critical tasks and milestones are automatically displayed in red. However, Microsoft may also consider tasks as critical whose “deadline” is set to a fixed value and whose end date is behind this date.

Much more is displayed in red than useful. In any case, it is worthwhile to check all tasks with a red bar in a plan. At best, only one chain of tasks is shown in red. In the leftmost column there should be no calendars except for the input milestones. In the options you can select whether the dates should be recalculated automatically. If this is turned off, changes will not be visible immediately (as in Excel). In this case, the calculation can be triggered manually using the F9 key.

Mostly there is the problem that the calculated date is more or less far behind the target date. There are some approaches to eliminate this problem (in order of expediency):

• Parallelising tasks that were previously performed one after the other

• Shortening the duration of tasks by using more resources

• Changing the dependencies of tasks on the critical path

Conclusion

Transparency and honesty pay off. Pretending incorrect facts or overestimating oneself have already caused many projects to fail. Creating a plan that is incorrect in terms of content is equivalent to pretending to be wrong. Since planning is the foundation of a project’s survival, you should think twice before investing time here. Most projects fail because of incorrect requirements. In second place is already incorrect planning.

Good planning helps to justify resource requirements and to raise funds. It enables a functioning progress control and thus a timely, realistic reporting. As a team leader, if you have a working plan, then you can see into the future — otherwise you can’t.

The fact that you have read this far means: you are interested in successful project management and you will see a plan in the future very differently than before. Your reputation will improve and you will no longer feel stress when you go into critical meetings. You are prepared.

All trademarks are the property of their respective owners.

Thanks for reading.