So last time, we started to talk about issues related to traditional critical path and PERT based project management. I said that as advanced as PERT was when it was developed in the 1950’s, it suffered three significant flaws. data quality, scope change, and assumptions of infinite resources. Let’s explore these further and then talk about more modern approaches that address these issues.
Garbage in Garbage out: human nature is based in large part on an instinct for self-preservation. Thus, when estimating the time required to do a task, people lie. Yes, you heard me, they lie. They pad the estimates to protect their performance in a job. They insert extra time wherever they can to provide cover when things “go bump in the night”. Anyone who has worked on a task knows that things do go wrong sometimes in unexpected ways especially if innovation or great risk is involved.
Thus, every task in the WBS of a PERT plan has an accumulated piece of fluff to soften the fall of the individual worker or subproject team when the project goes behind schedule. Then on top of that, every project manager worth his weight will protect the project with extra time strategically placed along the critical path so they too will have job security if the project slips. Even though PERT has provisions to differentiate between the least optimistic, most likely and most optimistic schedule estimates, all will be distorted by the padding.
Compounding the problem is the tendency of humans to procrastinate. So even if a task has lots of padding in the schedule, much of the pad is consumed when the people assigned to the task wait until too late to get started. Then when something does go wrong, the project slips with no protection.
Scope Creep: Every project experiences creep. No matter how careful the planning is, something comes along that adds to the work. A customer changes their mind. A planned design can’t happen because a material isn’t available, and a new substitute must be developed. New regulations require additional permits. Preplanning for these changes can change the critical path and completely disrupt the PERT diagram resulting in significant schedule slippage. Complex CPM/PERT projects are incredibly difficult to re-plan even with good computer software because of the interconnections between tasks. This leads to plans full of errors or that simply fall by the wayside after a major scope change.
Infinite Capacity: Don’t worry, we’ll just add more resources. The development of PERT allowed the Polaris team to set end dates for the project much more reliably than previous schedule methods, but as time went on and schedules slipped, those commitment dates had consequences. After all we were in a cold war and the enemy had to be defeated. Thus, resources from other projects and areas of the defense world were redeployed to meet the deadline as is necessary in battle to win. While that method of resourcing works in war where everything is on the line and everyone is willing to sacrifice, going to your banker and telling him, “I just need an extra $5 Million to finish this project on time” doesn’t always work especially when his original loan to do the project maxed out your line of credit. Thus, either the schedule slips or some element of the scope must be shortchanged which means the customer is not going to be happy. A lose-lose proposition.
New ideas for a new information age
In the last 15 years of the 20th Century, new ideas began to emerge to address the shortfalls of critical path based project management. To address the time estimating issues and infinite capacity issues, Goldratt’s “Critical Chain” methods created allowances for resource constraints and added a simple but statistically based means of overcoming the schedule padding issue. Without going into great detail, schedules are protected by using an optimistic estimate of each task and aggregating the risk of schedule slippage using an insurance-like pooling of risk along a resource constrained path. Risk buffers are mathematically sized blocks of time placed at the end of a resource constrained path allows for schedule slipped within limits and a way of monitoring slippage so that corrections can be applied proactively before a project goes into peril. Its a great method that I have used with success in projects.
Now Critical Chain allows for a significant increase in accuracy predicting project dates and managing risk but it does not fully take into account human factors in projects. In order to address this failing, the next evolution had to be people based.
In 2001, a group of software developers met to discuss their dis-satisfaction with the project management of the software design and release cycle. The software industry was trapped in an endless cycle of delayed and ineffective products. Sales and marketing would identify a new need for a software product as part of some larger product or a product unto itself. The identification of a product design specification would then lead to a CPM or CCM based project plan with all the complexity that comes with it. Programmers did their little piece of code per the WBS and moved on. There was little ownership and quality control was done at the end when the finished software was completed resulting in cycles of rework to debug the code. Worse yet, by the time the code was released, customer needs had changed or there were missing features not previously understood by the project team, again requiring rework and additional releases.
Many of those in that meeting had worked in manufacturing environments where they had seen the benefits of lean and other continuous improvement techniques. Using Lean as a reference point, they though about ways to eliminate waste in the software development cycle. The result of the brainstorming in that meeting was a set of principles called “The Agile Manifesto”.
Perhaps the greatest contribution of Lean to Agile is the notion of meeting the customer’s needs. Every activity in Agile always comes back to listening and responding to the customer. Instead of a broad-brush product design specification set in stone at the outset of a project, requirements are viewed as fluid, changing with customer desires. To accommodate this, work in Agile is broken down based not in a WBS based on the organization of a company or department but based on customer requirements. Analogous to a flow process layout in a lean value stream, teams of customer-oriented suppliers code based on “user stories”. These stories are simple, elegant descriptions of a particular customer desire that can met by the people assigned to it.
Another innovation in Agile over traditional project management is the use of the skills of the work team to self-schedule and minimize the time required to accomplish a customer desire. The customer may be internal; a project leader or other manager assigned to “own” a particular customer need. In some cases, the actual customer is directly connected to the team, deepening the ownership of both the customer and the people tasked with meeting their needs. Part of the process is a setting of expectations for when the need must be met. The team can then further breakdown the goal among its members and make progress in a series of “sprints” or short intense bursts of productivity on a specific goal. By allowing those with the greatest knowledge of the work to organize its completion rather than a project manager, many of the shortfalls of a traditional WBS are overcome. And when changes do occur, the reaction time is greatly reduced, and the re-planning happens organically within the various work teams rather than as a forced reaction to a directive from on high. Schedule slippage is reduced.
Yet another important feature of Agile methods is a natural robustness to change. In the same way that reducing batch sizes improves response time to errors in manufacturing, the agile process recognizes that failure is part of the process of success. It allows for small rapid iterations in design so if something does not work the first time, the team can quickly iterate and recover.
While there are several variations to the workflow scheduling such as “Scrum” or “Kanban” (based on but not exactly like a production kanban) the similarities to lean is not co-incidence. In the past few years there have been a number of examples, where these new approaches to project management are circling back from software environment to other business project situations. In the same way that simple models of production flow like kanban revolutionized production planning and largely eliminated the planning complexities created by centralized Materials Requirement Planning (MRP) software in the 1970’s and 80’s, today Agile is doing the same in new product development and program management.
Of course, there is always a downside spin to a new and promising development like Agile. Just as how it happened when the term “Lean” was coined back in 1990, everyone wants to turn Agile into a buzzword prefix for whatever they are selling. Today we have: Agile Marketing, Agile Engineering, Agile Procurement, Agile Investing, Agile Accounting, etc., etc., etc. I am sure someone is busy working on a “Agile janitorial” practices seminar. Buyer beware.
The bottom line for me is that the next time you get involved in a project of any sort, just realize that if you apply the basic rules of continuous improvement, the process of implementing that new “whatever” will be easier and less stressful on you and your team. Instead of focusing on the fad that is agile, focus on the basics of customer-supplier relationships and value that agile can provide in aligning the customers need to your project.
Have a great day.