Some of the questions that come up in my project management training oscillate between when to use the critical path techniques and why to use critical path in an agile context. My analogy to these questions is, "If the job required a wrench, why use a screwdriver? If the job really requires a screwdriver, why not use it?" I am sure some of you may recall the inspiration behind my question comes from the very old discussions on the common object request broker (CORBA) where one of the cartoon pictures summarized, "If every problem is a nail, a hammer is the only tool required!" So, the question to ask us is if all the projects are the same! The project management framework identifies several techniques and tools (not commercial tools) that must be evaluated for its purpose to solve.
Extending this analogy, let us first understand the critical path. This technique has been present for several decades and was introduced in the middle of the 20th century around the mid-1950s. Construction, Defense, Manufacturing, Supply Chain, and Transportation industries were predominant during that period building infrastructure like raising huge cities, shipping yards, rail roads, hospitals, defense systems, and highways. While there was also a limited amount of computer-based software and research and design initiatives, the mindset was that most of the projects should have a detailed breakdown of jobs to ensure resources were lined up when needed to avoid delay.
For instance, when certain workers were required to offload shipments when the ship arrived, this project was staffed with these workers around that time rather than wasting their capacity waiting for the ship to arrive. Such a concept of just-in-time (JIT) costing models were pivotal to using the capacity and capability and so projects required understanding what types of activities are crucial. So, finding the longest path in the project that can't afford to slip (hence the term Float came up) was required given the two sets of book ends (early start, late start and early finish, late finish). This is the reason why the concept of critical path emerged.
Now, let us fast forward about 50 years! We still build/upgrade infrastructure, we are also building new innovative products in the digital sphere. Software has completely eaten the world where there is not a single industry that does not have some kind of software tool or software simulation. The notion of plan-driven (Traditional), change driven (Agile) and flow-driven (Kanban) are coexisting today. In the case of Adaptive or Agile initiatives, the same team is working on the functionality in a timeboxed manner and so why is critical path required? Similarly, when flow driven initiatives apply, it is still the same core team working to eliminate queue and streamline flow invalidating the need for critical path as the focus is only on one or two items in the swim lane. One of the very reasons why the INVEST property come into picture is to eliminate the dependency among the work committed by the team (Independent). Consequently, these approaches eliminate dependency in the first place invalidating the need for critical path (activity sequencing) and using the critical chain (schedule based).
Nevertheless, still some projects may benefit from a critical path. This may involve projects in the early stage that evaluate the approximate cost required or the approximate time required to deliver. So, when Agile itself is an overhead as projects need not have such an increased interaction (e.g.: A continuous email marketing project) or the risk of experimentation may be too high (not doing the soil study before laying the foundation for a skyscraper), then, the critical path foundations may still apply.
So, the critical path is just one more tool. Use it wisely where it is needed. Not apply it in all types of projects.
Thoughts?
No comments:
Post a Comment