Agile, Waterfall, and PMI Project Differences

I've been asking about the differences between Agile projects and traditional project management.  Many explanations err by answering the question only from a software or Information Systems perspective.  While Agile primarily appears in the software industry, the different approaches appear in many industries and product areas.

Since the Project Management Institute (PMI) offers both Project Management Professional (PMP)^® and PMI Agile Certified Practitioner (PMI-ACP)^® certifications, it would seem that Agile contrasts against traditional project management. 

However, it would be more instructive to contrast the Agile approach against the "traditional waterfall approach" of Systems Engineering.  (Refer to the International Counsel on Systems Engineering (INCOSE) for details.)

Agile uses a highly iterative approach that works better when requirements are vague and must be defined over the course of the project.  It is more appropriate for, as an example, the next set of security updates to Windows or the next year's model of the Ford Mustang.

The waterfall approach assumes progressive or phased elaboration of a fixed set of requirements that can be defined, validated, and turned into a design architecture or solution, from top to bottom.

However, Agile methods can still be used for portions of the system, particularly peripheral functions of the software. It is more appropriate for, as an example, the core of MS Project 2015 or a new hybrid squirrel-electric vehicle.

 

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

Slack, Float, and Critical Path Methodology

So as the PM I want to locate the longest path, because it will assure that I meet the project deadline.

Correct. But don't look for the "longest path," look for the "critical path." They are the same, but when you say critical path, you indicate that you know the best way to find it.

The shortest path, which has no slack, tells you as the PM that you will not be able to meet the deadline for the project.

Forget 'shortest path.' What tells you that you will not be able to meet the deadline is an end-to-end path having "negative slack." More about that later.

 

Slack is about an individual activity. Float is about how that activity's slack relates to the activities around it. They are the same thing viewed from slightly different perspectives.

 

Here's a source of confusion that I have yet to seen or hear anyone explain: For the critical path, we look for a path from the Start to Finish that has either zero or a negative number for the slack of all its activities. When we talk about a path that has slack (for example, 2 days), however, we talk about that single branch, not about a whole Start-to-Finish path.

 

Did you do connect-the-dots pictures as a child? Lets do a mental experiment. Imagine replacing all the boxes in a network diagram with their slack numbers. If there is enough time to do the project, you will see a path of zeroes from Start to Finish. In your mind, go over that path with a highlighter. That is the critical path. The durations of those boxes add up to the shortest time in which the project can be completed.

 

Suppose you add up the durations of the activities along the critical path, and the sum is 42 days. If the deadline is in seven weeks (49 days), then you have enough time.

 

If Sales promised the customer the project would be done in 40 days, but the project requires 42 days, then instead of having zeroes along the critical path, you will have negative twos (-2s). This is called negative slack. You will need to use schedule compression techniques to reduce the length of the project.

 

Note that the last two paragraphs involved only the critical path activities. None of the paths that you did not highlight in the first paragraph matter. They are all irrelevant -- up to this point.

 

Slack is also called "float" because you can move the activity forward up three days. Imagine a small cereal bowl floating in a large sink. It has room to float around. The bounds within which it can float are set by the edges of the sink. Similarly, an activity with positive slack can float within bounds set by parallel activities in the critical path.

 

Here's another confusing point. Suppose activities B and C are parallel to each other. That is, both can start as soon as activity A is done, but both must by done before activity D can start.

 

Activity B

Slack = 2 days

Duration = 4 days

 

Activity C

Slack = 0 days

Duration = 6 days

 

How long will the path that contains Activity B take? If you answered, 4 days, think again. Suppose activity A ends on day 10. Activity C takes 6 days, so activity D cannot start until day 16. So how long does the path containing activity B take? The path takes 4 days of activity plus two days of slack. It takes the same time as the longer activity (C) that it parallels.

 

Two activities done in parallel cannot be completed any faster than the longer activity. For this reason, it is a waste of time to look for "shorter" Start-to-Finish paths.

 

Activities or paths with slack (float) do not affect how long the project takes. However, there are two exceptions.

 

First, if the PM uses schedule compression techniques to shorten the project (for example, from 42 days to 40 days), then at least some of the activity durations or the relationships between activities change.

 

When the PM recalculates how long the project will take, the critical path may change. One critical path activity that had -2 slack might now have a slack of 1, so it is no longer on the critical path; and another activity that formerly had a slack of +1 and was not on the critical path may now have a slack of zero and lie on the critical path.

 

Second, every activity has risk. You can lower the risk of a non critical path activity by starting it early. You cannot do that with a critical path activity, so it carries more risk. If something goes wrong with a non critical path activity, if it takes long enough, it can still prevent the start of a critical path activity that follows it. On paper during planning, it does not affect the project's duration, but during execution, it can.

 

I hope I clarified more than I confused. Good luck!