Project management on time

Although we all have the same time, sometimes it seems that it is passing too fast. It's not that we're lounging, but that people are taking on more than they can, and everyone is suffering. And the projects we take on magically turn from cute, innocent aspirations into something impossible, and this again and again destroys our schedule.

Project managers know, or should know, that the iron triangle of project management is sometimes called a triple constraint because a project depends on the following three elements: timeline, budget, and scale. For many of us, the weak point is the left corner, that is, the timing.

Any project, starting from the development of a piece of software and ending with the construction of a house, takes a certain amount of time. The ratio between the scale of the project, time and price must be balanced. If there is not enough time or budget, the project is doomed. What's the problem?

Planning, delegating functions and the ability to say "no". First of all, we must determine the scale of the product: a verifiable, real result that will leave the client satisfied. If everyone has decided on the scale of the product, then you can move on to the scale of the project, that is, directly to work to achieve the final result. The scale of the product and the scale of the project depend on each other. If you change anything at the product scale, the scope of the project will change too, and these changes take time.

Sometimes we don't meet deadlines, but it's not our fault. We're working on feasibility studies, on new versions of tutorials, on training developments, and even more frustrated when clients want to know if the plan will be met by the deadline. Of course, this is impossible.

And every day there are more and more new demands, without our consent. Change something here, add it there, and now there are four or five new projects.

But this isn't an article about how hard it is to manage projects. Someone manages it better, someone – worse, but everyone sometimes has failures. When it comes to project management, time allocation is our Achilles heel. In the past, we would happily get to work without thinking, planning, and handing over functions. But now we have to refuse. It's sad and sad, but we can no longer allow things to pile up and a lot of commitments to sweep past us.

Traditional approach (as it looks on paper)

In an ideal project management world that doesn't really exist, there is a logical and practical approach to calculating project due dates. Imagine living in this perfect world of project management, and let's take a look at how things should be.

First of all, we work with customers in order to determine the scale of the product, to describe the work that we need to do. Then we create the scale of the project itself to create this framework, we take into account only the necessary work to achieve the final result. Next, we create a structure for decomposing the work of the project.

The work decomposition structure is not a list of activities to complete a project. The structure of work decomposition is work focused on the division of the result, and not on the work itself. Once we have created the structure, we can form a list of tasks that the project team must perform to achieve the result.

The action list should follow the hilarious eighty percent heuristic rule, which states that the smallest element in the work decomposition structure, called a work package, should take no more than 80 and at least 8 hours to create. We don't need to create an overly detailed decomposition, before every step, nor do we need too large work packages so as not to exceed the 80-hour limit and the work does not undergo improvisation. (As with any rules, there are exceptions.)

The list of actions should be arranged in the order in which the actions should occur. Most actions rely on constant logic – they must occur in a certain order in order for the project to succeed. We need to install the operating system before installing the applications. Programmable logic relies on management decisions. For example, we could create a script that, after installing the operating system, would call the remote server to get the application and install it on the target station immediately after the OS installation is complete. But you don't have to. It's selective logic based on experience, the nature of the work being done, your mood, etc.

Now the fun begins – as a supervisor, you learn the sequence of work and realize that you can actually follow several paths in tandem to complete the project. So, you plan to work visually in the project network diagram (PND). A network diagram visualizes the work and allows you to find a critical path. The critical path is not the path on which the most important actions are located. This is the longest way to achieve project completion. The critical path reveals actions whose late completion can cause your project to be late and miss deadlines. You can identify a critical path by tracking the duration of the activity from day one until the project is completed.


But what happens to actions that don't fall into the critical path? These activities are free, and the time allotted for their implementation can be increased without harming the timing of the project. There are some formulas that are used to calculate the allowable extra time for each activity.


You don't have to be a genius to be able to use math, it's much easier and easier to rely on an information system (such as Microsoft Project) to perform calculations.


The critical path may change because some non-critical actions may be delayed, additional actions may be added to the project, or the duration of non-critical actions may be revised. Your project could drag on if any of this happens – so you may have a new critical path.



There are relationships between each set of activities in your network diagram that describe how and when subsequent and parallel activities can begin. There are four types of relationships, although in most cases only two are used:

• Start-after-finish. This is the most used type of communication, which involves the completion of one action to start the next activity. For example, you must create a disk image before you can distribute it to another 1,200 computers.
• Start-to-start. This type of connection allows two actions to start at the same time, but they do not have to end at the same time. For example, imagine that your organization decides to distribute new software that will need to be installed by all users. In the project plan, all users must complete four hours of training before the app is installed. You create a system that installs software on users' computers while they gain knowledge of how to use the software. Both actions start at the same time, but they definitely will not be completed at the same time.
• Finish-to-finish. This relationship requires both steps to complete at a time. For example, you manage a website design project. To offer a new stylish look, your organization will send a million postcards to current and potential customers. The project plan requires that the final modifications to your website and the arrival of postcards at potential clients' offices be completed simultaneously.
• Start-to-finish. This is the rarest and most unusual type of connection - special. You will resort to it in case your planning occurs at the time of the task. In general, the action must begin in order for the other to be completed. Imagine that you are a manufacturer of plastic bottles. But you don't have infinite space for all the plastic, so you order it as soon as your inventory is minimal. Absorbing plastic by current actions triggers ordering more plastic so that you can create more bottles in the future.
• Together with any of these connections, you can use slowdowns and accelerations. Slowing down is represented by waiting time, and acceleration is represented by increasing urgency. For example, you install a completely new network in a building. You'd like the wiring and fasteners to be installed at the same time. However, the fasteners need to be installed a little before the cable is wired, so you should add a latency for wiring the cable. The plan allows both actions to be performed at the same time, but requires cable installers to be slightly delayed before they can start their work.

Sometimes project managers need to rush things in a project. In this case, you need to speed up the events - this is represented in the form of an earlier start of each action by reducing the time allocated for them. Expectations are positive times and acceleration is negative.

Project Duration Forecasting

The projected duration of the project is based on the total duration of the activities. A little bit of math and you can predict the best, worst, and most likely outcome of every action, and at the end of the entire project.



To make such a forecast, which will be the most accurate, you will need something more than a simple summation of duration. You should consider some factors that can ruin the schedule, drive you crazy, and create a host of other problems:

• Limitations. A restriction is anything that can limit your options. You've hired a consultant who can only devote time on December 29. You have enrolled your team in a training course starting january 20. Victor, a system programmer, goes on a month's leave in February. All these are limitations - and there are a great many of them.
• Assumptions. We all know what happens when we assume something. For example, we assume that the supplier honestly stated that the new servers will arrive by October 1st. We assume that the client is using Windows 95 or better, not OS/2. We assume that we have unlimited access to the place of work, and not just 8 hours a day. You will encounter problems if you do not take into account these assumptions.
• Resource availability. Have you ever thought that you would need 4 people to wir and install the cable, and you only have 2 specialists in the project? If you don't have the resources you need, your project will suffer.
• The law of diminishing returns. This law controls the benefit in relation to the available volume of labor. Let's say we have an action that requires 40 hours of work by two specialists. If we add two more specialists to this action, can we complete the work in 20 hours? Maybe, but if we add 40 specialists to the action, will everything be done in a matter of minutes? Probably not. In addition, not all actions are based on effort – many of them have a fixed duration. This is a good example of the fact that sometimes it does not matter the number of specialists - the actions still take a certain amount of time.
• Parkinson's Law. Parkinson's Law states that work is extended for the amount of time it has been allocated. Imagine being told that the action takes 40 hours, although it is known that the work can be done in 12 hours. A certain amount of time is added to possible errors, problems, and other non-work-related activities. But it turned out that the task really took 40 hours. Imagine the work you do before your vacation – you can do everything in one day. And after the vacation? You'll only need a whole day to send one email (and that applies to all employees).
• Risks. Business risks can have both negative and positive sides, although we remember only the bad. Most risks most often lead to the delay of the project, the addition of actions and in some cases lead to complete abstraction from the project and its closure.

Time management and rough forecasts

And how do we know how long each action takes? In some cases, you can rely on experience. Other times, you should believe the experts, historical information, and approximation. Approximation? Yes, imagine any IT project where you were a manager or participated. Every project has the right to a primary mistake. Almost every IT project is unique. Even if it's a project to install old software in a new environment, it has unique aspects. No two IT projects are exactly alike. There are always some differences.

These differences can confuse you. These unique configurations also lie in the best attempt to predict the duration of an activity. It may seem like you know everything, and sometimes you don't know anything at all.

Therefore, forecasts are called forecasts. But customers and management don't always understand this. Have you ever given a completely random forecast taken out of thin air? Such a simple rough forecast that customers and management expect from you is called a rough estimate. We recommend not to give such forecasts - if you need, it is better to indicate that this estimate is not justified and may be incorrect by 75% and even 125%. Otherwise, you will have to stick to the forecast, and if in reality the results are different, then you will have to pay.

Project Completion Time

If time management were an easy task, then everyone would be up to it. The best approach to effective time management is effective planning. As project managers, we should take control of the project schedule, which requires constant monitoring of the assessment of the duration of actions, the real time allocated to these actions, expert assessment and experience, in order to make appropriate changes in plans. Of course, it's always not too fun to replace one bad date with another.

We all have the same amount of time – we only control what we do with it.