Schedule Estimating Threshold

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

A question people ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more) the activities should be no longer than two weeks. Medium and small projects (say 1000 effort hours or less) should have activities no larger than one week. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller than your threshold allows the work to be more manageable. Think about it. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). (Yes, you can track progress if the work proceeds linearly – like painting a wall. But many of us work in the knowledge business (IT, Sales, Finance) and it is not easy to know exactly how the work is progressing.)

Let’s look at an example. If you assign a team member work that is due in four weeks, you are not going to know for sure whether the work is on time until the four-week deadline. The worker may tell you things are on track, but you don’t really know for sure until the due date. If the work is completed you will know you are on track. If the work is late you will know it then as well. However, four weeks (or longer) is too long to wait to know if the work is on track. A better approach is to break the four-week activity into four one-week activities. Then you will know after the first week if the work is on time or not.

If at all possible you want to try to have schedule work completed within two weeks. If you give someone work that takes four weeks or longer there is just too much time before you really know if things are on-track or not. It is much better for you if you can keep the schedule feedback loop to no more than two weeks.


Manage the Schedule for Small Projects

All projects need a schedule. If you have a small project perhaps the schedule is a simple checklist or Excel spreadsheet. As projects get larger they need more formal scheduling templates and tools.

The processes you use to manage a schedule also vary depending on the size of the project. Large projects need a lot of schedule management rigor. Small projects can use a lighter process. The following steps can be used to mage the schedule of a small project.

Review the schedule on a weekly basis.

Identify activities that have been completed during the previous week and update the schedule to show they are finished.

Determine whether there are activities that should be completed, but are not. Work with the individual that is assigned to the work see what is going on. Determine how much additional effort and duration are needed to complete the work and update the schedule accordingly.

Evaluate the remaining work to see if the project will be completed within the original duration. You may find that even though some activities may be completing later than planned, other activities may be completing early and the overall schedule may still be okay.

If your project is trending behind schedule, think of schedule management techniques you can apply to get back on schedule. Raise a schedule risk in your status report if the original deadline appears to be in jeopardy.

Adjust the schedule so that it reflects the remaining work to be completed, and is as accurate as possible.

Since this is a process for a small project, it would be unusual to have major problems with the schedule. The consequences of problems on small projects are generally small as well.


Define the Objectives of Your Project

Define the Objectives of Your Project

Objectives are concrete statements that describe the things the project is trying to achieve. They are included in your Project Charter. An objective should be written in a way that it can be evaluated at the conclusion of a project to see whether it was achieved. A well-worded objective will be Specific, Measurable, Attainable / Achievable, Realistic and Time-bound (SMART). (SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to “upgrade the customer service telephone system by December 31 to achieve average client wait times of no more than two minutes“.

  • Note that the objective is specific.
  • The objective is measurable in terms of the average client wait times the new phone system is trying to achieve.
  • You can assume that the objective is achievable and realistic.
  • The objective is time-bound, and should be completed by December 31.

Objectives should infer the deliverables of the project. In the prior example, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables (such as speed or ability to handle a specific number of users), it is written at too low a level. Characteristics tend to be more requirements statements – not objectives.

If the project is a part of a larger program, the objectives of all the underlying projects should be in alignment with the program objectives.

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. For example, the specific deliverables of an IT project may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Objectives are also valuable since they provide alignment to organization goals and strategies. Your organization should not authorize projects that do not tie to goals and strategies

The project objectives should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives. A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.


Four Steps to Show the Value of Training

Four Steps to Show the Value of Training

Many businesses struggle with whether they are getting their money’s worth in sending employees to training classes. This question can be applied to project management training as well as any other type of business training. You know the cost side of training too well. But how do you tell what the business value is?

The most common way to determine value today is to ask the trainee whether he or she thinks the class was valuable. This is very touchy-feely and doesn’t give you much information to go on, but it is probably the most that most companies ask in terms of follow-up.

A Rigorous Approach

There is a process to more rigorously determine the value received for your training dollars. These ideas are not for the faint of heart. They take more preparation and they take more of that most precious commodity – time. But see if it makes sense, and whether the results of this process will give you a much better feel for the value that you are receiving from training. You can also start with some of these steps, and try for the rest later.

  1. First, the trainee and their manager meet a few weeks before the training is scheduled to make sure the trainee is ready for the class. One of the important parts of the discussion is to identify opportunities where the trainee can apply the new skills on their job. This information should be documented so that it can be compared with a post-class assessment done later.
  • When the actual class begins each of the trainees should complete an initial survey showing their specific knowledge level of the class material.
  • A week or two after the class, the trainee completes a post-class survey showing their current knowledge level in the subject. For the most part, it is exactly the same as the initial survey from activity #2 above. This is compared to the initial survey to provide a sense for how much the trainee learned – at least in their own opinion. If this survey comes out close to the original version, it may show that the training may not have been very effective. You would expect that the post-class survey would show improvement.
  1. Here is the key step. A few months after the class, the trainee and their manager meet again for a post-class assessment, which is a follow-up to activity #1 above. In this discussion, the trainee and manager discuss the value of the class, and whether the trainee has been able to apply the new skills. In fact, the training may have been superb, but if there have been no opportunities to apply the new skills, then the business value will be marginal. The trainee and manager can then discuss the business value that was gained by applying the new skills on the job.


In most training classes today, the trainee completes the class feedback for the benefit of the training company, and then tells his or her manager how good the class was. This superficial feedback is all that is available to gauge business value. However, the real test of business value is whether the class resulted in an increased skill level that can be applied to the job to make a person more productive. This cannot be determined immediately after a class. The only way to determine business value is to determine in the months after the class whether or not the training has actually been applied on the job. If you capture this information on all your classes, you will get a much better and more fact-based view of whether the classes you pay for are providing business value to your company.


Three Techniques for Scope Change Management

1. Hold Everyone Accountable for Scope Management

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, your customer may try to go directly to team members for changes.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. Your customer  must also understand the process and its importance. Don’t consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

2. Use a Change Control Board for Large Projects

Sometimes on very large projects, the project sponsor does not feel comfortable making the scope change decisions alone. This may especially be the case if the effect of the change will impact other organizations. It may also be the case that multiple organizations are participating in, or contributing to, the project funding, and want to have some say in evaluating scope change requests. For these cases, a group of people might be needed to handle the scope change approval.

A common name for this group is a Change Control Board. If a Board exists, it may be more cumbersome to work through. However, the general scope change management process does not need to change dramatically. For instance, there is still a document for the initial the scope change request. The project team needs to determine the impact and cost to the project. The Board must consider the impact, the value to the project, the timing, etc., and then make a determination as to whether the request is accepted.

The Scope Change Procedures must be more sophisticated to account for the Board. For instance, you need to clarify who is on the Board, how often they will meet, how they will be notified in emergencies, how they will reach decisions (consensus, majority, unanimous, etc.), how incremental work will be paid for, etc.

3. Make Sure the Right Person Approves Scope Changes

A typical problem on a project is that the team does not understand the roles of the sponsor, customer and end users in the area of change management. In general, the project sponsor is the person who is funding the project. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. 

The people that the project team tends to work with most often are normal customers and end users. End users are the people that use the solution that the project is building.

It doesn’t matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change. The sponsor (or designee) must give the approval. The end users can request scope changes, but they cannot approve them. The end user cannot allocate additional funding to cover the changes and cannot know if the project impact is acceptable.


Five Steps Before Estimating Work

Estimating is hard enough. It is even harder if you are not prepared. Estimating a 20 hour chunk of work is not so hard. Estimating for full projects or large chunks of work can be challenging. Templates can help, but consider the following steps before you begin the estimating process.

Get a clear picture of the work that is being estimated

Many problems with estimation come because the estimator is not really sure what the work entails. You should avoid estimating work that you do not understand. This should not imply that you can know every detail. The estimating contingency is a way to reflect some of this remaining uncertainty.

Determine who should be involved in the estimating process

The project manager may or may not know enough to make the estimates on his or her own. It is usually a good practice to look for estimating help from team members, clients, subject matter experts, etc. This will usually result in the estimates being far more accurate than you would get by yourself.

Determine if there are any estimating constraints

If there are estimating constraints, it is important to know them up-front. For instance, the end-date may be fixed (timeboxed). You should also know if the client expects Six-Sigma level quality in the deliverables, or if the 80/20 rule will apply. It is possible that there may be a fixed budget that cannot be increased. (This would be of interest so that you can reduce the scope of work, if necessary, to meet the fixed budget.) Knowing these constraints will help the estimators make valid assumptions regarding the cost, duration and quality balance.

Determine multiple estimating techniques to utilize if possible

There are a number of techniques that can be used to estimate work. If possible, try to use two or more techniques for the estimate. If the estimates from multiple techniques are close, you will have more confidence in your numbers. If the estimates are far apart, you need to review the numbers to see if you are using similar assumptions. In this case, you can also try to utilize a third (and fourth) estimating technique to see if one initial estimate can be validated and the other rejected.

Document all assumptions

You will never know all the details of a project. Therefore, it is important to document all the assumptions you are making along with the estimate.

Risk Management Uncategorized

Understand the Risk Tolerance Level in Your Organization

All projects have risks and all risks have the potential for negatively impacting the project. You use risk management to determine the risks that are important enough to manage. During the risk identification process, you may encounter many risks that have some likelihood to occur and have a marginal impact to the project. The question to ask is whether the risk has enough impact on the project to worry about (this same question occurs for both qualitative and quantitative approaches). The answer says something about your risk tolerance.

For example, let’s say you identify a risk that is very likely to occur, but has an impact of $100 and one-half day duration. You may choose not to manage it. You cannot list this as an assumption since there is a good chance the risk will occur. However, the impact is small enough that you are willing to absorb the cost if it occurs, rather than deal with managing the risk (which would probably be more costly). Therefore you would choose a risk management strategy of leaving the risk.

In the prior example, the numbers were fairly trivial and the risk was easier to ignore. But, ratchet the impact up a little higher. Let’s say the risk now was $500 and one day duration. What about $100,000 and three months duration? Of course, the answers are all relative based on the size of the project. If your project had a $20,000 budget, a $1,000 risk impact might be worth managing. If your project budget is one million dollars, the risk impact of $1,000 would just be marginal.

When you are performing risk identification, you need to determine your tolerance level for risks. This will help you focus on the risks that are important and above your tolerance level, while ignoring risks where the impact falls below the tolerance level. Risk tolerance is also cultural in your organization. Some organizations are bigger risk-takers and will accept a higher level of risk on projects. They will also tend to have a higher threshold before they chose to manage a risk.

On the other hand, some organizations are more risk-averse. They will tend to accept less risky projects and they will also tend to have a lower threshold to manage risks. For example, let’s say you have a similar project in both organizations. The project managers in these risk-averse organizations will tend to manage risks that a project manager in the other organization might choose to leave.     


The Power of the Aligned Organization

When was the last time you rode in a car with wheels that were not properly aligned? Chances are it was a pretty rough ride. The car either pulled in one direction, making it hard work to keep it in your lane, or, it worked against itself as one tire pointed one way and another tire another way.

The same thing can happen in our companies. The ride can be pretty bumpy, not to mention noisy, unless everyone is pointed in the same direction. That’s why it’s important to understand the five benefits of an aligned organization

Benefit #1 – Ensures Everyone Works on the Right Things

The first benefit of an aligned organization is that with a common goal for everyone to strive towards, the right things are worked on. Here’s the trick – you need make sure that everyone clearly understands the goal and the end game. The best way to accomplish this is to clearly communicate the strategy of the company. What are the three to five most important things your company is working on? Once those are communicated and understood, you can then align everyone’s activity to accomplish those initiatives.

Benefit #2 – More is Accomplished

An aligned organization is structured and disciplined. This doesn’t mean the company lacks creativity or is oppressive. Rather, it means that projects not aligned with company strategy are not allowed to infiltrate the company. Alignment allows resources to stay focused on the tasks at hand and not waste time on other distractions.

Benefit #3 – Teamwork Increases

A third benefit of alignment in the organization is increased camaraderie. The ‘us’ versus ‘them’ mentality is nipped in the bud while everyone works toward the same goals together. Departments and groups of people that are not properly aligned have a tendency to look after their own interests. This will still occur in the aligned organization, but there is also more of, “what can I do to help?” Team members in the aligned organization realize that everyone must cross the finish line at the same time in order for the project to be successful.

Benefit #4 – Profitability Rises


An aligned company is a company that runs efficiently. Engaged teams that are working on the right things are naturally going to get more done. Getting more done in less time results in increased profitability. There are fewer misunderstandings and mistakes – and rework is few and far between. Alignment helps keep resource costs in check, and reduces expenses, both of which are areas that impact the bottom line.

Benefit #5 – Opportunities Abound


People like working with people and companies that have a track record of success. The aligned organization will have plenty of success stories to tell. That credibility allows salespeople to sell more, executives to explore new strategies, and managers to optimize opportunities. It generates more top-line revenue that ultimately trickles down to the bottom line.

A car that is not aligned will still run; however, the ride is rough and it’s not very efficient on gas. Once aligned, the car rides much more smoothly and fuel efficiency increases dramatically. Your company can still run if it’s not aligned, just not very efficiently. Take the time to align your organization and begin realizing the benefits!


The Customer May Not Know Enough to Completely Define the Project

Sometimes the project manager places too high an expectation on the amount of foresight and vision that customers and sponsors have. In many cases, the project manager will go to the customer looking for answers to help define the project and the customer will not have all of the information needed. This happens all the time and it does not mean that the customer does not know what they are doing. In many cases, especially for large projects, the customer has a vision of what the end results will be, but cannot yet articulate this vision into concrete objectives, deliverables and scope. 

There are three approaches for when you don’t know very much information on the nature of the project.

Increase Estimating Range Based on Uncertainty

Based on having less than complete information, the  project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining. On a normal project, for instance, you might estimate the work within +/- 10%. On a project with a lot of uncertainty, the estimating range might be +/- 50%. 

Break the Work into Smaller Projects

Another good alternative is simply to break the work down into a series of smaller projects based on what you know at the time. Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, in turn lead to the information needed for the final solution. You can define a project to cover as far as you can comfortably see today. Then define and plan subsequent projects to cover the remaining work as more details are known.  For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables. 

Uncover the Details as the Project Progresses

If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. In this third approach, you plan the short-term work in more detail, and leave the longer term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

This last approach uses an Agile philosophy. Agile projects are generally exploratory. The details of the project are uncovered as the project progresses. (There are many more differences in Agile projects, but this philosophy is one.) In a traditional project management model this would also be known as ‘progressive elaboration’ – which also means more details are uncovered as the project progresses.  

project tool

Four Responsibilities of Executives on Projects

A Primer on Processes and Templates

Recipes for cooking are a beautiful thing. A recipe tells you the ingredients and how much of each you should include in whatever you are making. It then describes what you need to do to these ingredients in order to make a dish that is not only edible, but tasty as well. It’s great that someone else has already spent the time in putting together a recipe to follow that nearly guarantees success each time.
To a certain extent we use recipes in our profession as project managers. The recipes we follow are the processes and templates that guide our projects to success each time. How can you put a process together and make the most of templates? Consider the following:
A Primer on Processes and Templates

Start with Phases

To put a process together, a good starting place is defining the major phases in which a project must go through. Think about how a project moves through your organization, and document those major steps. For example, a simplified software development approach would include the following phases: Planning, Design, Development, Testing, and Implementation. These phases are the framework in which you begin filling in details about the process.

Move on to the Outputs
The next area to concentrate on is the outputs, or end results, from each of these major phases. Ask yourself what tangible deliverable needs to be complete by the time you finish the Planning, Design, or Development phases. Focus on tangible results, or something you can see, touch, perform an action on, or feel. For example, the Planning stage is going to be filled with meetings and conversations that by themselves do nothing to move the project forward. However, the approved Business Requirements Document is an invaluable output that can propel the project forward to the next Phase of Design.

Back up to Inputs

Now that you have the tangible end results (or deliverables) of each phase defined, ask yourself what needs to be present at the beginning of each phase to create such results. Continuing with our example above, the output of the Development phase would be software functionality that can be tested. In order to accomplish this, the engineering team will need High Level and Low Level design specifications as Input. This will allow them to know not just what they are going to build, but more importantly, how they are going to build it.

Establish Conversion Activity

You now have the Inputs and the Outputs for each of the phases of your process. The final step is to determine what needs to be done to convert the Inputs to Outputs. Think about it this way…what has to be done to change the gooey mess of runny batter into a cake? You need to bake the cake. There’s your conversion activity. Likewise, what do you need to do to convert software that is ready to be tested to software that is production ready? You need to create test plans, execute test plans, and document the results.

What About Templates?

Templates are incredibly useful for all areas of process you create. You can use templates for your inputs (i.e. Business Requirements Document), your Outputs (i.e. an approved User Acceptance document from the customer) and all points in between. Create templates that will provide consistency and make it easy to transition from one phase to the next with confidence.

One word of caution when it comes to process and templates…don’t overdo it! Create just enough process and documentation around your project to float the boat. It can be tempting to have a process or template in place for every little thing. Resist that urge. Remember, too much of a good thing can ruin a good thing. Stick to the recipe and you’ll be able to guarantee consistent results time and time again!