Tag Archives: project

Estimating Project Timelines

Posted on by
Reply

Statistically Estimating Project Timelines by Walter McIntyre

Statistics

Why is it that projects more often than not come in behind schedule and over budget? This question drives business executives crazy. Why shouldn’t there be an even split between on time project delivery and late project delivery? These are valid questions.

The answer lies in statistics and human nature. Let’s deal with statistics first. When events are independent, like in rolling a pair of dice, all possible results are independent of each other.  For example if I roll a set of two dice 20 times, I will get 20 results that range from two to twelve.  If I plot these results in a frequency plot, I will get a normal distribution (a bell curve for you non-statistical types). If I roll the dice another 100 times, I will get the same distribution. Why? Because the probability of getting a pair of 2’s on roll one of the dice is exactly the same as the probability of getting a pair of 2’s on rolls two, three, four, etc.  I could bore you with a discussion of the central limit theorem at this point, but let’s not.

Instead, let’s change the rules of dice rolling and magnetize the die so that if die one comes up 2, die number two will come up 2 also. Now the result of each roll of the dice is no longer independent. Instead the resulting sum is dependent upon whether one of the die comes up two or not. The resulting distribution of 100 rolls will be skewed instead of normal. What does this have to do with projects meeting time and budget goals?  Let me explain.

If you look at a project map, a Gantt chart for example, you will see that the tasks in the project are not independent.  They depend upon each other. For example, let’s say that task three cannot start until task one and task two are finished. This means that task three’s start time is not independent. It is dependent upon the finish time of tasks one and two. So, a delay in either task one or two will result in a late start of task three. Since there is dependency between the successful on time delivery of these tasks, the central limit theorem does not apply. Additionally, the dependency tends to push the time line to the right (late delivery).  If we were to run through tasks one, two and three 100 times, the distribution would be skewed to the right (late delivery).

The reason dependency, in this case, skews the timeline to the right is related to human nature. Estimators tend to over promise to satisfy the requirement of a bid process (work is rarely awarded to the bidder with the longest delivery time).  Workers tend to wait until the exact start date to begin work rather than start early. Surprises in the task schedule nearly always delay the completion of a task or schedule (how many times have you observed an unforeseen problem shorten the delivery time in a project?).

Practical Approach

So what is an executive supposed to do? Most look at a schedule and apply a 70% efficiency factor to it. In other words, assume the time line will be 30 % longer and more expensive than planned. Of course the more you know about a project, its customers, and the quality of your delivery processes, the better you can estimate.

Another Approach

Another approach for estimating a project timeline is using a tribal knowledge calculation.

(most ambitious completion time + (4 x the most probable completion time) + the worst case completion time)/6

I find this method to actually work pretty good. Typically you will get each of these completion time estimates from different groups.  It is also easy to sell.  One additional plus is the ability to give the results as a  date range instead of a specific date.

Project Time Estimates

Posted on by
1

Why is it that projects more often than not come in behind schedule and over budget? This question drives business executives crazy. Why shouldn’t there be an even split between on time project delivery and late project delivery? These are valid questions.

The answer lies in statistics and human nature. Let’s deal with statistics first. When events are independent, like in rolling a pair of dice, all possible results are independent of each other.  For example if I roll a set of two dice 20 times, I will get 20 results that range from two to twelve.  If I plot these results in a frequency plot, I will get a normal distribution (a bell curve for you non-statistical types). If I roll the dice another 100 times, I will get the same distribution. Why? Because the probability of getting a pair of 2’s on roll one of the dice is exactly the same as the probability of getting a pair of 2’s on rolls two, three, four, etc.  I could bore you with a discussion of the central limit theorem at this point, but let’s not.

Instead, let’s change the rules of dice rolling and magnetize the die so that if die one comes up 2, die number two will come up 2 also. Now the result of each roll of the dice is no longer independent. Instead the resulting sum is dependent upon whether one of the die comes up two or not. The resulting distribution of 100 rolls will be skewed instead of normal. What does this have to do with projects meeting time and budget goals?  Let me explain.

If you look at a project map, a Gantt chart for example, you will see that the tasks in the project are not independent.  They depend upon each other. For example, let’s say that task three cannot start until task one and task two are finished. This means that task three’s start time is not independent. It is dependent upon the finish time of tasks one and two. So, a delay in either task one or two will result in a late start of task three. Since there is dependency between the successful on time delivery of these tasks, the central limit theorem does not apply. Additionally, the dependency tends to push the time line to the right (late delivery).  If we were to run through tasks one, two and three 100 times, the distribution would be skewed to the right (late delivery).

The reason dependency, in this case, skews the time line to the right is related to human nature. Estimators tend to over promise to satisfy the requirement of a bid process (work is rarely awarded to the bidder with the longest delivery time).  Workers tend to wait until the exact start date to begin work rather than start early. Surprises in the task schedule nearly always delay the completion of a task or schedule (how many times have you observed an unforeseen problem shorten the delivery time in a project?).

So what is an executive supposed to do? Most look at a schedule and apply a 70% efficiency factor to it. In other words, assume the time line will be 30 % longer and more expensive than planned. Of course the more you know about a project, its customers, and the quality of your delivery processes, the better you can estimate.

Six Sigma Performance Teams

Posted on by
4

If you were selecting a basketball team, what criteria would you use for the selection of players? If an academic team were being selected, what would your criteria be? If the selection of a Six Sigma process improvement team were the objective, what criteria would be used?

It seems so simple, but we can sometimes make things complicated. Too much attention to politics and control will spoil the team’s chemistry. There are some simple rules, though, that can make the process less painful and more successful.

First, the make-up of a Lean Six Sigma team will need to change a little as it moves through the process improvement phases. There will be a core group of members all the way through, but there will be a shifting of other members depending upon what the team needs at the time.

There are three main types of team members: regular, ad hoc, and resource members. The regular team members attend all meetings, unless advised otherwise, and participate in all team activities. Ad hoc team members participate only when the team requires their expertise. Lastly, there are resource team members. Their meeting attendance is at the discretion of the team leader. These team members are sources of information, resources (time, money, etc.), or coaching.

The second rule has to do with the specific talents of the team members. A Lean Six Sigma process improvement team should include a process owner, a process expert, a budget and accounting member, someone from engineering (if applicable), and maybe even a stakeholder (customer). It can also be helpful to place persons on the team that may work against you if left out. Being a team member will give them buy in.

Third, a team should have a common purpose. This common purpose comes from building a common identity. The team should know what the business expects from them, as well as the known roadblocks and limitations. This third criterion can become sticky. What should a team leader do if he has a team member who is trying to sabotage the team’s work? This is not an uncommon situation.

Team Dynamics

Positive team member behavior involves respect. This respect is built upon a willingness to show consideration and appreciation for others on the team. In fact, showing respect for others is a cornerstone of a stable society. With it, there is progress and synergy (alignment). Without it, there is stagnation and disintegration. The team environment is a micro-society. A team that is respectful of others, and the team as a whole, will have the best chance of success.

The appreciation of diversity of opinion is the starting point of positive team dynamics. The point of putting a team together is to have a diversity of opinion. All opinions and ideas have value and contribute to developing a best solution or result. To be successful, the team members should recognize and celebrate diversity of opinion. This means looking for the useful and positive in everyone’s comments and questions.

Agreeing to disagree is the adult method of dealing with conflict. This is how a team gains consensus. It is also a means to allow diversity of opinion to exist and drive the team forward. By agreeing to disagree, team members do not have to let go of their opinions to move forward.

Another important aspect of respect within a team is attendance. Team members have to be present in both body and mind in order to contribute toward the team’s success. If a team member is absent, that person does not contribute and slows the team’s progress. An unengaged team member presents a similar problem.

Attendance ties in with completion of action items. Since teams use tasks and timelines to move a project forward, action items become the vehicle for team progress. The team assigns action items to a responsible person and a due date is set. This makes the team’s progress predictable and the distribution of resources easier to control. When team members do not take action items seriously, the team cannot function.

When a team is functioning correctly, everyone is contributing. Contributing means participation, voicing your opinion, and adding your brainpower to the team’s efforts. One moment you are giving information, the next you are listening, and the next you are negotiating. The resulting high energy level speeds the team’s progress. It is also more fun.

Team Leadership

The team leader plays an important role in making sure that all team members contribute. This may mean asking someone’s opinion, or slowing down a team member who is too dominating. In either case, every team member’s dignity is important.

The responsible person on a team is called a leader for a reason. This is because the leader is expected to lead and manage, not supervise the team effort. This implies that exceptional leadership skills are necessary for those responsible for managing an improvement team. A leader is more effective than a supervisor is in this case. This is because a leader gets their power from people being willing to follow (a team environment) while supervisors get their power from higher levels of management (a command and control environment). In fact, a supervisory approach to team management will prevent success. Process improvement is a “What do you think?” activity not a “Do as you are told” activity.

Team Member Behavior

Some types of team member behavior will hinder a team’s progress. An example might be the team member who is there because it is part of their performance evaluation. This person is not there for the team. They are there to service their own needs. This team member will usually find pleasure in hindering team progress with arguments that have no substance or by not helping with action items.

The “card player” is another example of an ineffective team member. This person is quietly paying attention to the ebb and flow of power. They align themselves with the winning side on issues and rarely express their real opinions. It is all about keeping themselves on the correct side (the prevailing point of view) of issues. This kind of participation is more political than constructive. As a result, their contribution can bias the results of team activities such as scoring matrices, brainstorming, and multi-voting.

An especially dangerous attitude is associated with the team member who is there to represent their boss. This person is following orders. They will express the views of their boss rather than their own opinion. When this is a means of controlling the team, there will be problems. This boss’ opinion can be valuable as long as it is not subversive. The danger for the team is when the truth is suppressed or conclusions are biased because someone in a position of power is protecting the status quo or attacking something that the team is working on.

Conflict

Dealing with conflict is an important team function. Not only is conflict unavoidable in a team environment, it is desirable. The team should cherish conflict that results from diversity of opinion. The team leader will need to intervene when the conflict becomes personal or destructive. The bulk of the responsibility for this lies with the team leader, but some responsibility lies with the other team members as well. A set of ground rules will help the team prevent conflict from dragging it away from its mission.

The first rule is that conflict will be taken off line when it becomes a problem. During a meeting, this may mean taking a break, changing the subject, or both. This allows the conflict to be isolated from the rest of the team. Before reconvening, the warring parties must agree to disagree or to develop a plan to address their differences at another time.

Another rule is to obtain an agreement from all team members to take a team perspective during conflict situations. The point is that the team’s focus is not on individuals. At an adult level of understanding, it should be clear, that in most cases, what is good for the team is also good for the individual. It is not, “What’s in this for me?” Instead, it should be, “What’s in this for us?”

A team also needs ground rules for conflict outside of meetings. Conflict outside of meetings can derail the efforts of the team as effectively as conflict during meetings. Undermining teammates, or the team’s work, with persons who are not team members will sub optimize the team’s efforts in favor of individual goals. Team issues are the team’s business, unless the team leader feels that the situation is becoming unmanageable. Then the team leader can go outside of the team for help.

Dealing with conflict is all about respect. A team that has individuals who do not show mutual respect to their teammates will not be effective. From a team leader perspective, there may come a time when they have to remove a member from the team. This is a severe action and is a last resort. Making an enemy of a former team member will create internal and external repercussions for the team.

The point to all of the above is that the team must keep their eye on the ball. The team that keeps its focus has the best chance of success. Keeping their focus means controlling the pressure to spend time on individual or political concerns.

Six Sigma Projects

Posted on by
5

  Below are some examples of potential projects. Some are good process improvement project ideas and some are not.

 1.        The installation of a new process or piece equipment that has already been selected.

 Answer: This is not a good project idea.  The decision about what to do has already been made.

 2.        Call center cycle time improvement.

 Answer: This is a good project idea. It involves the improvement of an existing process.  It may need further scope narrowing (Type of phone calls, for example).

 3.        Development of a new ad campaign.

 Answer: This is not a good project idea.  The scope is too broad and does not address improving an existing process. Even so, some of the tools that make up common process improvement methodologies can be used in the development of the new ad campaign.

 4.        Improve safety.

 Answer: This can be a good project idea.  The scope is too broad and needs to be narrowed.  If the scope were narrowed to something more specific, it would become a good project (reduce back injuries in the warehouse, for example).

 5.        Reduce the number of back injuries while unloading trucks.

 Answer: This is a good project idea.  The project is narrowed down to a specific situation involving back injuries.

 6.        Increase profits

 Answer: Not a good project idea.  The scope is too broad.

Six Sigma Success and Honesty

Posted on by
3

Not all business problems lend themselves to the Six Sigma process improvement methodologies, especially those that have short time lines. There are many problems that business leadership understand and should just fix. A Six Sigma improvement project typically requires one to six months for a team to complete, depending upon the complexity and scope of the problem. This is longer than acceptable for some problems. In addition, many of the tools used in Six Sigma do not apply well to problems that are not process based. Examples of these would be emergencies and relationship issues. Process improvement tools apply better to up-front planning for these situations, than to the situations themselves.

Two other important considerations are the impact of variation and the truth. Not all variation is bad. Without variation, there would be no improvement. Six Sigma projects use variation to find both problems and solutions. This is because the awareness of a better way to do something manifests itself as variation. Consider, for example, that there are two processes producing an identical output. The operator of one process makes a change and introduces variation between the two processes. This new process produces fewer defects than the former process. Thus, by way of introducing variation, the operator discovers a better way to produce the output. Conversely, by eliminating all variation, we eliminate all experimentation, and as a result, we eliminate process improvement. The key is to plan and control variation. By planning and experimenting, a process owner can discover new and better ways to produce the product or service.

The truth is the basis of any effort to improve processes and eliminate defects. Sacred cows, sub-optimization, and parochialism are enemies of the truth and place limits upon how much improvement is achievable. To optimize improvement, we must embrace the truth, even if it hurts. The truth will literally set us free.