How many times have we pushed back tasks because we did not have enough time to attend to them? And how many times have we reached a point in the process where we realize that the task is either about to be late or is already too late because we did not attend to it in time? Let’s face the bitter truth: we tend to deal with the “urgent” first (right after we have decided it’s “urgent”), and very quickly in a non-controlled development process it develops into jumping from urgent task to another urgent task. How to deal with it? How to avoid it? What key-points are there to have an efficient timeline management.
First and foremost, there are no magic tricks here. If we have X man hours to do in a task and Y head count and the ratio X \ Y is larger than whatever timeline in hours that we may have planned, some of the tasks are not going to be completed on time.
The Importance of Task Estimates
It is painful to say, but many R&D projects miss deadlines because the task duration estimates and task complexity estimates are off. We are not talking about delays of days or weeks; we are talking about months and even years. So, one must wonder how come, after careful planning, we got it so wrong?
I would like to list the main reasons that impact the timeline of a project, which may create deviation between the estimated task time and the actual one:
- Wrong task estimate to begin with – nobody’s perfect and yes, we all make mistakes. Be it lack of experience, over-optimism or naivety we get some of our estimates wrong.
- Company overheads – different companies, different methods of work. In some organizations for example the mere engineering processes in terms of development flow, reviews, meetings and documentation may add significant overhead, any or all of which may have been overlooked while planning. In contrast in other companies there wouldn’t be any structured flow. The failure to identify these overheads usually originates in team members, even experienced ones that are not familiar with the process of the current organization.
- External tasks interference – none of us work in a void and as such there are tasks that were not accounted for during the project planning, tasks which were not necessarily needed for the development process of the project from other teams, management and even other projects that shift our attention and resources, any of which or all cause these delays. This is a major issue, as often these tasks are not officially planned and are not counted for in the overall effort budget. Also, remember that context switching has its toll as well.
- Human resource shortage – if we planned a project for N engineers but in reality, we managed to recruit N-2 engineers, no matter what we do we will not cover the timeline gap created. Furthermore, when we recruit an engineer at the beginning of the project, we have onboarding process which also demands calendar time that has to be planned. And of course, employees also switch jobs, team members get promoted. It is often difficult to cover these cases in the spares.
- Not enough spares – when we realize that we are not perfect we take spares in the timeline. None of the thumb rules I may suggest here will be any use for this problem, so eventually there is no substitute to the team’s experience; an experienced team leader knows to tell where, when and how much spares were needed. BTW, when we underestimate system complexity, we tend to give less spares on top of the short time estimate to begin with. A proper project risk estimation should prevent us from such underestimations.
- Committing to a timeline with too many unknowns – in a lot of cases, we have to deal with the pressure of management that wants to have timeline commitments as soon as possible, when we have a lot of technical risks and even sometimes haven’t fully or properly finished the research phase. These unknowns will have their revenge eventually and hit the project where and when least expected and will obviously cause delays. Once again, at least in terms of how risky our timeline commitments are, when running a well thought of risk estimation process, we should at least have the correct plan conceived and the prior knowledge as to if the project is a risky one or not.
Note that the last two points in the list are totally under our control. Unlike mistakes (that could happen), company overheads (that may or may not exist), external interferences (that will surely occur) and human resource shortage, we are the ones who decide how many spares we take and when to commit to a timeline. BTW, it is good practice to plan for much bigger spares when there are many unknowns. That said, take into account that in pure research projects in which we start doing something that had not done before, you may estimate whatever you like, it can go on days or years and it is very difficult to predict its schedule.
Let’s take a case example from a good place – two of your team members have been promoted, and you are in the middle of the project with 2 head count short. What do you do first? Which tasks get your immediate attention?
Of course, there are no right or wrong answers here, however it would be nice to have some tools to prioritize the different tasks.
Urgent and Important to Address Timeline Management Better
See below the two lists: the urgent and the important. It almost goes without saying that the items that appears in both lists would be the ones that will get our immediate attention.
Troubleshooting
Why urgent: troubleshooting is the source of our technical ability to move forward. For any kind of technical issue, we must conduct a troubleshooting process to at least understand if the issue is a show-stopper or we could live with it until the next fix arrives.
Why important: we must know any kind of malfunction in our system, the sooner the better. Troubleshooting is extremely important for the assessment of how deep the malfunction extends. In some technical issues we may find that an architecture change is required. We wouldn’t want to find out this bit of information at the end of the development process. A common mistake is to have a shallow troubleshooting process, realize that the issue could be solved later and tackle all issues towards the end of the development process, close to delivery. That, in its essence, is a very risky conduct since we may have to either stay with too many problems to fix towards delivery or we may find ourselves with an issue that cannot be solved under our existing design. Be 100% sure that the issue could be solved later and add its implementation into the work-plan with all of its implications on the project and only then allow yourself to continue forward.
Status Communication
Why urgent: to allow continuous progress of the project, we have to communicate the status of the project constantly to everyone involved – management, team, peers and colleagues. In addition, if an additional resource is needed, then the sooner we ask for it the better odds it will arrive in time.
Why important: when we communicate the status to everyone involved all the gaps are raised whether we meant for it to happen or not. For example, in our weekly update, once we have declared a task as done only to realize that only its planning was done, but we were 4 weeks away from the implementation. Obviously, that was a simple misunderstanding, but we could catch it only by discussing the current project status between us in the team. I would like to give as reference a very realistic scene from the TV series Silicon Valley.
Don’t ever get yourself into this state.
Scarce Resources availability
Why urgent: the urgency in resource availability is very clear – we have a resource now that may be unavailable for our project later and as such, we must make use of it while we can. However, the fact that this resource is available now does not make it important in the long run of the project. We have to be very careful not to create an unnecessary overload on the team only for the exploitation of a resource for a task that may well be premature at this stage.
External Parties Involved
Why urgent: working with external vendors or resources is always urgent. We have a schedule as well as financial obligations to keep with these parties and in most times, we would be forced to prioritize these tasks over others, even because of the simplest excuse of not having the budget wasted. These are not necessarily important tasks for the project.
Timeline Impactors
Why urgent: timeline impactors are tasks that we identified that if not completed ASAP we would most probably have an impact on delivery date. These tasks are the most problematic to prioritize. In the one hand, we marked these tasks as urgent because they have a direct impact on the project’s timeline and on the other hand, we realize that neither these tasks nor the subsequent tasks that may be delayed are on the main path of the project. For example, we have an urgent task to finish testing jig design for a minor feature in our system. If on the one hand, we do not do the jig testing right now implementation will be delayed which will as a result cause a delay in the project delivery while on the other hand, with all due respect, we are overloaded with other tasks with much higher priorities.
High Risks
Why important: high risks are big impactors on the project. The project may be buried because of unattended risks as explained in detail in previous posts. However, we must note that handling high risks is always important but not always urgent. For example, if we have a high-risk mitigation to build a proto for a certain feature to test with the clients and on the other hand we have a task to eliminate sensor noise because all of our sensor readings may come out faulty, the latter will take precedence and will need to get our immediate attention, even though the high risk is obviously more important in the long run for the project.
Impact on Other Programs
Why important: as usual (I am again repetitive) we do not work in a void. In many cases there are other programs and projects parallel to the one we are working on and most of the time there are inter-connections between the different programs. It is important to attend to the tasks that coincide with other programs and at least keep the intersections between the different development lines in time. Since they are usually long-term correlations, these tasks rarely get labeled as urgent but their importance is beyond doubt.
What do we do first? How to prioritize?
So which tasks gets precedence? As an example, I would like to give the elevator of a multi-story building. If we have a 10-floor building with a single elevator, the elevator has to serve all the floors. Obviously the most frequently used floor would be the ground floor as everyone in the building uses it. Let’s assume that all the inhabitants in the building want to get down to the ground floor. If someone on the 3rd floor calls the elevator, the ones who live on the 2nd and 1st floor will enjoy the arrival of the elevator as a by-product, so the lower levels in effect get more elevator service than the upper levels. Now the elevator reached the 3rd floor, and serves the person who entered the elevator to the ground floor immediately. Then the 5th floor, then the 2nd floor (as a by-product) etc. However, once in a while the elevator must give the 10th floor the highest priority otherwise the people who live on the 10th floor would never get the elevator in rush hour, when everyone in the building wants to get down to the ground floor.
With this analogy, we have to attend the “urgents”, because they are urgent. However, once in a while we must attend to the “importants” otherwise we would never reach them, until it was too late.
A few examples
I will start with one of the most common examples: training of staff, either new employees or data transfer within the project. These usually are not urgent tasks, but they are very important. We tend to postpone these training tasks since we always have something more urgent on the table, however, this is the kind of task that should get priority. Whichever knowledge that was not transferred to the project team is a gap that will impact some time on our initial estimates and cause a delay in the project delivery.
Another common example is when we have a single working prototype and two tasks for it: development of the next feature and a presentation for the client. Usually in these cases the discipline that makes more noise gets the prototype :-), however, as a rule of a thumb if one of the tasks is directly related to a high-risk mitigation that will be the one that should take precedence. If the market penetration and voice of customer are one of the highest risks in the project, presentation to the client it is. The main point here is that in an orderly managed project there should really not be a question. The Project Manager sits with the System Engineer and together easily decide which task has priority according to their prior work.
Prioritize your tasks according to future event’s impact and not only according to present events
One last example, when we have a periodic status communication to the management parallel to the development process. Well, the right way to do it is to take away from the development only the head counts that are truly needed for the communication (presentation preparation included). That means only one person from each discipline and even that is sometimes more than required. Do not make a show out of it, just give the status as it is while continuing the development. Everyone would be satisfied that way.
Finally, make sure to have your work estimates during the project updated all the time; this way, each surprise will deviate only a little from the last estimate of your timeline. In addition, when you are working long enough in the same place, have a retrospective look at the last 2 or 3 completed (or abandoned) projects you have been working on – have your lessons learned: why we were late, why we were on time (yes, yes, I had a few of those as well) and accordingly make your adjustments to your current project.
I do wish you all that all of your projects will be delivered on time, or at least with only a reasonable delay.