Projects in the IT industry are usually a big challenge. Not only for the company that is supposed to perform a task, but also on the ordering party, and thus, while planning the work, you cope with a number of factors that you not always have a full control over. Of course, you can always wield a whip in the form of a schedule. “If you won’t deliver X until Y, then we’ll push the deadline by Z”. This gives you a certain amount of security, but does it always has a positive impact on the course of the project, future relations and the atmosphere that you have to work in on a daily basis?


Tongue-in-cheek, there’s a large group of clients, whose entire conversations revolve around two words – ‘deadline’ and ‘ASAP’. This gives you a clear idea of what the client favors the most, and that is completing the task on time, meeting the only acceptable, the most important, and in theory, non-negotiable date. This is a ‘certain constant-pressure’.

Now let’s think about what’s important to you. Looking at the agency environment, which I’m actually operating in, I can state that to us, as the service providers, executing all the project assumptions as soon as possible, obviously while upkeeping all the high-quality standards, is even more important than to the client. This means that we should approach projects in a way, where the deadline set by a client is only one of the factors, which we take into account when we plan our work. The main consideration for the executing party should be establishing when are we able to complete a project, and this depends heavily on how we approach its planning and execution. We’re usually not the only people involved in a project. There are entire teams responsible for particular pieces of the puzzle and it’s up to how we approach it, when it comes to the amount of time we’re actually going to need.

And why is that so? The explanation is fairly simple. In the agency environment, resources are planned and assigned short-term and swiftly adjusted to the current situation in the entire portfolio of projects. ‘Swift’ is the keyword in our reality.


Moving forward, let’s see what options do we have when drawing up schedules and verifying deadlines. In order to do that, we need to make certain assumptions. Below, we’ll discuss two options for verifying deadlines on the basis of estimation. Depending on the results, a number of actions might be necessary: increasing/decreasing the resources, negotiating with the client, or even making the tough decision of informing the client that we won’t be able to meet all of his expectations. I’m a supporter of open communication and finding ways out together. Hiding the reality of the matter from a client isn’t a good practice, unless you like a hands-off ride on the brink of healthy relations.


Regardless of the method you choose to draw up a schedule, you need some input data: scope of the project, budget, backlog, estimations, resources and their availability, as well as the initial risk analysis. You work out the particular information on your own, some of it is delivered by a team or analysts, that is, people. It’s a crucial point that the data isn’t spat out by calculating algorithms but rather developed, using different approaches and assumptions. When assembling various parts of a project, you have to establish what was the driving force behind the person, who delivered them. Has the person who did the estimation added a buffer, and if so, how big was it, has the person acquainted with all the project assumptions, has the time available for execution been taken into account, and so on. Again, the question arises – why? Why do you have to analyze all this, why can’t you just take for granted that Mr. Smith said it’ll take 150h and that’s it? Yes, it’s convenient, however not very optimal and dangerous to a large degree. You want to be pretty sure that the project will be completed with as little surprises as possible.

Pessimistic approach

Probably the most well-known and popular of them all. Giving you a relative feeling of security, protecting particular team members the most, but at the same time stretching the project in time. It fits perfectly with a number of basic problems appearing in projects, for instance, Parkinson’s law, which claims that work expands so as to fill the time available for its completion, student’s law (described below), and the ubiquitous Murphy’s law.

How does it work when it comes to planning?

We ask Mr. Smith how long will it take to do the task. Mr. Smith thinks: I need X amount of time to complete it, but I’ll add some more, as there may be a problem, plus the security buffer, because if I won’t make it, the boss will be mad and the client non-pleased. We receive the estimation value, make similar assumptions (yeah, we have a boss too), add buffers to buffers. We’re good now, there’s no way we won’t make it. And the project? As always, it’ll fill the entire available time, no matter how much there is of it.

Such approach, called the critical project path, is pessimistic but also necessary as to introduce some optimism to our projects.

A pinch of optimism, as the recipe for a successful project

The implementation of an optimistic approach in projects requires many changes, including the acceptance by the company’s top brass, as well as understanding from the team members side.

You emphasize optimization and boosting effectiveness, so you have to get all the pain points of the pessimistic approach together, and think how to modify them. There are the following issues with the aforementioned approach:

  • security buffers added to tasks by people doing the estimations,
  • student’s syndrome emerging during the execution of tasks,
  • Parkinson’s and Murphy’s laws.

Let’s start from the bottom of the list, where there are two laws mentioned. There’s not much you can do about them except to accept them. What you can do, though, is minimize their consequences in a way, in which they’ll have no effect on the project as a whole. To answer the question ‘how?’, consider the situations related to particular tasks.

Security buffers – you can’t make it without a certain slack of time. Here’s where the critical chain approach comes to the rescue, and its basic assumption is optimism! While analyzing tasks, you deliberately decide to cut their estimations in half, and the time leftovers you get add up to make a single buffer for the whole project. As a result, the total time for all the tasks gives you an idea of a deadline. This is the earliest date, when the project completion is possible.

What’s next? Then you have to tackle the student’s syndrome. It is a phenomenon, based on the boost in efficiency of the performed work, along with the decreasing amount of time required for its completion. Let’s get the obstacle out of the way! Its occurrence depends on the deadline, and the deadline is assigned to a task. You can’t remove the task, so let’s get rid of the deadline. If someone completes a task faster than the estimation has assumed, he knows what to do next and also knows he has to do it as fast as he can.

How to control the project completion?

Similarly to critical path, you monitor the completion of a task, and the only thing you have to ask is ‘when will the particular task be finished?’. There’s no need to shuffle the schedule, which was the case with critical path, as soon as a delay occurred. You only keep the tabs on the general buffer consumption.

Where are the benefits? 

The obvious gain is in the execution of tasks with full efficiency of team members, which shortens the time to complete it. Moreover, by getting rid of the task buffers, you optimize the project as a whole. Statistics show that the actual time savings at the scale of an entire project are around 20%, and the percentage of projects delivered on time is around 80% (while it’s merely 20%, using other methods).

To end on a high note

Being aware of the problems that you have to cope with allows you to be prepared for them. Obviously, the approach discussed above may not be applicable to every project or on every stage, but in my opinion, it reflects the natural course of a project. It requires the cooperation of an entire team, understanding, clarity and involvement, however, in the end, the payoff is worth the work you’ve put in.

Maciej Borkowicz

Project Manager at Divante eCommerce Software House

Share your comment