SummaryThis article delves into the recurring challenge of project delays in new product development (NPD). It explores how mismanaged timelines and internal blame games contribute to these setbacks. It examines what missed timelines indicate. Further, the article highlights the importance of efficient execution by project teams. It explores the fallacies in the negotiation process of timelines between top management and operational teams, revealing how strategic adjustments and misunderstandings about time buffers lead to unrealistic expectations. By identifying the root causes of high development lead times and offering synchronization solutions and enhanced communication across teams, this article provides valuable insights for improving overall project efficiency and success.&nbsp;Picture this: a conference room bathed in the sterile glow of fluorescent lights. The room and the lights witness a swarm of gloomy faces towering over a non-descript, circular table and pondering over what could have been. The topic under discussion is time management and how, for the nth time, they are in danger of missing a milestone of a significant project which would launch a new product in the market.Such sights are not uncommon in NPD project management environments. In such situations, the ire of top management is directed towards project teams executing the projects, how inefficient they are, how their commitment counts for nothing and how their trust is running on thin ice. On the other hand, each team that faces blame often shifts the responsibility to the upstream team, citing delays in receiving inputs, issues with the quality of inputs that lead to reworks, and so on.A play of blame and counter-blames ensues. Everyone seems right in his place, leading to a lot of confusion on what or who caused the problem. In such environments, any "root-cause analysis" either fails or throws up trivial solutions. Without any root cause, organizations resign themselves to expediting &amp; fire-fighting as the only way to solve problems. Expediting leads to a lot of wasted effort and creates a lot of bad blood between teams (Supply Chain vs R&amp;D, Supply Chain vs Quality, R&amp;D vs Process Engineering, etc).Organizations find themselves trapped in a vicious loop, expending energy on ineffective solutions while the underlying inefficiencies persist, undermining overall project success and progress.So, how do we achieve clarity in this conflict?Given that the issue initially arises from missed timelines, the solution may lie in deeply understanding timelines' genesis in any project…The origin of timelinesProject timelines are generally drawn at or before the start of the project. The methods of estimating timelines vary. Sometimes, a high-level estimation of individual project phases is done based on experience, and project milestone dates are drawn. In other cases, planners are brave enough to do a bottom-up estimation. They identify project tasks and their dependencies, estimate task durations, and roll them up in various ways to get the milestone dates.In both scenarios, the initial estimation, whether bottom-up or top-down, is followed by a complex negotiation process between planners and the top management.Games people play- The complex process of timeline negotiation (estimation?)Once initial estimates are established, an intricate negotiation dance ensues between the operating teams and top management. Each side strategically adjusts these estimates—adding or subtracting buffers—to guard against unexpected challenges. For instance, top management often pushes for more ambitious timelines to maintain pressure on the teams, such as trimming a 22-month estimate to 18 months, believing that a tighter deadline is necessary to achieve the original timeline. In response, operating teams anticipate this tactic and inflate their estimates, proposing, say, 26 months so that after negotiation, they secure the 22 months they initially needed. However, top management is aware of these tactics and counters by further reducing the timeline. Ultimately, the negotiation becomes less about finding the truth and more about who can outmanoeuvre the other.Good or bad, the negotiation finally ends with some mutually agreed-upon timelines. Agreement to timelines by the operating team at the end of any complex negotiation process is viewed as a commitment and true validation of the initial plan and its accuracy.Thereafter, the general assumption is that achievement or non-achievement of timelines is an indicator of system efficiency:The more milestone dates one can meet, the higher the system efficiency.Any deviation from project timelines is put up as a problem to be solved. But is it really a problem? Let's delve deeper.What does it take to achieve a project timeline….Prima facie, for any milestone date to be achieved, two conditions must be met. Both conditions are necessary for the achievement of target milestone dates:Necessary Condition 1 - The initial estimation of the milestone date at project start is reasonably accurate.Necessary Condition 2- Project teams execute the project efficiently.<figure class="image"><img style="aspect-ratio:2039/1411;" src="https://backend.vectorconsulting.in/storage/editor_uploads//necessaryconsitions_1726307399.png" width="2039" height="1411"></figure>Why is the NC1 (Estimate project duration correctly) condition necessary? – Because if timelines estimated at the start of a project are not accurate, even if the project is executed at the fastest possible speed, it may still not ensure the achievement of those timelines.Why is NC2 (Execute project efficiently) a necessary condition? - Because even if the timelines are accurate, the project teams would still be unable to achieve timelines if they do not execute efficiently.The paradoxWhich of the above two conditions are being met in a specific scenario is surprisingly difficult to find out! Why?Let's say a project achieved the timelines set for it. A quick analysis will show that the timelines could have been completed under any of the following conditions:<ol><li>Both NC1 (Estimate project duration correctly) and NC2 (Execute project efficiently) are valid- in other words, the initial estimate was correct, AND the project teams worked efficiently to execute it.</li><li>NC1(Estimate project duration correctly) is false, but NC2 (Execute project efficiently) is true- the initial estimate was too aggressive (read: wrong). Still, the execution team made extraordinary efforts to achieve them and were successful in the end.</li><li>Both NC1 (Estimate project duration correctly) &amp; NC2 (Execute project efficiently) are false, as explained in the following scenarios –<ol><li>The initial estimates needed to be corrected/aggressive, and the teams could achieve them, but only by cutting corners on the scope.</li><li>The initial estimates were wrong/buffered; therefore, the execution teams, though inefficient, could still achieve the timelines.</li></ol></li></ol>What is fascinating about the above analysis is that there are three scenarios, but there is no way to determine which scenario out of a, b, or c is active in any given case!The initial estimates may have been either accurate or inaccurate, and the projects may have been executed efficiently or inefficiently- yet the timelines can be met! Meeting of timelines is indicative of one of the possible combinations mentioned in scenarios a, b and c but does not isolate any of the two conditions as a cause.&nbsp;It's worth repeating this statement differently - a project may achieve its timelines. However, it still does not clarify whether that was due to accurate estimates of timelines at project start execution speed or both!Now, let's look at the other possibility. Let's say that a project was NOT able to achieve its timelines. The project milestones may not have been achieved under any of the following conditions:<ol><li>NC1 (Estimate project duration correctly) is false &amp; NC2 (Execute project efficiently) is accurate. Although the teams worked extremely efficiently &amp; productively to deliver the projects, the initial estimates themselves were off/inaccurate. There could have been scenarios like uncertainty in delivery times, scope creep, etc., that were not foreseen in the initial estimates.</li><li>NC1 (Estimate project duration correctly) is valid &amp; NC2(Execute project efficiently) is false- although the timelines were reasonably accurate, project teams dropped the ball at various points during the project. The efficiency of project execution left a lot to be desired.</li><li>Both NC1 (Estimate project duration correctly) &amp; NC2 (Execute project efficiently) are false- the initial estimates were inaccurate. The execution efficiency could have been better, which somehow led to failure in meeting milestone dates.</li></ol>Again, we observed a similar result! We do not know which of the three scenarios were active (a, b, or c). The non-achievement of timelines does not indicate either estimation inaccuracy or execution inefficiency. All possibilities are open even after looking at the metrics! However, most people arrive at (b) as the only conclusion if a timeline is missed!Closing the loop on the initial claim made and going back to the initial relationship that we drew:<figure class="image"><img style="aspect-ratio:2039/1411;" src="https://backend.vectorconsulting.in/storage/editor_uploads//necessaryconsitions_1726307451.png" width="2039" height="1411"></figure>The above relationship is accurate but also misleading! This means that NC1 and NC2 must be true simultaneously to meet the timelines. However, people tend to implicitly assume NC1 as accurate by default and rush to conclusions about NC2 if the timelines are met/are not met.Therefore, what's the point of looking at milestone timeline achievements when they do not deliver any insight?As a matter of fact, milestones do have one essential function.Using milestones as a means to synchronize efforts across the organizationA project typically requires a coordinated effort across multiple teams, each contributing different skills and resources to achieve a common goal. These teams can be internal or external (such as suppliers, outsourced entities, or supply chain partners). In many cases, these teams are geographically dispersed and may work on other projects simultaneously, many unrelated to the project at hand.In such a complex environment, effective collaboration and synchronization among teams is crucial, especially during critical stages of the project. This means that each team must be ready and available to receive and act on inputs from other teams at the right time. However, this can be challenging in a multi-project environment where each team has its own set of priorities and timelines.Time &amp; scheduling becomes a beneficial ally if used appropriately, in such environments.Knowing the timing of future milestones is crucial for teams to prepare and align their efforts within a project effectively. When teams know when key milestones are expected to occur, they can proactively engage in preparatory activities, ensuring that everything is in place when moving forward.For example, suppose a process engineering team knows a particular build will likely happen on a specific date. In that case, they can ensure that all necessary equipment, such as rigs, jigs, fixtures, tools, consumables, etc., are ready in advance. By preparing everything beforehand, the team can immediately begin work once the parts arrive from suppliers, minimizing downtime and potential delays.Additionally, knowing milestone dates allows teams to give specialized resources and a heads-up before their involvement is required. This ensures that the right people are available and can allocate their time effectively. When teams are prepared and synchronized with the project's timeline, the overall efficiency and effectiveness of the project are greatly enhanced.What milestones cannot do?Organizations, though, have another need which they try to fulfil by looking at milestone achievements. There is a need to monitor the execution efficiency on an ongoing basis so that they can take measures to improve the efficiency if they see it dropping. As mentioned earlier, this need cannot be satisfied by looking at milestone achievements.Is there another way to assess the execution efficiencies that do not rely on the previous faulty technique? Looks like there is one.If we could assess the execution efficiencies differently, then the need to use timelines to monitor the same would be reduced. Additionally, by taking steps to enhance execution efficiency whenever a decline is observed, we can achieve the fastest possible lead times in product development.The only reason we would still want to look at timelines would be to understand when the project will likely be delivered so that appropriate communication is passed on to stakeholders.&nbsp;Factors determining execution efficiencies on a projectThe following measures, if taken on an ongoing basis, will help us determine whether teams executing the projects are doing so efficiently:<ul><li>Monitoring resource utilization in teams</li><li>Monitoring the quality of output being delivered by teams (including intermediate outputs)</li><li>Monitoring &amp; fostering communication &amp; collaboration across teams</li></ul>If we take the above three measures and proactively resolve issues related to these, we would have ensured that projects are constantly being executed efficiently.The three measures mentioned are about asking the right questions while a project is being executed.1. Resource utilization - Efficiently executed projects make the most available resources. The following questions to be asked on an ongoing basis during project reviews will help us assess this factor and mitigate it:<ol><li>Is the project waiting for resources in any team?</li><li>If yes, how long is it likely to wait (in days or weeks)?</li><li>Is the waiting time beyond the tolerance limit?</li><li>What can we do to quickly address the situation?</li></ol>When put in place, a mechanism of Daily Work Management helps team leaders ask those questions of their team members almost daily.This mechanism includes breaking down tasks being executed by teams into smaller activities, monitoring the completion rate of the smaller activities and comparing it with the arrival rate of newer inputs to compute the waiting times. When the waiting times are too high, they can be resolved by adding more resources (from other teams or from outside) or re-engineering the processes in this team to crash the processing times.2. Quality of work - Delivering high-quality work that meets or exceeds expectations without excessive rework &amp; late revisions is another sign of efficiency.<ol><li>Excessive rework- Too often, in a project environment, we see revisions resulting from "foresight errors"- errors that could have been avoided if due process had been followed. These errors are caused by shortcuts taken under time pressure.</li><li>Late revisions- Late revisions happen when the pressure of time forces teams to postpone the scope of work to the following phases. This work typically accumulates in the final phase of a project because there is no more phase to postpone, leading to late revisions.</li></ol>The following questions, when asked on an ongoing basis during project reviews, help us assess this factor and mitigate it:<ul><li>What are all the steps required to complete an activity? Are the steps being followed?</li><li>What are the deviations being taken while performing an activity? Are these justifiable?</li><li>Are we handing over half-done work to the teams downstream?</li></ul>Again, the Daily Work Management mechanism ensures continuous oversight of processes followed and the intermediate outputs delivered by teams. Task breakdowns into activities, as mentioned earlier, help track the thoroughness of the work being done before handing it over to other teams.3. Communication and collaboration - Efficient projects benefit from clear, open communication among team members and stakeholders. Strong collaboration helps avoid misunderstandings and ensures alignment across the project. For this to happen, it is essential to synchronize priorities across the organization so that teams find common cause in working together on individual projects. Too often, we see teams prioritizing different projects while at work, leading to long waiting times when one team needs the support of another team.Mechanisms must be implemented to ensure no misalignment in priorities while different teams are executing projects.Teams are encouraged to raise issues or "support requests" on each other. The problems could be related to the physical integration of parts designed by different teams, functional integration of parts/sub-systems from various teams, and lack of clarity in inputs. Once the issues are raised, the mechanisms we put in place help us monitor and resolve them as soon as possible.ConclusionA proactive process of execution monitoring is the only way to identify issues and inefficiencies as they crop up and address them. It also serves as a way of acknowledging and rewarding the efforts of execution teams irrespective of whether they achieved the timelines set at or before the project starts.Since proactive measures are taken continuously to ensure the efficient execution of projects on a day-to-day basis, projects are completed as soon as possible. Teams which are not executing efficiently are found out through this process and evaluated accordingly.Under such conditions, timeline estimations are still done, but they serve their only purpose of synchronizing the efforts across internal &amp; external stakeholders. The very mechanisms established to measure flow and efficiencies as part of daily work management are also used to estimate the expected achievement of timelines. After breaking down tasks into smaller activities and tracking their completion daily, the progress of activities across various teams on a project can be consolidated. This roll-up provides insight into whether project timelines are on track and, if not, highlights potential delays.&nbsp;

Unravelling the blame game in NPD project management

SummaryThis article delves into the recurring challenge of project delays in new product development (NPD). It explores how mismanaged timelines and internal blame games contribute to these setbacks. It examines what missed timelines indicate. Further, the article highlights the importance of efficient execution by project teams. It explores the fallacies in the negotiation process of timelines between top management and operational teams, revealing how strategic adjustments and misunderstandings about time buffers lead to unrealistic expectations. By identifying the root causes of high development lead times and offering synchronization solutions and enhanced communication across teams, this article provides valuable insights for improving overall project efficiency and success.&nbsp;Picture this: a conference room bathed in the sterile glow of fluorescent lights. The room and the lights witness a swarm of gloomy faces towering over a non-descript, circular table and pondering over what could have been. The topic under discussion is time management and how, for the nth time, they are in danger of missing a milestone of a significant project which would launch a new product in the market.Such sights are not uncommon in NPD project management environments. In such situations, the ire of top management is directed towards project teams executing the projects, how inefficient they are, how their commitment counts for nothing and how their trust is running on thin ice. On the other hand, each team that faces blame often shifts the responsibility to the upstream team, citing delays in receiving inputs, issues with the quality of inputs that lead to reworks, and so on.A play of blame and counter-blames ensues. Everyone seems right in his place, leading to a lot of confusion on what or who caused the problem. In such environments, any "root-cause analysis" either fails or throws up trivial solutions. Without any root cause, organizations resign themselves to expediting &amp; fire-fighting as the only way to solve problems. Expediting leads to a lot of wasted effort and creates a lot of bad blood between teams (Supply Chain vs R&amp;D, Supply Chain vs Quality, R&amp;D vs Process Engineering, etc).Organizations find themselves trapped in a vicious loop, expending energy on ineffective solutions while the underlying inefficiencies persist, undermining overall project success and progress.So, how do we achieve clarity in this conflict?Given that the issue initially arises from missed timelines, the solution may lie in deeply understanding timelines' genesis in any project…The origin of timelinesProject timelines are generally drawn at or before the start of the project. The methods of estimating timelines vary. Sometimes, a high-level estimation of individual project phases is done based on experience, and project milestone dates are drawn. In other cases, planners are brave enough to do a bottom-up estimation. They identify project tasks and their dependencies, estimate task durations, and roll them up in various ways to get the milestone dates.In both scenarios, the initial estimation, whether bottom-up or top-down, is followed by a complex negotiation process between planners and the top management.Games people play- The complex process of timeline negotiation (estimation?)Once initial estimates are established, an intricate negotiation dance ensues between the operating teams and top management. Each side strategically adjusts these estimates—adding or subtracting buffers—to guard against unexpected challenges. For instance, top management often pushes for more ambitious timelines to maintain pressure on the teams, such as trimming a 22-month estimate to 18 months, believing that a tighter deadline is necessary to achieve the original timeline. In response, operating teams anticipate this tactic and inflate their estimates, proposing, say, 26 months so that after negotiation, they secure the 22 months they initially needed. However, top management is aware of these tactics and counters by further reducing the timeline. Ultimately, the negotiation becomes less about finding the truth and more about who can outmanoeuvre the other.Good or bad, the negotiation finally ends with some mutually agreed-upon timelines. Agreement to timelines by the operating team at the end of any complex negotiation process is viewed as a commitment and true validation of the initial plan and its accuracy.Thereafter, the general assumption is that achievement or non-achievement of timelines is an indicator of system efficiency:The more milestone dates one can meet, the higher the system efficiency.Any deviation from project timelines is put up as a problem to be solved. But is it really a problem? Let's delve deeper.What does it take to achieve a project timeline….Prima facie, for any milestone date to be achieved, two conditions must be met. Both conditions are necessary for the achievement of target milestone dates:Necessary Condition 1 - The initial estimation of the milestone date at project start is reasonably accurate.Necessary Condition 2- Project teams execute the project efficiently.<figure class="image"><img style="aspect-ratio:2039/1411;" src="https://backend.vectorconsulting.in/storage/editor_uploads//necessaryconsitions_1726307399.png" width="2039" height="1411"></figure>Why is the NC1 (Estimate project duration correctly) condition necessary? – Because if timelines estimated at the start of a project are not accurate, even if the project is executed at the fastest possible speed, it may still not ensure the achievement of those timelines.Why is NC2 (Execute project efficiently) a necessary condition? - Because even if the timelines are accurate, the project teams would still be unable to achieve timelines if they do not execute efficiently.The paradoxWhich of the above two conditions are being met in a specific scenario is surprisingly difficult to find out! Why?Let's say a project achieved the timelines set for it. A quick analysis will show that the timelines could have been completed under any of the following conditions:<ol><li>Both NC1 (Estimate project duration correctly) and NC2 (Execute project efficiently) are valid- in other words, the initial estimate was correct, AND the project teams worked efficiently to execute it.</li><li>NC1(Estimate project duration correctly) is false, but NC2 (Execute project efficiently) is true- the initial estimate was too aggressive (read: wrong). Still, the execution team made extraordinary efforts to achieve them and were successful in the end.</li><li>Both NC1 (Estimate project duration correctly) &amp; NC2 (Execute project efficiently) are false, as explained in the following scenarios –<ol><li>The initial estimates needed to be corrected/aggressive, and the teams could achieve them, but only by cutting corners on the scope.</li><li>The initial estimates were wrong/buffered; therefore, the execution teams, though inefficient, could still achieve the timelines.</li></ol></li></ol>What is fascinating about the above analysis is that there are three scenarios, but there is no way to determine which scenario out of a, b, or c is active in any given case!The initial estimates may have been either accurate or inaccurate, and the projects may have been executed efficiently or inefficiently- yet the timelines can be met! Meeting of timelines is indicative of one of the possible combinations mentioned in scenarios a, b and c but does not isolate any of the two conditions as a cause.&nbsp;It's worth repeating this statement differently - a project may achieve its timelines. However, it still does not clarify whether that was due to accurate estimates of timelines at project start execution speed or both!Now, let's look at the other possibility. Let's say that a project was NOT able to achieve its timelines. The project milestones may not have been achieved under any of the following conditions:<ol><li>NC1 (Estimate project duration correctly) is false &amp; NC2 (Execute project efficiently) is accurate. Although the teams worked extremely efficiently &amp; productively to deliver the projects, the initial estimates themselves were off/inaccurate. There could have been scenarios like uncertainty in delivery times, scope creep, etc., that were not foreseen in the initial estimates.</li><li>NC1 (Estimate project duration correctly) is valid &amp; NC2(Execute project efficiently) is false- although the timelines were reasonably accurate, project teams dropped the ball at various points during the project. The efficiency of project execution left a lot to be desired.</li><li>Both NC1 (Estimate project duration correctly) &amp; NC2 (Execute project efficiently) are false- the initial estimates were inaccurate. The execution efficiency could have been better, which somehow led to failure in meeting milestone dates.</li></ol>Again, we observed a similar result! We do not know which of the three scenarios were active (a, b, or c). The non-achievement of timelines does not indicate either estimation inaccuracy or execution inefficiency. All possibilities are open even after looking at the metrics! However, most people arrive at (b) as the only conclusion if a timeline is missed!Closing the loop on the initial claim made and going back to the initial relationship that we drew:<figure class="image"><img style="aspect-ratio:2039/1411;" src="https://backend.vectorconsulting.in/storage/editor_uploads//necessaryconsitions_1726307451.png" width="2039" height="1411"></figure>The above relationship is accurate but also misleading! This means that NC1 and NC2 must be true simultaneously to meet the timelines. However, people tend to implicitly assume NC1 as accurate by default and rush to conclusions about NC2 if the timelines are met/are not met.Therefore, what's the point of looking at milestone timeline achievements when they do not deliver any insight?As a matter of fact, milestones do have one essential function.Using milestones as a means to synchronize efforts across the organizationA project typically requires a coordinated effort across multiple teams, each contributing different skills and resources to achieve a common goal. These teams can be internal or external (such as suppliers, outsourced entities, or supply chain partners). In many cases, these teams are geographically dispersed and may work on other projects simultaneously, many unrelated to the project at hand.In such a complex environment, effective collaboration and synchronization among teams is crucial, especially during critical stages of the project. This means that each team must be ready and available to receive and act on inputs from other teams at the right time. However, this can be challenging in a multi-project environment where each team has its own set of priorities and timelines.Time &amp; scheduling becomes a beneficial ally if used appropriately, in such environments.Knowing the timing of future milestones is crucial for teams to prepare and align their efforts within a project effectively. When teams know when key milestones are expected to occur, they can proactively engage in preparatory activities, ensuring that everything is in place when moving forward.For example, suppose a process engineering team knows a particular build will likely happen on a specific date. In that case, they can ensure that all necessary equipment, such as rigs, jigs, fixtures, tools, consumables, etc., are ready in advance. By preparing everything beforehand, the team can immediately begin work once the parts arrive from suppliers, minimizing downtime and potential delays.Additionally, knowing milestone dates allows teams to give specialized resources and a heads-up before their involvement is required. This ensures that the right people are available and can allocate their time effectively. When teams are prepared and synchronized with the project's timeline, the overall efficiency and effectiveness of the project are greatly enhanced.What milestones cannot do?Organizations, though, have another need which they try to fulfil by looking at milestone achievements. There is a need to monitor the execution efficiency on an ongoing basis so that they can take measures to improve the efficiency if they see it dropping. As mentioned earlier, this need cannot be satisfied by looking at milestone achievements.Is there another way to assess the execution efficiencies that do not rely on the previous faulty technique? Looks like there is one.If we could assess the execution efficiencies differently, then the need to use timelines to monitor the same would be reduced. Additionally, by taking steps to enhance execution efficiency whenever a decline is observed, we can achieve the fastest possible lead times in product development.The only reason we would still want to look at timelines would be to understand when the project will likely be delivered so that appropriate communication is passed on to stakeholders.&nbsp;Factors determining execution efficiencies on a projectThe following measures, if taken on an ongoing basis, will help us determine whether teams executing the projects are doing so efficiently:<ul><li>Monitoring resource utilization in teams</li><li>Monitoring the quality of output being delivered by teams (including intermediate outputs)</li><li>Monitoring &amp; fostering communication &amp; collaboration across teams</li></ul>If we take the above three measures and proactively resolve issues related to these, we would have ensured that projects are constantly being executed efficiently.The three measures mentioned are about asking the right questions while a project is being executed.1. Resource utilization - Efficiently executed projects make the most available resources. The following questions to be asked on an ongoing basis during project reviews will help us assess this factor and mitigate it:<ol><li>Is the project waiting for resources in any team?</li><li>If yes, how long is it likely to wait (in days or weeks)?</li><li>Is the waiting time beyond the tolerance limit?</li><li>What can we do to quickly address the situation?</li></ol>When put in place, a mechanism of Daily Work Management helps team leaders ask those questions of their team members almost daily.This mechanism includes breaking down tasks being executed by teams into smaller activities, monitoring the completion rate of the smaller activities and comparing it with the arrival rate of newer inputs to compute the waiting times. When the waiting times are too high, they can be resolved by adding more resources (from other teams or from outside) or re-engineering the processes in this team to crash the processing times.2. Quality of work - Delivering high-quality work that meets or exceeds expectations without excessive rework &amp; late revisions is another sign of efficiency.<ol><li>Excessive rework- Too often, in a project environment, we see revisions resulting from "foresight errors"- errors that could have been avoided if due process had been followed. These errors are caused by shortcuts taken under time pressure.</li><li>Late revisions- Late revisions happen when the pressure of time forces teams to postpone the scope of work to the following phases. This work typically accumulates in the final phase of a project because there is no more phase to postpone, leading to late revisions.</li></ol>The following questions, when asked on an ongoing basis during project reviews, help us assess this factor and mitigate it:<ul><li>What are all the steps required to complete an activity? Are the steps being followed?</li><li>What are the deviations being taken while performing an activity? Are these justifiable?</li><li>Are we handing over half-done work to the teams downstream?</li></ul>Again, the Daily Work Management mechanism ensures continuous oversight of processes followed and the intermediate outputs delivered by teams. Task breakdowns into activities, as mentioned earlier, help track the thoroughness of the work being done before handing it over to other teams.3. Communication and collaboration - Efficient projects benefit from clear, open communication among team members and stakeholders. Strong collaboration helps avoid misunderstandings and ensures alignment across the project. For this to happen, it is essential to synchronize priorities across the organization so that teams find common cause in working together on individual projects. Too often, we see teams prioritizing different projects while at work, leading to long waiting times when one team needs the support of another team.Mechanisms must be implemented to ensure no misalignment in priorities while different teams are executing projects.Teams are encouraged to raise issues or "support requests" on each other. The problems could be related to the physical integration of parts designed by different teams, functional integration of parts/sub-systems from various teams, and lack of clarity in inputs. Once the issues are raised, the mechanisms we put in place help us monitor and resolve them as soon as possible.ConclusionA proactive process of execution monitoring is the only way to identify issues and inefficiencies as they crop up and address them. It also serves as a way of acknowledging and rewarding the efforts of execution teams irrespective of whether they achieved the timelines set at or before the project starts.Since proactive measures are taken continuously to ensure the efficient execution of projects on a day-to-day basis, projects are completed as soon as possible. Teams which are not executing efficiently are found out through this process and evaluated accordingly.Under such conditions, timeline estimations are still done, but they serve their only purpose of synchronizing the efforts across internal &amp; external stakeholders. The very mechanisms established to measure flow and efficiencies as part of daily work management are also used to estimate the expected achievement of timelines. After breaking down tasks into smaller activities and tracking their completion daily, the progress of activities across various teams on a project can be consolidated. This roll-up provides insight into whether project timelines are on track and, if not, highlights potential delays.&nbsp;&nbsp;&nbsp;

Let's Empower Growth