Schedule Estimating Threshold

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.

Managing projects at your company? Download free tools and templates from Toolkit Cafe and make your job easier

Assumptions and Risks – Two Sides of a Coin

Assumptions and Risks – Two Sides of a Coin

Let’s take an example of a common statement that is included in many Project Definitions – that the resources needed for this project will be available when needed. What kind of a statement is this? Most people would say it is an assumption. After all, when a project starts, you always assume you will get the resources you need.

However, is it really an assumption? Can you imagine starting a project where the people and equipment were not available and there was a realistic possibility that they would not be ready when you need them – perhaps because another project needed to finish first? It is not too difficult to imagine that scenario. In that case, the same statement would definitely be a risk – not an assumption.

The same statement might be an assumption or a risk depending on the circumstances of your particular project. There is some degree of uncertainty to an assumption. If the event is negative and there is a low probability that it will happen, it can be stated as an assumption. If the event is positive and there is a high likelihood it will happen, it is also an assumption. One way to identify important assumptions is to perform a risk assessment and look at all the low-risk items. Most of these low risks are not worth mentioning, but some will have significant implications if events do not turn out as you think. These are the ones that you can document as assumptions.

There are two key characteristics of risks and assumptions. First, there must be some uncertainty to the event. If there is 100% chance of an event occurring, it is simply a fact. If there is a 0% chance of the event occurring, it is fiction. Neither are risks or assumptions.

Second, assumptions and risks are both outside the total control of the project team. If the event is within the control of the project team it is neither an assumption nor a risk. It should simply be managed to make it happen.

Review the following examples for more clarity on assumptions and risks.

Statement

Assumption, Risk or Other?

We will have strong support for this initiative from our executive sponsor. Can’t tell if it a risk or an assumption. Depending on the project, there could be a high degree of risk in this statement (risk) or very little (assumption).
We will complete requirements before we begin design work. This is part of the project approach. It is not a risk or assumption because it is within the control of the project team.
Our vendor will complete their installation by October 1 Can’t tell if it a risk or an assumption. Depending on the project, there could be a high degree of risk in this statement (risk) or very little (assumption).
We must go to the moon to get the supply of meteor fragments that this project requires. This is not a risk or assumption because there is no risk involved. It is a fiction (0% true).
It is 60 miles from one project team location to the other. This is not a risk or assumption because there is no risk involved. It is a fact (100% true). (If it were not true it would be a fiction (0% true), but it would still not be an assumption or risk statement.) 

Manage the Schedule for Small Projects

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.

  1. Review the schedule on a weekly basis.
  2. Identify activities that have been completed during the previous week and update the schedule to show they are finished.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Seven Steps for a Project Quality Review

Seven Steps for a Project Quality Review

In some cases, such as a government project, periodic audits may be called for as a part of the overall contract. This “outside party” could be any qualified person outside of the project manager. In some cases, your organization may have an internal project audit specialist. It is possible that the Project Director or the Project Sponsor could also perform this audit. The outside party could be an outside contractor or consultant, but they do not need to be.

The audit itself focuses on whether effective project management processes are being utilized and whether the project appears to be on-track. A project audit asks questions about the processes used to manage the project and build deliverables. The audit can follow this process:

  1. Notify the parties (Auditor) – The auditor notifies the project manager of the upcoming audit and schedules a convenient time and place. Other key stakeholders are notified of the audit as well.
  2. Prepare for the audit (Auditor) – The auditor may request certain information up-front. The auditor might also ask the project manager to be prepared to discuss certain aspects of the project. This ensures that the actual meeting time is as productive as possible.
  3. Perform initial interview (Auditor, Project Manager) – During the initial meeting, the auditor asks the appropriate questions to ensure the project is on-track. If there are any areas that are not on track, the auditor notes them as such.
  4. Perform as many other interviews as necessary (optional)(Auditor, Project Team) – On many projects, the audit might culminate in the initial meeting. If the project is large or complex, the auditor might need to perform follow-up analysis. This includes meeting with other team members and clients, and reviewing further documentation.
  5. Document the findings (Auditor) – The auditor documents the status and the processes used on this project against best practices. If the organization has standards and policies in place for managing projects, the auditor determines whether any of these are not being followed on the audited project. The auditor also makes recommendations on things that can be done to provide more effective and proactive management of the project.
  6. Review draft audit report (Auditor, Project Manager) – The auditor and the project manager meet again to go over the initial findings. This auditor describes any project management deficiencies and recommendations for changes. This review also provides an opportunity for the project manager to provide a rebuttal when necessary. The initial audit findings might be modified based on specific feedback from the project manager.
  7. Issue final report (Auditor) – The auditor issues a final report of findings and recommendations. The project manager may also issue a formal response to the audit. In the formal response, the project manager can accept points and discuss plans to implement them. The project manager may also voice his disagreement with certain audit points, and explain his reason why. In these cases, the project sponsor and the project director (manager of the project manager) will need to decide if the project manager should comply with the recommendations or not.

Manage Communication – Large Projects (Part 1 of 2)

Manage Communication – Large Projects (Part 1 of 2)

In a large project, all communication takes place in context of an overall Communication Management Plan. Status meetings and status reporting are required, just as for a medium-size project. In addition, there are many other types of proactive communication that need to be considered. This creative and proactive communication is laid out in a Communication Management Plan, which is created as follows.

Beginning of Project – Plan Communication

  1. Determine the project stakeholders. In some cases these are stakeholder groups such as a project steering committee. In other cases, there may be a single person such as the sponsor.
  2. Determine the communication needs for each stakeholder. The project manager can categorize the communication needs into three areas.
  • Mandatory. This generally includes project Status Reports, legal requirements, financial reporting, etc. This information is pushed out to the recipients.
  • Informational. This is information people want to know or that need for their jobs. This information is usually made available for people to read, but requires them to take the initiative, or pull the communication.
  • Marketing. This communication is designed to build buy-in and enthusiasm for the project and its deliverables. This type of information is pushed out to the appropriate people. You need this type of positive communication if your project requires people to change how they do their job.
  1. For each stakeholder, brainstorm how to fulfill the communication need. For each stakeholder, determine the information they need to know, how often they need an update, and the best manner to deliver the information. At this point, be creative. For instance, all stakeholders still need an updated project status. The Steering Committee may need an executive briefing to provide strategic direction every other month. The project sponsor may need a personal briefing on a monthly basis. A quarterly newsletter may need to go out to the entire client organization for informational and marketing purposes. 
  2. Determine the effort required. Estimate the effort required to create and distribute each of the identified communication options outlined in step 3. Also determine the potential benefit of the communication to the recipient and the project team.
  3. Implement mandatory communications. Regardless of the prioritization, implement any communication options that are mandatory for the project. This will definitely include project Status Reports, but there may also be government-required reports, legal reports, etc.
  4. Prioritize the other communication options. Discard the communication options that require high effort for marginal benefit. Also discard those that provide marginal benefit even though they may take little effort from the project team. Implement the communication options that provide high value and require low effort from the project team. Also evaluate those options that have high value and require a high level of effort from the project team. Some of these might make sense to implement while others may not.
  5. Add the resulting communication activities to the schedule. This will include assigning frequencies, due dates, effort hours and a responsible person(s) for each communication option implemented.

Escalate a Performance Problem with a Formal Plan

Escalate a Performance Problem with a Formal Plan

One of the hardest jobs of a manager is to take an employee down a path that may ultimately result in termination.  It is hard enough for most managers to provide performance feedback to begin with – even when the employee performance is good.  When the employee performance is not where it needs to be, it is even harder. 

The first thing you need to do when you see a performance problem is sit down with the employee, discuss the performance observations, try to determine a cause and put a short-term action plan in place so that the employee has a chance to turn the situation around. 

Unfortunately, sometimes the initial performance feedback and short-term plan do not have the desired effect.  If this occurs, the manager needs to take additional actions.  In some companies and in some positions, the next step might be a demotion or termination.  This might also be the case at smaller companies where the management team needs to make personnel decisions quickly, and where the company is not under as many obligations from a Human Resources standpoint. 

In larger companies, however, managers normally don’t have the authority to fire employees on their own.  The Human Resources Department normally has processes in place to make sure that people are treated fairly and within allowable legal guidelines.  If a manager tried to resolve a situation on his or her own but was unsuccessful, it is time to bring a formal Human Resources process into play.

Managers sometimes hesitate to take personnel-related actions because of their concern for how the rest of the team will react.  If the employee is a popular one, there is a tendency to believe that the team will react negatively.  In fact, that might be the case if the manager acts arbitrarily.  However, if the manager gives an employee plenty of time to improve his or her performance but the problem does not go away, termination may still be necessary.  In this situation, the manager should be able to explain to the rest of the team how every effort was made in the employee’s favor.  The rest of the team should understand first-hand that the employee’s performance was weak.  Also, they should understand that replacing that employee is in the best interest of the team, the entire organization and perhaps in the employee’s best interest as well.   

A team knows its weak links.  In many situations, the rest of the team ends up working harder to compensate for the person with the weak performance.  In the best cases, the team does so willingly (and perhaps subconsciously), but their actions mean that they cannot be effective.  In the worst case, teammates start to turn against the poor performer, causing resentment, animosity and friction among team members. 

Sometimes a perceived performance problem hits the team member totally by surprise.  However, in most cases, they already understand the situation.  Poor performers should see that they are missing deadlines or that “completed” work requires a lot of rework.  Once they get on a short-term improvement plan, they become keenly aware of whether or not their performance is meeting expectations.  If they still cannot meet expectations, it will become increasingly obvious to them.  This situation will cause them more anxiety, which can drive performance down even lower.  The situation should be resolved as soon as possible for the sake of the employee as well as the organization. 

Remember that putting a formal performance plan in place is not the same as termination.  The performance plan is really a way to save the person from possible termination.  A good performance plan puts everything into black and white, and it should precisely set expectations.  The performance plan should include the length of the plan, the expectations and how the progress will be communicated.                

     

Once the performance plan is signed, it is activated.  The employee should strive to meet the expectations of the performance plan.  The manager must provide ongoing feedback on the employee’s performance and whether the employee is meeting expectations.  This entire process is set up to manage expectations.  If the employee is not meeting expectations, the manager must continue to say so in the ongoing written feedback.  This ensures there are no surprises. 

Managing Staff

Managing Staff

Topic 1. Overcome Team Resistance to Project Management

It’s one thing to build a Project Charter and the schedule. It’s another thing to effectively manage the project. If you could issue the plan and the work assignments and have everyone complete his activities on time, your life would be much easier. However, the process of managing the team and the schedule becomes complicated because of the people element involved. People are unpredictable. To understand how the project is proceeding and to ensure that it stays on track, controls are needed. You may need to go around and ask people how they are doing. You need people to tell you in Status Reports and status meeting how they are doing. You need to keep updated statistics on work completed, in-progress and not started.

Unfortunately, team members do not always respond well to these management and control processes for a number of reasons. 

  • They may think the processes are cumbersome and keep them from completing their deliverables.
  • They may feel they will be punished for bringing bad news or doing things incorrectly.
  • They may not feel the project management processes are effective.
  • They may have a normal human tendency against processes that feel like controls.
  • Team members may have tried to follow the processes, but found they were not complete or they were not supported by other people.
  • They may feel that the project manager is not following the procedures, so why should they.
  • They may see people going around the processes without consequences.

Knowing and recognizing these normal human tendencies will help counter the resistance you may encounter on your project. The project manager needs to communicate the processes effectively, including their overall value to the project. Once discussed with the team, it is important to apply the project management processes consistently so that they can be adopted successfully on the project. 

Topic 2. Address Staff Performance Problems with an Early First Meeting

It can be difficult for a project manager to deal with team members with performance problems. You should first determine whether the behavior is impacting the project in terms of its deliverables or its deadlines. If so, the situation needs to be addressed for sure. The next question is whether the behavior may cause problems in the future.  If so, then you could consider this a project risk. There are a number of potential risks including:

  • A risk that the behavior will, in fact, lead to missed deadline dates in the future.
  • A risk that the behavior will alienate the rest of the team and that overall cohesion and morale will suffer.  This may cause the team’s performance to suffer as a result.

If the manager perceives the employee may become a significant risk, he should address this situation proactively. The place to start with personnel problems is usually to take the most direct route – a face-to-face discussion.  In this discussion, the manager can discuss his perceptions of the employee’s behavior and why it will (or may) cause problems on the project.  The manager understands the risks to the project and should communicate these risks to the employee.

One of the benefits of the first meeting is that the manager can share the concerns, and the employee will have a chance to tell his or her side of the story.  You never know how these first discussions will progress.  Sometimes they are difficult and don’t accomplish what you hope. However, sometimes the person you are talking to will agree with you and tell you the reason for his or her behavior.  As a manager, if you know the causes, you might have some ability to help fix them.

The employee may have a problem in his or her personal life (which may or may not be shared).  There might be personality problems between the employee and other members of the team. If you can get some sense as to the cause of a problem, you have a chance of determining a remedy.

In fact, there may be a number of remedies that the manager and employee can work on together. This includes trying to build up the employee’s communication and people interaction skills, providing continued people-coaching, or changing the employee’s job in a way that will allow him or her to excel.  The exact solution will depend on the give and take that comes out of this meeting.

The meeting should end with some concrete commitments for addressing the problem.  The project manager needs to feel comfortable that the employee will again start to engage constructively with the rest of the team. If they cannot agree on these points, the meeting will not have been totally successful and a further escalation may be necessary. 

Manage Quality and Metrics – Techniques

Manage Quality and Metrics – Techniques

Gather Subjective Metrics with Client Satisfaction Surveys

Gathering metrics is important because it allows you to see how you are performing against the expectations of your clients. If the world were perfect, all of the metrics you collect would be factual, relevant and accurate. However, in many cases it is impractical or cost-prohibitive to try to gather exact and quantitative numbers.

 

One way to supplement quantifiable metrics is with client satisfaction surveys. For instance, instead of trying to measure the exact response time of an application against some service-level standard, you could simply ask your main users how satisfied they were with the application response time. It should make sense that if you are rated a 4.5 out of 5.0 (5 being the highest), you are probably doing a pretty good job in this area. However, if your survey results come back as a 1.8 out of 5.0 (5 being the highest) then it should be obvious that you are missing the mark. You did not need a complicated system, metric to tell you that. A simple customer satisfaction survey questions gets quickly to the same result.

 

In the same way, let’s say you want to gather metrics that indicate the time it takes to resolve client problems. This could involve tracking when the initial request comes in, when you first responded to the client and when the request was resolved. On the other hand, you could simply send out surveys that ask your clients if they were satisfied with the time it took to resolve the problem.

 

Surveys are by their nature qualitative; that is, they reflect the opinion of the person being surveyed. Therefore, you would not necessarily want to base your entire project success criteria on survey metrics. Some results are more easily obtained quantitatively. For instance, there is usually no reason to send out a survey to the finance department to ask them if your spending is within budget. You should have the facts available to you. However, for many other types of metrics, a qualitative survey question can be used as a substitute for the quantitative metric.

 

Collecting Project Metrics and Demographics Can Assist on Future Projects

Gathering and reporting a consistent set of metrics at the end of a project can help your organization see the trends for delivering projects over a period of time. The metrics should show how well project teams are meeting their commitments in terms of quality, cost and duration. As more and more projects report the metrics, a baseline will be established that will allow your organization to see how it is improving, or slipping, over time.

 

If you collect metrics on an organization-wide basis, you should collect some project demographics in addition to the actual metrics. Project demographics are just predefined project characteristics that provide a description on each particular project. If you store the demographics and metrics in a file or database, they can be analyzed to show the overall trends in a more discreet and granular way.

 

If you do not collect demographics, you can still compare actual cost to deliver versus the estimated cost. The advantage of gathering some project demographics is that you can compare similar projects. For instance, you can compare the cost and effort associated with delivering mainframe development projects versus web development projects. Or you could compare how well projects from the Sales organization meet their deadlines and budgets versus projects from the Finance area.

 

The other benefit of gathering project demographics is that you can use the information as input into future project estimates. For instance, let’s say you have marketing campaigns for different products. Let’s also say that you have been collecting project estimations and the actual results for cost and duration. If you had this information, you could estimate the cost and duration of a current product marketing campaign by comparing your project with similar projects that were completed in the past. This may be of help for estimating your project. The demographics you capture from completed projects can be used to search on later for new projects. (A sample worksheet to capture project demographics and metrics is available in the Template Library.)

 

Make Sure Your Metrics Tell a Complete Story

In many instances the project team publishes the results of a metric in a way that does not allow the reader to fully understand whether the results are good or bad. This is because the reader sees a metric, but they do not understand the target and they do not always understand what the metric is trying to achieve. The project manager and project team may know what a given metric is telling them, but other readers of the information may not. One way to help is to always report the metric along with the target. For instance, if you report your current expenditures to date, also include your expected expenditures at this point in the project. If you report that your project has spent $100,000 so far and your total budget is $150,000, the reader still does not have the context to know whether this is a good or bad situation. Sure you are under budget, but the work is not complete either. The better way to report this information is to state that you have spent $100,000 to date and that according to your estimate you should have spent $110,000 at this point in the project. If the trend continued, you estimate the final cost of the project to be $135,000 versus your budget of $150,000. If you report the metrics with this context, your readers can understand what the numbers are saying.

Provide Leadership to Implement Critical Change Requests

Provide Leadership to Implement Critical Change Requests

Scope change is not inherently bad or good. However, the team can react to changes in positive and negative ways, depending on the state of the project. A typical reaction from most project teams is to just go ahead and make the approved changes. However, there is another reaction that can be more problematic – the team may not want to make any more changes. This is the scenario for this column. This situation could occur for a variety of reasons.

  • This may be a long project, perhaps requiring overtime, and people just want the project to end.
  • The proposed changes will require a lot of work, and the deadline date is being held firm. Again, overtime may be required from the team.
  • Members of the project team and the client have not had a smooth relationship on the project. There may be project team members that do not want to help the client further.
  • The changes require major upstream rework – including changes to requirements, design, and other phases that have already been completed.

All of these situations (and more) result in a scenario where the project team is not motivated to support scope changes. This puts the project manager in a tough position where he has to get the rest of the team on board for one last charge.

Frankly, it’s a tough sell. The team is usually tired and they are not motivated. In fact, morale may be poor. However, this is the time for the project manager to show leadership. Since the cause of the team problems is probably complex, the solution should be multi-faceted as well. Here are some things for the project manager to consider.

  • Explain the facts first. Do not start with a rah-rah speech right away. First meet with the team and explain the background and circumstances. Then talk through the changes that are needed and why they are important from a business perspective.
  • Acknowledge the pain. The project manager must acknowledge the problems. Let the team members know that you understand that they may not want to make the changes. Don’t dwell on it – but acknowledge it.
  • Be motivational. Now is the time to motivate the team. Appeal to their sense of working together as a team to get through this adversity. Let them know the value they are providing to the company.
  • Talk to everyone one-on-one. In addition to the team meeting, talk to the entire team one-on-one to understand where they are at mentally. Listen to their concerns and get their personal commitment to work hard and keep going.
  • Get management and the sponsor involved. Now is also a good time to ask your manager and your sponsor to talk to the team, thank them for their work so far and ask for their continued help getting through the changes.
  • Look for perks. Little perks can help a team get through motivational and morale trouble. These can be as simple as donuts in the morning and pizza for those that have to work late overtime.
  • Make sure the clients are in there with you. Normally if the project team is working extra, the clients are sharing the pain as well. However, the project manager should make sure they are.
  • Communicate proactively. Keep everyone informed as to the state of the project and the time and effort remaining. If the project manager starts getting closed and secretive with information, it causes many more problems to morale.
  • Celebrate successes. The project manager does not need to wait until the project is over to declare success. Look for milestones, or mini-milestones, as opportunities to celebrate a victory and give praise to team members.

A project manager needs to have more management and leadership skills than simply telling people to “do their jobs.” This is a tough situation and requires good people management skills to get through successfully. Success is never guaranteed, but utilizing some of these tips can help you get through a tough situation.