When the opportunity arises during idle time between projects, our organizations involved in project execution should review our processes. It's likely that we'll always find out how to optimize them, and above all, how to avoid repeating mistakes in future planning and become more efficient every day and in each new project.
Further, during the project´s progress we –both as participants and observers- can also detect how some processes (even those we think we had already improved) may be modified, so that we are able to complete them in shorter times, at a lower cost, and with less effort and/or better quality. And as participants, as these areas for improvements are detected, we can point them out to the team, so they may invest time in reviewing these improvements to later implement them.
Often, we are so busy while in mid-project that we deem it impossible to focus on issues that do not translate into a direct improvement of the original schedule. The problem with this way of thinking is that if we do not take the time to review our actions and learn from them (first-order learning) we are not improving the way we manage matters, at least not during the current project's duration, but instead we will have to wait until its completion to implement corrective changes.
Sometimes we have the same opinion about those meetings scheduled during the project´s progress. We are physically there, but mentally we're absent, since our focus is on our mobile phones sending messages, or on our laptops sending emails. Thus, our contribution to the meeting or to reviews or analyses has poor impact or influence compared to what it could have, and afterwards we feel the meeting was a waste of time.
Certainly and sometimes bordering on exaggeration, for instance a meeting is scheduled in order to set the time for another meeting, or it is simply ineffective (when we do not stick to the agenda, but make a soap opera of each item); or ge get into meetings that should take an hour, but end up lasting three hours. In such cases, an analysis is also required that scrutinizes the reasons why these meetings are not as effective or impacting as expected. Hence, meetings are also processes that need to be reviewed.
For the above reasons, our advice to any team running a project is to make a forced halt in order to review any missing lessons, and analyze whether their immediate inclusion into the process under way would improve the remaining project execution (learned lesson applied as continuous improvement). Even F1 racing teams, with an execution exceeding 300 km/h, have their own pits to make the necessary stops, settling on a strategy to reach the podium. Then, why cannot we have our own pit stops in our projects, where we can check or change tires, clean the helmet visor of the pilot, refuel the car, and then resume with a fresh oomph the rest of the race? These are things that seem logical but we barely put into practice, and probably we have not done so because we have not turned them into habits.
Perhaps what I have written will not resonate with some of you. The good news is that I can also communicate it with an image you might consider funny, but it is important to remember that when you are involved in a project, you might usually be pulling the cart, and the one proposing a meeting to support you, is the one holding the wheels.
We can improve that process
We can´t talk now
We are very busy