No time for a schedule?

"I don't have time to create a schedule. I need to move forward!" This, or something similar, is often the response I get when I ask for a schedule. Often, even project managers don't have one. For anyone who wants to actively address the topic of schedules, I've summarized my thoughts on creating schedules and estimates in this article.

List all tasks

That sounds banal? It is. To create a schedule, all tasks must be listed. A work breakdown structure can help here so that you don't forget recurring work in a project. But brainstorming to determine which activities will arise is also important. All activities must be included in the plan. If someone spends 20% of their time writing emails, then only 80% remains for the remaining work. Then there are also meetings and other activities that take up time. These times must be accounted for in the plan. The list of tasks can also be done as a team during a planning workshop.

Estimation of costs

Every task requires time. Therefore, all tasks should be estimated with effort. Ideally, the estimate comes from the person who is supposed to complete the task. When estimating, it is useful to include the minimum (best case), the realistic, and the maximum (worst case) estimates. This will help you identify work packages with uncertainties, which could take, for example, 10 hours or 200 hours. Avoid estimating work packages that are too large. Work packages lasting more than a week are not suitable for a reliable estimate. Break the tasks down accordingly.

Don't let the target date influence you

That's easier said than done. It's our subconscious playing tricks on us. This phenomenon is known as the anchoring effect. If I tell you that a product has to be launched in June of next year and then ask you when we can finish the product, the first thought that pops into your head is June of next year. There's nothing we can do about that. What we can do, however, is break down the tasks and estimate the effort required. Then we can come up with a more realistic date. So when you're making your estimate, you should try to leave the target date out of the equation for now. Once you have a realistic plan, you can examine how you can reconcile reality with your wishes.

Consider the planning horizon

When it comes to scheduling, there are different planning horizons. There are long-term, medium-term, and short-term planning horizons. My product may have to be launched in the middle of next year. In that case, that is my long-term planning horizon. But there is also an EMC test that is scheduled to take place this year. That is my medium-term planning horizon. And then, with the team, I have the goal of completing a release in two weeks. That is my short-term planning horizon. In my opinion, it is highly recommended to have different planning horizons and to communicate them to the team. The next milestone, in particular, must be known to everyone in the team! If everyone knows where the journey is headed, then you can set the next course of action and ignore everything else for the time being. It is important that the tools for planning the different planning horizons are different. The tasks for the next few days are planned differently than the tasks for the next months and years!

Avoid multitasking

I have to do this, but I also have to do that, but I can't do both. So I'd rather do nothing. But I have to do something.

Sounds crazy, but it happens often enough. Prioritize what needs to be done and use that to make decisions. This decision implies that some things simply won't be done for the time being. Do the important and meaningful things and consciously leave out things that hinder you.

Tackle things once and finish them

Get into the habit of completing tasks at 100% and not 80% or 98%. Completing tasks has several advantages. First of all, it's one less point standing between you and the project's completion. Your mind and desk are freed up for new tasks. And then there's another effect that shouldn't be underestimated. After completing a task, it feels great. You're highly motivated and want to move on to the next one right away. If tasks aren't completed, the exact opposite effect occurs. You feel bad, and this significantly slows down your productivity!

List pitfalls and ambiguities

Make note of any pitfalls or ambiguities that occur to you during the estimation. You'll need to clarify these points later. An example might be that a requirement is unclear to you. This results in uncertainty about the effort required. Then make note of this point and clarify it later.

Time planning is leading teams

Often, time planning is seen simply as a means of estimating delivery dates and costs. Data that interests the customer, the product manager, or the boss. In my view, time planning is much more than that. It serves to lead teams. Because ultimately, the schedule results in a list of tasks that need to be completed next. If I don't have a schedule, or if it's not good enough, what do I expect from the team? This aspect of time planning should always be kept in mind. Then it becomes clear why a schedule is so important. It's the number one tool for operational project management.

Use checklists and patterns

Often, tasks are performed systematically and in the same way over and over again. In these cases, it's a good idea to use patterns and checklists. For example, in software development, there's always a pattern that looks something like this:

• Specify
• Implement
• Test unit
• Review code
• Complete module

For such patterns, it's a good idea to create a checklist. This also provides a direct structure for estimating effort. This also applies to hardware and mechanics, by the way. I use various checklists successfully for this purpose time and again and am amazed at how people manage without them.

Beware of MSProject

Microsoft Project is an absolutely powerful tool for creating and managing schedules. But in my opinion it is also very dangerous. In project plans with over 300 lines it is very difficult to maintain an overview. This can be done by the project manager who created the plan and puts a lot of time into it. But for everyone else the plan in Project Chaos. In the project plan all the tasks from the beginning to the end of the project are listed one after the other. This shows what you will be doing in the next year. I can only advise against this. Instead you should work with the planning horizons and detail the tasks that actually arise. If you want to show someone your plan, one A4 page should be sufficient. If you think that is not possible, then you just haven't understood the plan yourself yet. Reviewing a 300-line project plan makes absolutely no sense. The effect on the developer is, by the way, something like this: "Wow, that's a lot of information. What am I seeing? How am I supposed to know what to do in week 20 next year? Oh, none of this is worth anything!" If you don't believe that, just ask the developer honestly :-)

Know effort, capacity and deadlines

This is absolutely crucial for me. Anyone managing a project (whether for themselves or for a large team) should know the numbers.

• What effort has already been made?
• How much effort is still open?
• Does the ratio of completed and outstanding effort correspond to the current project status?
• How many people and therefore what capacity (man-hours) are available?
• What are the important dates in my project until the end of the project?

If you can't answer these questions, then the project isn't going well or you're lucky :-)

The 3 x 1/3 rule

In projects, you often see project plans with "Specification," "Implementation," and "Test." I've never encountered a project like that. A simple rule of thumb is to allocate one-third of the time for each of these activities. This rule of thumb should be observed when reviewing a project plan. If there is a significant deviation from this rule, it is unlikely to be a good indicator of the plan's reliability.

Planning buffers

There are always unexpected problems and tasks you didn't anticipate. If you only estimate all the tasks you can think of, it's impossible to meet the deadline. Because every project risk that arises and every task you haven't considered leads to a delay. Therefore, it's a good idea to plan with a buffer. For anyone interested in this topic, I recommend the Critical Chain method! It's an absolute must for anyone who manages projects.

Bottom Up – Top Down

There are two ways to estimate the effort required for a project. One is bottom-up. This means that all tasks are listed and the effort totaled. This gives you the total effort. Another approach is top-down. This allows you to use previously completed projects for the estimate. Project A took 14 months. Project B took 18 months. Project C is more extensive than Project A but not quite as complex as Project B. In this case, 16 months for Project C could be a quite realistic estimate. The best approach is to combine the two methods and use the top-down estimation to check plausibility.

Review of scheduling

Schedules are meant to be discussed, not just for the project manager to know! Present the project plan to the team or other people and ask for feedback. This is very valuable. Important! Pay attention to the tip about Project. Not everyone can view a schedule in Project. Extract the important information from the plan. Only then can a meaningful review take place.

Estimate time consumption and improve measurements

Efforts are estimated. This is also their weakness, because engineers are not as good at estimating as they are at measuring. So why are measurements so rarely used? Efforts are usually recorded in companies anyway. So why not use the data to generate insights for new projects? Or do they know how long a code review or risk analysis for a Class IIB product takes? If not, have they never done one? It makes a lot of sense to collect data and conduct project retrospectives. This also allows you to determine the effort involved in a project. This data is very valuable for subsequent projects.

Conclusion

Proper project planning and management determines whether a project is successful or not. Therefore, you should develop the ambition to do your planning and management professionally and effectively. It's also much more enjoyable to lead a project than to be driven by it.

If you have any questions or would like to talk to me, I am happy to help and advise you.

I'd love to hear your feedback and get in touch with me. Feel free to comment on the article. If you know someone who might also be interested in the blog, I'd be delighted if you'd recommend it.

Best regards
Goran Madzar