American Eagle Group PM Terms & Definitions

Fine-tuning Task Relationships with Lead and Lag

noreply@blogger.com (The Project Professors) — Fri, 28 Jan 2011 04:21:00 +0000

David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

PMBOK Definition:

Lag: A modification of a logical relationship that directs a delay in the successor activity. For example, in a finish-to-start dependency with a ten-day lag, the successor activity cannot start until ten days after the predecessor activity finishes. See also lead.

Lead: A modification of a logical relationship that allows an acceleration of the successor activity. For example, in a finish-to-start dependency with a ten-day lead, the successor activity can start ten days before the predecessor activity has finished. A negative lead is equivalent to a positive lag. See also lag.

Practical Definition:

Lag: A pre-defined delay between the predecessor and successor activities, as in, the delay caused by paint drying before picture hanging.

Lead: A pre-defined acceleration of the success activity in relationship to the predecessor relationship. Also known as negative lag. Used to create overlap of tasks to shorten the overall length of the project.

Understanding Lead and Lag

Lead and lag time are used in project schedules to fine-tune relationships between predecessors and successors. Many people, especially laymen – those who talk about projects, sling project management terms around, but don’t fully understand the true meaning behind the terms – confuse these terms with slack or float. They are completely different.

Slack and float mean the same thing, as described in “What is Slack? What is Float? Is There A Difference?” They are mathematical calculations and change over the course of the project. They are a result of the planning process and result in the non-critical path only. Lead and lag can exist in both the critical and non-critical paths.

Lead and Lag are defined during the planning stage and do not change over the course of the project, unless explicitly changed by the project team.

Lag in a Finish-to-Start Relationship

Lags are used to wait a period of time between tasks. For example, concrete must cure before it can be used. Therefore, the builder pours the concrete, waits four days and then builds the walls on the concrete. The Gantt chart below shows a lag between pouring the concrete and building the walls using a finish-to-start relationship.

Lag in a Start-to-Start Relationship

Let’s see what a lag in a start-to-start relationship might look like. Using the example of market research as described in the article, “Four Logical Relationships of Project Management: What They Are and How To Use Them,” we developed a survey, distributed the survey, received responses and then tabulated the results. We stated “Receive Survey Responses” and “Tabulate Responses” as start-to-start relationship. In reality, we’d wait a few days before tabulating the results. So, the resulting Gantt chart would be

Lag in a Finish-to-Finish Relationship

Using the cooking example from the Four Logical Relationship article, let’s add a pie to the menu. We can use a finish-to-finish relationship so the pie finishes 15 minutes after the food is finished. Here is the new Gantt chart:

Lag in a Start-to-Finish Relationship

Using our dinner boat cruise example from the same article, there is a 30 minute overlap between ticket window closing and the boat leaving the dock so we can pre-sell tickets for the next day. Here’s the Gantt chart:

Lead – Accelerating Successor Activity

Defining lead time into the plan accelerates the successor activity’s start time. We use lead time to shorten overall project schedules or a particular portion of the schedule. When fast-tracking a project, that is, accelerating various tasks to shorten the project, we use lead time to overlap activities.

Lead Time in a Finish-to-Start Relationship

Using the car washing example from our article mentioned above, let’s pretend we only have 45 minutes for a job taking normally 60 minutes. Normally, we’d spend 15 minutes washing, 15 minutes drying and 30 minutes waxing the car. We will overlap the washing and drying by 7.5 minutes and overlap the drying and waxing by another 7.5 minutes. The resulting Gantt chart looks like:

Of course, by overlapping the tasks, or fast-tracking them, we increase the risk of having to re-do some work. In the case where the tasks are ordered sequentially, we know the final result of the predecessor task before the successor starts. When fast-tracking, the predecessor may finish slightly differently than expected, or in the case of the car washing example, overspray from rinsing one portion of the car will require us to re-dry because of the overspray.

Lead Time in Start-to-Start Relationships

Using lead time in a start-to-start relationship causes the successor activity to start before the predecessor task. An example might be both the electrical work and plumbing can start at the same time in a house construction. Although this example might be a bit of a stretch, we show it here for illustrative purposes. Let’s say the electrician can start 30 minutes prior to the plumber. The Gantt chart would look like

Lead Time in a Finish-to-Finish Relationship

Going back to our “Four Logical Relationships of Project Management” article, we used meal preparation to illustrate a finish-to-finish relationship, where we wanted all the food to be ready at the same time. Actually, meat should “coast” for 15 minutes before cutting, which means we want to pull it out of the oven 15 minutes before serving. Therefore, we would construct our Gantt chart as follows:

We see, by adding in the lead time, we should put the meat and the potatoes into the oven at the same time. The vegetables and pie would go in 45 minutes later, at the same time we pull the meat out to let it coast. By following this timing, the main course of the meal is ready to eat at the same time and the pie is done when we finish eating the dinner.

Lead Time in a Start-to-Finish Relationship

Once again, using the same example as before – the dinner boat cruise – we can add in lead time to account for the time the owner would close the ticket sales and then hurry to the boat to collect the tickets from the boarding passengers. Let’s say, the owner closes the window 15 minutes before the boat’s departure from the dock. Using the start-to-finish relationship in case the boat’s departure is delayed, we inject the lead time designation. The resulting Gantt chart looks like

Conclusion

Lead and lag permit us to fine-tune our project plan. A lag is a pre-defined delay between the predecessor and successor activity. A lead is a pre-defined acceleration of the successor task.

We use lags when a delay must occur before the successor activity can proceed, as in waiting for the paint to dry or concrete to cure. We use lead times to compress the project schedule as in fast-tracking a project or when we can overlap tasks.

Lead and lag times can be placed in any of the four relationships of project management.

All materials are copyright (c) American Eagle Group. All rights reserved worldwide. Linking to posts is permitted. Copying posts is not.

Dependency: A Necessary Concept in Project Management

noreply@blogger.com (The Project Professors) — Sat, 22 Jan 2011 18:00:00 +0000

David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

Let’s face it, we are dependent. We are dependent on the air we breathe, the food we eat and the water we drink. Without these necessities, we wouldn’t exist.

In our projects, we have tasks dependent on other tasks. In our article, “Four Logical Relationships of Project Management: What They Are and How To Use Them,” we described the four relationships between tasks. The relationship describes how tasks relate, i.e., how the predecessor determines the start or finish of the successor.

Dependency determines the order of sequence or an activity’s placement within the project schedule. I know, it’s subtly different than relationships, but it is important to understand the subtly. In fact, many books and people interchange relationship and dependency – even the PMBOK does – but there is a difference.

Three Dependency Types

Three types of dependencies define the order or sequence of activities in the project schedule. They are

Mandatory dependency,
Discretionary dependency, and
External dependency.

Let’s define each and understand when they are used.

Mandatory Dependency

Mandatory dependencies are those that are contractually required or determined by the nature of the tasks themselves. The order in which they are performed flows from the activities’ definitions.

For example, when building a three-story building, the foundation and first floor infrastructure must be built before the second and third floors can be added. The activities dictate the order of implementation.

Mandatory dependency is also called hard logic.

Discretionary Dependency

Discretionary dependencies are defined by the project manager or team. These are the types of dependencies we like because it gives us the ability to move tasks or schedule activities based on our discretion – thus the name. It lets us decide the order or timing of task implementation.

For example, we can shift workloads by moving tasks to periods in the schedule when a particular resource is less utilized, i.e., not overworked. Using our construction example, we need to have the plumbing and electrical work finished before the dry wall is installed (a mandatory dependency between the first two activities and the dry wall installation). But, it is not necessary to do the plumbing first and the electrical second, or at the same time. They can be done in any order as long as they are completed before the dry wall installation. The project team decides the order while developing the schedule.

Discretionary dependency is also known as preferred logic, preferential logic, or soft logic.

Discretionary dependencies should be fully documented so the logic is known in future reviews. While it might be obvious during the planning sessions why the tasks were ordered or scheduled the way they were, this logic is sometimes forgotten over time and will be questioned by the reviewers or anyone not initially involved in the decisions.

Additionally, these dependencies can artificially affect total float time. Documenting, as stated above, will help future decisions and understanding.

External Dependency

External dependencies describe those tasks dependent on outside influences such as vendors, parties outside of the project such as internal departments supplying information or parts necessary for the project work, etc. These dependencies are outside of the project team’s control. They represent risk to the project schedule.

For example, let’s say the project must take delivery of 1000 widgets from supplier XYZ. Normally, XYZ delivers on-time and to specification. Recently, XYZ acquired a new customer that orders 10,000 widgets, wants them immediately and XYZ wants to impress this new customer. Your order may be put on hold while they pump out the 10,000 widgets for the new customers. Delivery to you, in this case, is late and in order to make the delay as minimal as possible, XYZ trimmed some corners and delivered less-than-expected quality widgets. As a consequence, your schedule is late and using inferior parts.

Even though you complained to your management, called Purchasing to push XYZ and re-arranged your resources as best you could, the schedule suffered.

In the event of these dependencies, the project team should plan accordingly. Buffers can be placed after these activities to account for slippage. Contractual agreements should have damage clauses to help eliminate these occurrences or at least pay for damages incurred, such as having to crash a schedule at extra expense to bring the schedule back in line, etc.

External dependencies involve relationships between project activities and non-project activities.

Conclusion

We use dependencies to order the activities in our schedule. The majority of the times, the tasks themselves dictate the order of implementation – mandatory dependency.

The favorite dependency for project teams is the discretionary dependency since we can move the work load to suit the availability of the resources. In the event we have some unexpected down time (yeah, like that happens all the time in my projects), we can move activities in real-time to fill the void.

External dependencies are the toughest to work with and represent risk areas in our schedule and require additional analysis to mitigate the consequences.

All materials are copyright (c) American Eagle Group. All rights reserved worldwide. Linking to posts is permitted. Copying posts is not.

Four Logical Relationships of Project Management: What They Are and How To Use Them

noreply@blogger.com (The Project Professors) — Sat, 22 Jan 2011 00:04:00 +0000

David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

PMBOK Definition

Logical Relationship: A dependency between two project schedule activities, or between a project schedule activity and a schedule milestone. The four possible types of logical relationships are: Finish-to-Start, Finish-to-Finish, Start-to-Start, and Start-to-Finish. See also precedence relationship.

Precedence Relationship: The term used in the precedence diagramming method for a logical relationship. In current usage, however, precedence relationship, logical relationship, and dependency are widely used interchangeably, regardless of the diagramming method used. See also logical relationship.

Practical Definition

Task relationships determine the start and finish dates of a task as it relates to other activities. The relations are labeled as Finish-to-Start, Start-to-Start, Finish-to-Finish and Start-to-Finish.

Expanded Definition

There seems to be relationships in every aspect of life. We have mathematical relationships, money and time relationships, food and wine relationships and even human relationships. So why not project management relationships.

Some relationships are simple while others are complex and baffling. Sometimes they are easier to figure out while others take a bit more noodling. These statements pertain to all relationships and even more so in project management.

Understanding these relationships and their use are critical to the project manager’s success. Why? Because most project managers don’t know they exist, don’t plan properly for their existence, and yet, the relationships exist and happen whether we like it or not.

Once we understand them, know how to apply them and plan according to their natural occurrence, the project schedule more closely reflects the reality of the project. The more closely we model future reality in our plans, the more likely we’ll succeed in our project and meet the stakeholders’ expectations. Additionally, understanding those helps us adjust our efforts and even bend reality at times to bring the project in line with what we want.

Understanding Alphabet Soup: FS, SS, FF, SF

The four relationships are:

Finish-to-Start (FS)
Start-to-Start (SS)
Finish-to-Finish (FF)
Start-to-Finish (SF)

Each relationship acts differently as predecessors and successors interact.

Predecessor vs. Successor

PMBOK Definitions:

Predecessor Activity: The schedule activity that determines when the logical successor activity can begin or end.

Successor Activity: The schedule activity that follows a predecessor activity, as determined by their logical relationship.

Before we can begin to understand the four relationships, we must understand predecessors and successors.

A Predecessor is typically the task that precedes other tasks. Successors typically occur after other tasks, or its predecessors. This is the common understanding of predecessors and successors.

In actuality, predecessors are the tasks that control the relationship between two activities. In fact, predecessors can actually occur after a successor. If that twists your mind a bit, stay with me as I explain how that can happen. I can guarantee you’ve been a victim of activity sequences where the predecessor occurred after its successor.

Finish-to-Start

PMBOK Definition: The logical relationship where initiation of work of the successor activity depends upon the completion of work of the predecessor activity. See also logical relationship.

Layman’s Definition: Once this task finishes, we can start the next one.

Practical Definition: In a Finish-to-Start relationship, the predecessor must finish before the successor can start. In fact, the predecessor’s finish date determines the Successor’s start date.

Abbreviation: FS

A Finish-to-Start relationship is typically displayed as follows:

FS is the relationship that occurs the most often within most project schedules. In fact, ninety-five percent (95%) of all tasks are related in a FS relationship. It is the most prevalent of the four relationships. As a result, many project management software packages such as MS Project use it as the default relationship. Unless specified otherwise, the software assumes activities relate in an FS manner.

It basically states once the predecessor finishes, the successor can start.

An example of FS relationships is car washing. We wash the car, dry the car and then wax the car. It makes no sense to dry the car before we wash it. And certainly waxing the car first only grinds the dirt into the paint rather than protecting it.

The activities in car washing naturally fall into a finish-to-start relationship. Of course, we could overlap the activities. In other words, we could start drying the car before we are finished washing it, but we do risk water overspray causing addition necessary drying. The overlapping of activities still follows the definition of finish-to-start relationship because the one spot being dried must be washed and rinsed first.

Start-to-Start

PMBOK Definition: The logical relationship where initiation of the work of the successor schedule activity depends upon the initiation of the work of the predecessor schedule activity. See also logical relationship.

Layman’s Definition: We want these two tasks to start at the same time.

Practical Definition: Once the predecessor task starts, we can start the successor task.

Abbreviation: SS

A Start-to-Start relationship is typically displayed as follows:

In essence, they all sound the same. The start of the successor task is gated by the start of the predecessor activity. Until the predecessor starts, the successor cannot start.

But here is another meaning people miss. It simply states the successor cannot start UNTIL the predecessor starts. It does not mean it has to start at exactly the same time. It can occur sometime after the beginning of the predecessor’s activity.

An example of a start-to-start relationship might be tabulating results from some market research. In market research, we develop a survey, distribute the survey, and wait for responses to our survey. As we receive the responses, we enter the data into a database and tabulate the information. We do not need to wait for all the responses to return before tabulating the information.

In fact, in market research, an one percent response rate is considered good. Two to four percent response rate is super. But what it really means is we will not receive from 96 to 99% of the desired responses. If we used a finish-to-start relationship between the receiving responses and tabulating the results, we’d never tabulate the responses. Therefore, once the responses flow in, we can start tabulating the results and watch for early trends. This method is what they use during political elections trying to predict the winner before all the votes are counted. Programming this example into project management software would yield the following Gantt chart:

Finish-to-Finish

PMBOK Definition: The logical relationship where completion of work of the successor activity cannot finish until the completion of work of the predecessor activity. See also logical relationship.

Layman’s Definition: We want these two tasks to finish at the same time.

Practical Definition: Once the predecessor task finishes, the successor task can finish.

Abbreviation: FF

A Finish-to-Finish relationship is typically displayed as follows:

In finish-to-finish relationships, we must wait for the predecessor task to finish before we can finish, or declare, the successor finished. And just as in start-to-start relationships, the successor doesn’t necessarily finish at the same time as the predecessor; it can finish after the predecessor.

When serving dinner, we typically experience, or want to experience, a finish-to-finish relationship. Usually, we want all the food to be ready for eating at the same time and placed on the table, arranged for the family to eat.

Using a finish-to-start relationship while preparing the food results in some portion of the meal cooked while other parts have not even been started. Using a start-to-start relationship while cooking the food can result in some items being over-cooked, under-cooked or just right. Therefore, the only relationship which works for having all the items cooked to the right doneness and placed on the table at the same time is a finish-to-finish relationship.

Let’s say our menu includes meat, potatoes and vegetables. Setting the oven at 350o, the meat takes 45 minutes, the potatoes 60 minutes and the veggies 15 minutes. To properly stage the cooking so all finish at the same time, we would put the potatoes in the oven first, wait 15 minutes, put the meat in, wait another 30 minutes and then add in the vegetables. Programming this example into project management software would yield the following Gantt chart:

Start-to-Finish

PMBOK Definition: The logical relationship where the completion of the successor schedule activity is dependent upon the initiation of the predecessor schedule activity. See also logical relationship.

Layman’s Definition: This task finishes when the next one starts, but not before then.

Practical Definition: Once the predecessor task starts, the successor task finishes.

Abbreviation: SF

A Start-to-Finish relationship is typically displayed as follows:

Read the definition again. The successor task finishes when the predecessor activity starts. Wait! How can the successor task finish, which means it started, before the predecessor activity starts? I don’t know about you, but this definition twists my brain sideways.

Fortunately, this relationship only occurs less than 1% of the time, so most people miss it, or simply don’t know it exists, but it does. I have seen many people trying to describe this relationship and frankly, most are wrong. So, I provide two here. Don’t go scurrying to the PMBOK for examples because it is conspicuously devoid of examples of these relationships except FS. Hmm…

Imagine you are a dinner boat cruise owner. The boat leaves the dock at 6:00 pm for the cruise around the city. As a smart owner, you open the ticket booth window for sales at 2:00 pm. Your goal is to sell out of all tickets before the boat leaves the dock.

At 5:00 pm, the captain of the boat calls you and says, “Hey boss, I’m stuck in traffic. I’m going to be late. Please let the customers know the boat won’t leave the dock until at least 7:30 pm.”

Six o’clock comes and all the tickets are not sold. As the owner, what to you do? Do you close the ticket sales window and wait for the boat to leave the dock? Do you close the window and go home? Or do you keep selling the tickets until the boat leaves the dock? Of course, you’d keep the window open selling tickets until the cruise is underway.

What determined the finish time of the ticket sales: the clock striking six or the boat leaving the dock? It is the boat leaving the dock. The clock reaching 6:00 pm is meaningless. The boat leaving the dock determines the relationship between the two tasks.

So we see from this example, the predecessor isn’t necessarily the task that comes first, but one that controls the task relationships. If we go back and review the other three relationships already described, we’ll see the same condition – the predecessor determines the relationship. In the start-to-finish relationship, the predecessor is the “main” event, the one determining the finish of the other activity. In the case of the ticket window opening, its opening is determined by the time of day or 2:00 pm. Whether the boat leaves on time or not does not impact the window’s opening.

As we saw, the window’s closing time was extended by the boat’s late departure. Programming this example into project management software would yield the following Gantt chart:

I understand most people reading this definition are not dinner boat cruise owners. So, a more practical example might seat the understanding into memory. Maybe not more practical, but one “closer to home.”

Remember back to the days you went to school. In order to test your knowledge of a subject, the teacher always gave a test. If you were like me, you’d wait until the last minute to cram for the exam. In fact, if the instructor showed up a bit late, you’d still be studying until the test paper hit your desk.

What determined the start of your study time? I never did figure that out, but in my case, it seemed to be panic. But I can tell you what determined the finish of my study time. The professor stating all study material must be put away. That, my fine readers, is a start-to-finish relationship.

Conclusion

Understanding the four relationships between activities in a project schedule helps model the reality most accurately. Unfortunately, most project teams only use the finish-to-start relationship between tasks. This method does not accurately schedule the activities of a project.

When planning the steps in a project, actively discuss relationships between all tasks and accurately schedule them. Just as determining the duration of a task is important, relating it to the other things that need to be done is critically important for the success of the project. You might not use all four relationships within a project, but you should at least know they exist and consider them.

All materials are copyright (c) American Eagle Group. All rights reserved worldwide. Linking to posts is permitted. Copying posts is not.

What is Slack? What is Float? Is There A Difference?

noreply@blogger.com (The Project Professors) — Sun, 16 Jan 2011 03:43:00 +0000

David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

PMBOK Definition:

Slack: Also called Float. See Float.
Float: Also called Slack. See Slack.

Total Float: The total amount of time that a schedule activity may be delayed from its early start without delaying the project finish date, or violating a schedule constraint. Calculated using the critical path method technique and determining the difference between the early finish dates and late finish dates. See also Free Float.

Free Float: The amount of time that a schedule activity can be delayed without delaying the early start date of any immediately following schedule activities. See also Total Float.

Practical Definition:

Slack or Float provide flexibility in the project schedule. When leveraged properly, project managers can shift activities and resources to meet the project objectives and priorities. It is the amount of time an activity can be delayed without impacting other activities or the project end date. Changes over the course of the project implementation.

So, What Is Slack or Float?

Slack and float are the same thing. They can be used interchangeably, so our discussion of slack and float will purposely use both. Once the concept is understood, it is more important to understand how to leverage slack time within projects.

We discussed float in the definition of the Critical Path because the critical path has no slack or float by definition. The non-critical path(s) contains the float – the amount of time an activity can be delayed without delaying successor tasks or the project end date.

A Bit o’ History

Modern Project Management practices were developed starting in the 1950s. Much of the credit goes to the US Navy while developing the Polaris project: a missile launch system from a submerged submarine. Prior to that period, no formal methodology was used to manage projects. Because of time pressure, highly classified and cutting edge developments, the leaders felt it important to standardize the implementation of the project.

It developed the Project Evaluation and Review Technique, a.k.a., PERT for managing the projects. From that methodology, we have the Work Breakdown Structure, Work Packets, PERT Analysis, and more. They coined the term Slack (float has a different meaning for the US Navy).

Meanwhile, private industry was coming to a similar conclusion: the lack of project management methodology caused many projects to fail or not be completed according to plan. It developed the Critical Path Method which determined the path of activities that defined the project’s shortest duration. From it, we gained the concept of the Critical Path, Critical Tasks, Non-critical Path, Non-critical Task, etc. They used the term Float.

Today, we follow the Project Management Body of Knowledge developed by the Project Management Institute which is a compilation of the two methodologies keeping the best of both.

Calculating Slack or Float

Total Float

In our critical path definition article, we described the method of forward passes and back passed to determine the critical path of the project network diagram, the early start and finish of each activity and the late start and finishes. Using the early start (ES) and late start (LS) information generated while calculating the critical path, we use the following formula to determine Total Float – the amount of time a task can be delayed without delaying the project end date.

Total Float = LS – ES

Each task along the non-critical path will initially have the same Total Float value.
Assume the following notation represents a specific task where

ES = Early Start
EF = Early Finish
LS = Late Start
LF = Late Finish
DU = Duration

Using the same network diagram we used in the critical path definition, shown below, we see the Total Float (TF) equals eleven (11). Note, it is the same value for the entire non-critical path (the top path). As the project progresses, various tasks may slip, be delayed or take longer than originally planned. This change decreases Total Float.

For example, assume Activity C slips by 3 days. The remaining total float would be 8 days. In fact, since Activity C slipped by 3 days, so do Activities D and E. Their Total Float values decrease to 8 days, also. If Activity D takes 10 days instead of the planned 8, Total Float will decrease another 2 days. Activity E’s Total Float then becomes 6 days.

If Activity E subsequently slips for whatever reason more than 6 days, the project will be delayed. So you can see how Total Float changes over the length of the project. This is normal of projects.

Our diagram is simple. In typical project schedules, many non-critical paths exist, each with different values for their total float. As the project progresses, their float values will change at different rates as their respective activities delay.

Free Float

Let’s understand Free Float before we discuss how to leverage this knowledge.
Free Float is the amount of delay an activity can experience without delaying any of its successor tasks. Typically, the only place you’ll see Free Float is at the end of a non-critical branch, unless the team purposely placed buffers between tasks.

Buffers are also called Reserve in the PMBOK. The PMBOK defines Reserve as a provision in the project management plan to mitigate cost or schedule risk. The reserve we are discussing here is a schedule buffer. Buffers are placed in the schedule after high-risk tasks or tasks that have a high risk of slipping, such as “Waiting for material from an outside vendor.” These can experience shipping delays, manufacturing issues, vendor priority changes, etc. These conditions can have severe results on project schedules. We lower the risk’s probably or impact (mitigation) by placing buffers after those tasks.

Back to Free Float.

We use the following formula to calculate Free Float:

Free Float = ESs – EFp - Lag

We calculate Free Float by subtracting the EF of the predecessor from the ES of the successor minus any lag between the two. Let’s understand this conceptually. Any value greater than zero represents the amount of delay the predecessor can delay without impacting the successor. If it has multiple successors, the predecessor’s Free Float is the minimum value of all those calculated.

In other words, let’s say that once the predecessor finishes the successor can start (the classical Finish-to-Start relationship). If the successor can start without any delay after predecessor finishes, than the Early Start (ES) of the successor equals Early Finish (EF) of the predecessor, therefore, ESs – Efp equals zero, there is no Free Float. Even if a lag is defined between the two tasks, Free Float would be zero because lag does not change if the predecessor slips – it simply pushes the successor task ES by the same amount of the predecessor’s delay.

In our diagram, we see Free Float (FF) in the top path equals zero for all tasks except Activity E. That is true because once the predecessor task finishes, the successor task is scheduled to start immediately. Activity E has Free Float because its successor’s ES is determined by Activity G, which finishes later, therefore, providing Free Float for Activity E.

Observation For PMP Exam Takers

For those looking to take the PMP exam, note some of the following observations:

TF and FF are zero for every task in the critical path. That follows the definition and, if calculated mathematically, would prove to be true. Thus, once the critical path is determined, you know those values will be zero.
If, while conducting the back pass and all calculations are correct, you have a value greater than zero upon reaching the first task of the network diagram, that value represents the TF and FF for the non-critical path (of course, if there is only one non-critical path in the network diagram).
FF only exists at the end of the non-critical path if there are no buffers placed in the path.
Be careful to look for lag designations such as the one between Activity F and Activity G.

Practical Application

You are thinking, “While all this understanding is fine and dandy, what does it have to do with the real world and how can I leverage it? Oh, and by the way, I’m not going to be calculating this stuff, so why the big definition?”

Certainly, in a real project where 400 to 800 activities exist, you will not be calculating this information by hand. Instead, using project management software such as MS Project (MS Project 2007 shown below), you can see and watch, as well as leverage, the float time occurring naturally or see the buffers placed after high risk tasks.

In the Gantt chart shown, the time illustrated between the green lines represents Total Float. It shows the amount any one of the tasks in the Extruder portion of the project can be delayed without delaying the project end date. It also represents the Free Float between the Extruder Delivery and the end of the project. Notice there is no other Free Float on that path or on the Critical path (shown using red Gantt bars).

How to Leverage the Free Float and Total Float

As the project progresses, the “whitespace” will change, showing the impact on the float time. You’ll want to watch it so it doesn’t “disappear” causing the project or successor tasks to be delayed.

Let’s say one of the critical tasks (shown by red Gantt bars) is not progressing as planned. If adding additional resources to the task would help bring it back in line, then moving resources from non-critical tasks might make sense. We can see the impact of moving resources from one task to another because the software will update the plan accordingly – assuming the tasks are effort-driven and developed properly. As a resource is removed from the non-critical task, its duration will lengthen. By placing the resource on the critical task, its duration will shorten. We can see the impact on the float and determine if it is acceptable.

Because our plan is in some project management software, we can play several “what-if” scenarios to determine the best avenue of re-aligning resources before we actually make the changes permanently. In this manner, we can avoid some costly mistakes.

Conclusion

Slack and Float are the same thing. We differentiate between Total Float and Free Float to understand the amount of delay we can tolerate without impacting the project schedule and successor activities, respectively.

The concept and use of float helps us keep our project on schedule and move resources more efficiently as the project progresses. The lack of float or its disappearance gives us clear indication our project is out of control and corrective measures must be taken. Additionally, by using what-if scenarios, we can understand impacts to the project

Understanding float and its use is one industry trick of successful project managers.

All materials are copyright (c) American Eagle Group. All rights reserved worldwide. Linking to posts is permitted. Copying posts is not.

What is the Weighted Scoring Method?

noreply@blogger.com (The Project Professors) — Thu, 13 Jan 2011 18:59:00 +0000

David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

Practical Definition
A method of scoring options against a prioritize requirements list to determine which option best fits the selection criteria.

The Weighted Scoring Method
Weighted Scoring is a technique for putting a semblance of objectivity into a subjective process. Using a consistent list of criteria, weighted according to the importance or priority of the criteria to the organization, a comparison of similar “products” can be completed. If numerical values are assigned to the criteria priorities and the ability of the product to meet a specific criterion, a “weighted” value can be derived. By summing the weighted values, the product most closely meeting the criteria can be determined.

Ok, that sounds a bit confusing, so let’s make it simpler.

When choosing between Product A, B or C, which product most closely matches your needs? For most people and organizations, they simply guess. “This one just seems to be the best.” “This is the number one product out there, so it must be good.” “But my brother-in-law sells this one and he tells me it is really great.” There is no objectivity or way to tell what is fact and which is fiction.

This Weighted Scoring Method can be use when selecting projects or anything where we must compare one item to another.

For example, when purchasing a new car, how do you pick the one you want? You might make a list of items the car must definitely have to be considered. Then you write down additional options you’d like to have. And you leave a few spaces to note features one car has the others don’t.

After trips to the various dealers, you tally up the list of matches and buy the one which meets the list the best. While you might not be this formal, you do it mentally. You are simply weighting some features and functions of the car of higher importance than others and if a car does not meet one of those important criteria, it is thrown out of the running.

When selecting technology for your organization, you probably have a lot more money and impacts on the business involved. A wrong decision can have dire consequences.

Real-Life Example
Here’s an example which describes how powerful this approach is.

We were called by a potential client who wanted to select some technology for their company. They had formed a taskforce from three different areas in the company. For the past 18 months, each area had different ideas as to the right technology to select. None were willing to compromise. They had actually become hostile towards one another.

Our job was to get this taskforce to consensus on a solution within two days. If we were successful, we got paid. If we failed, there would be no check in the mail.

Using a weighted scoring model and our prepared requirements list, we had the client review and weight the requirements’ priorities. Using the products selected by the three factions, we compared the functionality of each to the requirements and gave them a score. We multiplied the priority with the score to compute the weighted value, summed the weighted values and determined which product best fit their organization.

After careful analysis of the results, each member of the taskforce agreed we had our selection and to move forward with the implementation. Total time to consensus: 1.5 days. We collected our check.

The Method
The Weighted Scoring Method is best done in a spreadsheet where the requirements can be listed, a numerical priority entered, and the products to be compared recorded.

Here’s a screen shot of a typical spreadsheet format:

Column A: Requirement number uniquely identifies each requirement. Numbering can be strictly numeric or alpha-numeric to identify various identification indicating requirement’s business unit, initiative classification, budget account, etc.

Column B: Requirement description. The requirement description should be short, but descriptive enough so others understand the requirement. This may be tied for more complete descriptions in other documents via the requirement number.

Column C: Priority value assigned by the team for the requirement. Requirements should match key stakeholders’ expectations and requests. Priority values should be numeric. Values that work best are 0, 1, 3, and 5.

0 means requirement does not apply to this particular study or project. Philosophically, why would the list contain a requirement of 0? If the requirement list is standardized for a particular type of project such as project selection or even technology selection, then removing the requirement rather than rating it a zero may generate some questions later about it being missing.
1 means the requirement is of low importance at this time
3 means the requirement must be met
5 means the requirement is of high importance

If too many choices are given in the prioritization, then the task of ranking the requirements will bog down into bickering between one value and the next. Fewer choices results in a faster and just as accurate process.

Column D: Score First column of Project A or Product A or whatever is being compared. The product or project is scored against the requirement independently of the priority. Does the item meet or exceed the requirement? Does the requirement even show up on the radar for this item or is it not even an honorable mention? The scoring values are 0, 2, 4, and 6.

0 means the item doesn’t include the requirement at all
2 means the item may meet some of the requirement, but not all of it
4 means it meets the requirement
6 means the item exceeds the requirement

Again, we limit the number of choices to speed the rating process. We use the values 0, 2, 4, and 6 so people don’t get them confused with the priorities. Yes it happens and so avoid the confusion, it is simplest to change the values. The final results are the same.

Column E: Weighted Score simply multiplies the priority with the score and the results become the weighted score.

Conduct the scoring for each requirement and let the spreadsheet calculate the weighted score. When all requirements have been considered for the candidates, simply add the weighted scores for each item compared. Again, the spreadsheet can do this easily. The product or project with the highest score most closely matches the prioritize requirements.

Caution: After picking the top three scorers, a review of the scores against the requirements is necessary. The top scorer may have some low or zero scores against high priority items. Just because the winner scored zero against a high priority requirement doesn’t knock it out of consideration necessarily. Knowing it doesn’t meet or exceed a requirement is crucial for future planning. Since its deficiency is known, work-arounds and other approaches can be taken or planned proactively rather than reactively when discovered later.

Conclusion
The Weighted Scoring Method is a powerful but flexible method of comparing similar items against a standard, prioritized list of requirements or criteria. We’ve used this method in less formal ways when buying personal items without even recognizing it.

It provides a level of objectivity in matters where subjectivity can have major negative consequences. It can be used for project and product selection, risk response analysis and solution design. The method described here has be proven in real-world scenario and is structure for efficient use of time for those involved.

In the end, the choice is yours. The weighted scoring model is simply a tool, a technique to help guide your decision making.

All materials are copyright (c) American Eagle Group. All rights reserved worldwide. Linking to posts is permitted. Copying posts is not.

The Critical Path - A Tool To Keep The Project On Schedule

noreply@blogger.com (The Project Professors) — Thu, 06 Jan 2011 21:15:00 +0000

David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

PMBOK Definition
Generally, but not always, the sequence of schedule activities that determine the duration of the project. It is the longest path through the project.

Practical Definition
The longest paths of tasks through the project plan with zero float or zero slack.

Defining the Critical Path
Normally, the critical path defines the overall length of a project. Why is that important? It means that if any task along that path, known as a critical task or critical activity, slips by even one day, the project will suffer a day-for-day slip minimum. The project may slip more depending on the impact of the slip on resources or other factors, but at minimum, the slippage will be at least the amount of the task’s delay.

In some cases, a small slip won’t impact the overall project’s success, but if time is the driving constraint (see Triple Constraint and Beyond), any slip must be managed carefully.

What is Slack or Float?
Slack and float are the same. We have two different terms for slack and float because of project management’s history. Modern project management began in the 1950s. Of course, project management has been around for a very long time. Certainly, the Egyptians used some form of project management to build the pyramids and other massive structures. In fact, they employed project managers, although they usually held the title of slave masters. Their tools of the trade were not schedules and budgets, but whips and chains. We are not permitted to use those tools anymore, therefore, we must resort to project plans, due dates, and funding constraints.

In the 1950s, the US Navy developed the Polaris Missile and submarine (for an interesting account of that project as it relates to Risk Management, read Polaris: Lessons in Risk Management). At the time, they had no formal process in which to manage the project. During that time, they defined PERT – Project Review and Evaluation Technique, a methodology we still use today. They defined a term called slack which represented a period of time a task might be delayed without impacting the project schedule or its successor task (they couldn’t use the term float because that has a different meaning when it comes to the Navy).

At the same time, private industry developed a methodology called CPM – Critical Path Method – with a similar concept called float. Both consider the amount of time an activity may be delayed without impacting the project schedule or its successor task.

On the critical path, there is no slack or float. No task or activity can be delayed without impacting is immediate successors or the project schedule.

See Slack or Float for a more complete definition and the use of slack or float in managing projects.

How to Determine the Critical Path
Determining the critical path is relatively simple. We simply create a network diagram of the project, traverse each path adding the durations of each task of the leg. Whichever leg has the greatest duration becomes the critical path. Since we start at the beginning of the network diagram and travel toward the last task, we call this the forward pass.
We conduct a similar process backwards through the diagram, called the back pass, which gives us values used to determine the float times for each activity.

Using the diagram below, lets understand what this means.

The following notation represents an activity (task and activity are the same and used interchangeably, although the PMBOK has migrated to the use of activity exclusively).

ES = Early Start – the earliest the task can start
EF = Early Finish – the earliest the task can finish, calculated from the ES plus the duration
LS = Late Start – the latest the task can start without impacting the project schedule
DU = Duration – planned value
LF = Late Finish – the latest a task can finish without impacting the project schedule

The Forward Pass - Determining the Critical Path
We start the process with the forward pass beginning with the first task, Activity A in the diagram above. We start with 0 since it is the first day. We determine EF by adding the DU to ES. In this case, EF for Activity A is 10 because 0 (ES) plus 10 (DU) equals 10 (EF).

We can either copy the value of EF of Activity A to the ES of Activity B or we can add 1 to the EF since Activity B will presumably start the next day. If we add one to EF going forward, we must remember to subtract the 1 as we do the back pass. It is easier and just as accurate to simply copy the value as adding and subtracting 1. For the diagram above, we simply copied the value from the EF of the predecessor task to the ES of the successor task.

Caution: You will note on the bottom branch of the diagram a designation FS 8. This represents a Finish-to-Start relationship between the two tasks with a lag of 8. We must add the lag value of 8 to the EF to generate an accurate ES for the successor task.

Note: Activity H has two predecessors: Activity E & G. Both may determine its ES. During the forward pass and following the top path first, Activity E’s EF is 50, which following this method, would be copied to the ES of Activity H initially. The value is replaced by Activity G’s EF when computing through the bottom path because it is greater, thus extending the project’s overall end date. During the forward path, greater values replace lower values when an activity has more than one predecessor. So we see that Activity H’s ES and EF are 61 and 66 respectively. Thus, the project’s shortest duration is 66 days. The bottom path determined the project’s length and is identified as the critical path (and was highlighted in red for illustrative purposes).

The Back Pass – Determining the Float of Each Task
Once we have finished the forward pass, we can begin the back pass. The back pass generates the numbers we use to determine the float values for each task – the amount of time a task can be delayed without delaying a successor task or the project end date.

To conduct the back pass, we start by copying the EF of the last task, in this case, Activity H, into the LF (late finish) of the last task. Thus, by definition, the EF and LF of the last task of the project are equal. This only makes sense because, if the last task were to slip, the project end date would also slip. Therefore, the early finish and the late finish of the last activity must be equal.

Next, we subtract the DU of the last task from the LF to derive the LS of the last task. Again, the ES and LS of the last task should be the same, by definition. We continue the back pass by copying the LS of the task into the LF of any predecessor task. Of course, if any lag time is designated, we must subtract it from the value first as noted in the caution above. We continue this process for each predecessor until we reach the first task in the project.

In the event a task has two successors, as Activity B does in the above diagram, the lowest value is copied into its LF position. If we have done all the subtraction operations correctly, when we reach the LS of the first task, it should be zero for at least one of the paths in the diagram. If you do this exercise on the network diagram above following the top path first, you’ll note the value of LS for the first activity will be 11. Once you complete the back pass of the bottom path, LS of Activity A will be 0.

Computing Slack and Float For the Diagram
By definition, activities on the critical path, known as critical activities, should have no float or float should equal 0. Since we’ve determined the bottom path above is the critical path, we can simply assign 0 to both the Total Float (TF) and Free Float (FF) of each activity along the path. We will prove this mathematically correct later.

To determine the Total Float for the non-critical activities, those activities appearing on the non-critical paths, we subtract the ES from the LS of the task. For example, Activity C’s ES is 25 and LS is 36. Subtracting 25 from 36, we calculate the Total Float for Activity C to be 11. Assuming this represents 11 days, the answer tells us we can let Activity C slip by 11 days without impacting the project end date. If Activity C were to slip by 12 days instead, the project end date would also slip.

Calculating Total Float for each activity along the top path of this diagram, we soon realize Total Float for each task is the same at 11 days. Let’s understand what this means.

At the start of the project, Activities C, D, and E can slip a maximum of 11 days total without impacting the project end date. If Activity C were to slip 3 days or take 3 days longer than originally planned, then Total Float would decrease to only 8 days remaining for Activities D and E. Furthermore, if Activity D would slip an additional 5 days, Total Float would adjust to 3 days meaning Activity E only has 3 days of leeway without impacting the project end date. So you can see, Total Float changes as the project progresses and activities slip or take longer to complete than originally planned.

Proving mathematically that Total Float on the critical path is 0, we simply subtract the ES of a critical task from its LS and we calculate 0 because ES equals LS for critical tasks.

The formula for calculating Total Float:

Total Float = LS - ES

Calculating Free Float
Free Float is the amount of time an activity can slip without impacting the ES of a successor task. To calculate Free Float, we subtract the EF of the predecessor task from the ES of the successor task minus any specified lag time. The formula looks like this:

Free Float = ESS – EFP – Lag

where the subscripted S is the successor task and the subscripted P is the predecessor task. The only activity that has Free Float above is Activity E. Initially, it can slip 11 days without impacting Activity H, its successor. As the project progresses, Free Float can change just as Total Float changes. You can perform the Free Float equation on all the other tasks and easily see Free Float is always zero. In fact, the only place you’ll see Free Float is at the end of a non-critical path, unless you inject buffers into the schedule manually.

Once again, you can prove Free Float is 0 for critical activities by using the formula stated above.

Of Course You Wouldn’t Calculate The Critical Path By Hand In The Real World…
The diagram above only depicts 8 activities. Real project plans typically have 400 to 800 tasks. Determining the critical path by hand would be very time consuming. Fortunately, software programs such as MS Project contain the capability to determine the critical path for us. MS Project highlights the Gantt bars in red when viewing the Tracking Gantt view. Non-critical tasks are displayed with blue bars, by default.

Understanding how the critical path is determined is important for project managers so they can leverage the slack or float time accordingly to help keep critical tasks on schedule. Leveraging the float time is described in more detail in the article describing that topic.

The critical path works in conjunction with the knowledge of the triple constraint discussed in the article Triple Constraint and Beyond.

Conclusion
The critical path is an important tool in the project manager’s toolkit. Understanding its importance and relationship to the project schedule help project managers keep projects on-time. When used in conjunction with the triple constraint (or sextuple constraint as described in the Triple Constraint and Beyond article), project managers can deliver more projects successfully.

The Triple Constraint and Beyond

noreply@blogger.com (The Project Professors) — Mon, 03 Jan 2011 04:38:00 +0000

David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

Practical Definition
The factors which help the project manager deliver a successful project. One constraint drives the priorities while another supports the delivery of those priorities.

Defining the Triple Constraint
The three factors by which we can define our project. They are Time, Money and Scope. Some say Schedule, Budget, and Scope. Or any combination.

Description
The Triple Constraint, sometimes referred to as the Iron Triangle, represented the three major determining factors of a project.

Time or Schedule is the length of time for a project. Sometimes, the length is determined by a hard, pre-defined or drop-dead date. If the project finishes after the date, the result is useless.

For example, if you are planning a party and the cake and gifts arrive a day later, they did not meet the time required. The guests are gone and the usefulness of the cake is diminished.

Sometimes, the time duration is determined by the sequence of events and the accumulated duration for each event in their order of execution. For example, if it takes 20 minutes to wash a car, 10 minutes to dry it and 1 hour to wax it, then the total duration for the project is 1 hour 30 minutes assuming no breaks or wasted time between tasks.
Money or Budget defines the cost of the project. There may be an upper limit as to how much can be spent in order to achieve the desired or defined results.

For example, if you only have $300,000 to spend on a house and can’t possibly find a penny more in the budget and the house you want costs $350,000, you have some decisions to make concerning the features to eliminate or pick a different floor plan.

Scope defines the deliverables that must be produced to meet the project requirements. Anything less constitutes an unfinished or incomplete project. Anything additional defines things not necessary for the project.

For example, if the plans call for a five car garage and the builder only builds three, the house would be considered unfinished and unacceptable. If the builder adds an additional bay, then the timeline and budget would be impacted.

These constraints relate to each other. For example, with more money, we can typically add more to the scope, e.g., a bigger house with more bathrooms. With more time, we can be concerned about the details so each item is completed to our exacting standards. With less scope defined, we need less money and time.

The Triangle
Usually, the Triple Constraint is drawn as an equal-lateral triangle. In order to keep the angles the same, as one leg of the triangle lengthens or shortens, the others must do the same. As the budget is cut, the scope must decrease along with the time. (I know, I hear you saying, “In your dreams, buddy. Get into the real world.” I know because I’ve been there more times than I like to remember, but just stick with me.)

While it is interesting to know about the Triple Constraint, how does it really help me in managing real projects?

Driving, Weak and in the Middle
The key concept to know is the relationship between the constraints in respect to the key stakeholders expectations or desires. We label the constraints as

Driving Constraint
Weak Constraint
Middle Constraint

The Driving Constraint drives the project. If the budget is the most inflexible, i.e., it can’t be increased, we must meet that budget to be considered successful (see Successful Project Definition). The Driving Constraint is the constraint our key stakeholders are the most unwavering on. We must meet the Driving Constraint.

Additionally, we must know the Weak Constraint. The Weak Constraint is the constraint with the most flexibility. It is the one we wiggle around on in order to keep the project on time and on budget. If the budget is the Driving Constraint and the Scope is the Weak Constraint, then we as the project manager might recommend a change in scope in order to hold to the budget. We might decide some features can wait until another time or they are not as important as preserving the budget.

Buying a car might be an example of the budget driving the purchasing project while the car features might be the most flexible during the negotiation process. We might be willing to forgo certain luxury features to keep the monthly payments within our means.
The Middle Constraint is just that. It is more flexible than the Driving Constraint and less flexible than the Weak Constraint.

Who Decides Which is Driving and Which is Weak
Unfortunately for us project managers, we don’t pick the driving, middle or weak constraints. The key stakeholders do that for us. We must learn from them what is most important and which is the most flexible concerning the three: Time, Money and Scope.
If your stakeholders are anything like mine, and I suspect they are, simply asking them which one is the most important will only yield, “All Three!” But the ole project management adage states, “You can have it good, you can have it fast, and you can have it cheap. Pick two!” One drives the project and one is “flexible” – within reason, of course.

Usually, stakeholders are not forthcoming in offering hints suggesting which the driving or weak constraints are. Fortunately, sometimes the project provides some ideas. Sometimes a date becomes our deadline such as a budget freeze, drop-dead date, etc. Sometimes the budget is set by the size of the grant, the amount of the loan or other factors. But many times, nothing finite is apparent which leaves us interviewing the stakeholders trying to discover, based on their answers and reactions, the weighting of the constraints. The interview process is a critical business skill in itself and beyond the scope of this article (regardless of time or budget.)

The Dark Side of the Triple Constraint
There is a downside of the Triple Constraint. It would be nice if their priorities remained the same throughout the entire project. Unfortunately, this is not so. On top of that, many key stakeholders change their minds, project factors change (budget cuts, company priorities change, customers modify their orders, fickle markets adjust, etc.) and a myriad other reasons. An astute project manager must be sensitive to such “alignments” to shift project resources and focus accordingly.

To add insult to injury, we typically are not warned or informed of such shifts. We typically learn about the changes after the fact. Therefore, we must be proactive and through continual contact with the key stakeholders and probing them with questions, ascertain the constraint priorities. If the priorities change, the project manager must adjust accordingly.

Using the Knowledge of the Triple Constraint
So, how do we use the Triple constraint knowledge to our advantage and manage our project according to the stakeholders’ priorities?

Every project ebbs and flows, just like a river. Sometimes, progress is advancing without hindrance and other times, it hits bumpy waters like rapids. Other times, it slows to a crawl. Leveraging the Triple Constraint, we shift resources to tasks to get the progress back in line. If time is the driving constraint, we put resources on the tasks that could delay the project time line. If we can burn through a few more dollars, adding additional resources might be a better option. If eliminating some features of a project or delaying their implementation until a later release will keep the project time in line, we make the recommendations for the changes.

If budget is the driving constraint and time is the weak constraint, we hire cheaper labor with less experience, and therefore, take longer to perform the tasks at hand.
The Driving Constraint dictates the focus of the project manager while the Weak Constraint provides the leverage to align the project with that focus.

But Wait, There’s More…
In the Fourth Edition of the Project Management Institute’s Project Management Body of Knowledge (PMBOK), the guide for industry standard project management practices, the authors expanded the Triple Constraint by stating there are more constraints impacting projects. On page 6, they list

Scope,
Quality (a level of quality must be met requiring more time and money),
Schedule (overall length of project or forced downtime such as plant closings, weather delays, etc),
Budget (limited funds, budget cuts or funds unavailability),
Resources (a resource may not be available when the schedule states causing a delay in the overall project), and
Risk (space program must launch at specific time to lower risk of weather patterns could delay launch, etc.)

Any one of those can drive a project’s focus. Regardless of which constraint above becomes the driving constraint, the project manager must strive to understand the weak constraint(s) to keep the driving constraint on course.

Conclusion
The Triple Constraint, or its new variant – Sextuple Constraint – is the project manager’s best friend. Understanding their relationships to the key stakeholders’ priorities help the project manager deliver successful projects. Knowing which constraint determines the project’s success, we can leverage other factors to meet the requirements.

Managing projects is never easy or foolproof. But sometimes, having just one tip in our pocket aids us in getting it home safely.