In today’s organizations, it is becoming more and more important to understand the needs of a project manager and an engineer. These needs can differ a lot, which can cause a tension and problems within the company because both have their own ideas about how they want things to be done.
Deadlines are important so we don’t lose the focus on what has to be done in what time frame. Without deadlines we probably would fritter our time away even more, postpone important tasks even further and delay problems so long that it might even become a disaster.
In the long run, a lack of deadlines causes frustration because you feel you are never finished and can’t finish what needs to be done. That leads to doubts about your own performance and self-worth. This problem can turn into a vicious cycle.
The actual problem is perfectly explained through Parkinson’s Law: “work expands so as to fill the time available for its completion” and not the actual time you need for doing the task.
It is quite scary how right this law is. Have you ever found yourself in such a situation, maybe in a meeting? In meetings you can talk for hours about one topic and everybody contributes, even those who don’t have a clue, but at the end of the meeting the crucial decisions are made in five minutes, leaving you to wonder why everything couldn’t be handled that way from the beginning by limiting the meeting to a certain amount of time.
Deadlines are the natural enemy of procrastination, which studies show nearly every fifth person is affected by.
There are two different types of deadlines:
Real Deadlines: These are deadlines which the real world is giving us. For example, if you need to release a feature just before Thanksgiving, then you need to have your product done by that time. If you see beforehand that your engineering team is not going to make that deadline, then it’s worth considering getting help from someone external or finding another solution. It’s a make-or-break situation.
Fake Deadlines: Deadlines which are not linked to any real world events are simply pointless. In other words, if that deadline is only there to make your project manager happy, then it is not a real deadline. One of the dangers of fake deadlines is that engineers will start rushing to get the work done and will most likely lower the quality or scope, so you end up with a poorly executed project. To create a sustainable startup, you need a good product to win the long race.
One really good principle is the Agile Manifesto: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
In a lot of startups, engineers are totally against deadlines or any kind of estimate, which is really hard for project managers to understand and can lead to misunderstandings on both sides. The product managers may believe that the engineers are acting unprofessionally or don’t want to commit. On the other side, engineers feel like the product manager is setting unrealistic goals and wants to push them to do assembly-line work. But let’s take a look at why this is happening and what can be done to let them work more effectively together and understand each other.
First of all, engineers sometimes feel that the management doesn’t take them seriously and pushes them to meet unrealistic deadlines. In some companies, they even get blamed for not fulfilling promises. Over time, this creates a situation where they wince when they even hear the word “deadline”.
However, for a project manager, deadlines are the most important information on how long something will take and what steps he has to do next. Without deadlines, his job is most likely set up to fail. What kind of information can he pass on? To him, it’s not sufficient to be told, “Well…. We will fix that issue maybe today, maybe in three weeks, maybe in five weeks, I’m not really sure.”
An estimate is nothing more than an approximate calculation; it’s clearly not a binding contract. There is a big difference in how you are providing estimates: “It should take around one week” is different than saying, “This will be done on the 5th of march”. An estimate will give the project manager an idea of how much time the project will take. With this communication between the two parties, the project manager has something to work with and can pass it on to other teams or clients.
Also, this estimation gives the engineer the freedom to not get punished when the project is not done in exactly one week. To keep this freedom intact, it’s crucial that all parties communicate very well and there is no room for interpretation whatsoever; otherwise, the estimation will turn into a deadline.
With the given estimation, the project manager understands the amount of work the engineering team has to do or he can decide whether the project or feature makes sense at all for the company. The project manager has to trust the engineering team to give him estimates which are as accurate as possible.
Before you start a project, you are probably making estimates for yourself already and are not starting out clueless. But why not share these estimates with your project manager? For example, if you discover that a future will take way too much time to build, it’s a good idea to tell your project manager — they like to hear these things from you because you are the expert.
Estimates also let your CTO know if you are struggling with a complex issue; then he can jump in to help you instead of micromanaging you the whole time. This gives you more freedom in the long term and more time to plan your own schedule better. Conversely, when you are progressing faster than expected, you can schedule in new features or move on to the next one.
While there are many benefits of estimating your project, you should definitely not spend hours on planning; that would cost too much time. If the project is too big, keep breaking the task down until it’s easier to estimate the time.
It’s very important to follow some basic steps when planning a new product or project; these are outlined below.
Every product has different estimates based on the tasks which have to be done. To plan these deadlines as accurately as possible, you always need to understand that problems can occur during the process of creating the product.
When you create a project schedule, always consider potential problems, maybe by looking at other projects or based on your experience. If you can’t think of any possible delays, make them up; by doing so you will most likely stick to a realistic time frame.
Based on Hofstadter’s Law, an advancement of Parkinson’s Law, projects will always take longer than you expect. Therefore, as a rule of thumb you can estimate your project will take 50–100 percent more time than you planned. Depending on the industry, that can be way too much or not enough of a time buffer. It’s always better to use a generous time buffer to be sure you do not miss the deadline. An impossible deadline can be fatal to the spirit of the team. It will cause permanent overwork, an irritated working environment and even burnout diseases.
For the planning of your tasks, it’s important to know your personal timelines. This doesn’t mean getting your work done as fast as possible. It means determining how much time you will ideally need to perform a task to your and the team’s complete satisfaction.
If a project manager is assigning you a task which you know based on your experience will take at least eight hours and he estimated two hours for it, then this will cause a problem and you need to talk about it.
If your work is good, you will gain more trust from your project manager and he will give you more time, as the primary goal should always be high quality over everything else. If you’re a beginner, trust that your speed will improve automatically over time; don’t be overwhelmed by unrealistic timelines at the beginning.
Try to break down your project into mini-deadlines (milestones) to create checkpoints for your progress.
Through this technique you will consistently keep the motivation level up, detect errors in scheduling and figure out how to solve them. This is also a way to avoid Parkinson’s Law, because the closer the mini-deadline gets, the more you will throw yourself into it.
Another advantage of the milestones is that other people can see what is already done and what is still pending. Especially on large projects, it’s sometimes hard to keep track of all the tasks and procrastination grows. Therefore, shorter deadlines ensure a proper work flow.
Project managers and engineers can work well together as long as they keep their communication up. On the one side, the project manager needs to constantly challenge his team, but on the other side he also needs to trust them and their time estimates. Using their estimates, the project manager can make the right calls for the startup.
