Techniques to Manage Projects With Predetermined End-dates (Timeboxing)

In a perfect world, your project schedule and completion dates would be derived based on the amount of work to be done and the number of resources available. As you know, that is not always the case. Sometimes there is an end date by which the work must be completed. For instance, the end-date may be determined by a government regulation, a scheduled event or to coincide with another company initiative. This situation is referred to as a timebox, meaning you have a fixed amount of time to get the work done and the end-date is “boxed” in.

There is nothing wrong with having a fixed end-date. It can give everyone on the team a sense of urgency and focus. There may be a problem, however, if the project manager and team do not think they can get the work done by the deadline. In that case, the project manager needs to raise this as a risk. Potential risk plan actions include:

  • Assigning more resources to the project. Too many resources may have diminished value but this is usually the first place to start.

  • Having the team work overtime, with the understanding that overtime itself has a diminishing return, and that long-term overtime can actually have a negative effect.

  • Working with the stakeholders to scale back the required deliverables due by the deadline. This may include removing entire deliverables or functionality from required deliverables.

  • Determining whether some required deliverables and features can actually be delivered later than the due date. In these cases, a 90% solution may be viable at the due date, with the additional work completed soon after.

Important –  Estimate the Amount of Schedule Risk

Even if your manager or sponsor has given you a fixed end-date, it is important to carefully build the schedule first as if you did not have the fixed end-date. If you do this first, it will give you a sense for how realistic it is to hit the fixed date. For example, let’s say you have a project that has to be completed in nine months. If you first create a “normal” schedule that shows the project will be complete in 9 ½ months, it would not be too much of a stretch to think you could complete the work in nine months. However, if you create a “normal” schedule and it shows the end date at 13 months, you will understand the difficulty and the risk associated with trying to get all of the work completed in the nine-month timebox. This does not mean that you will not have the nine month deadline. However, it gives you more information to have a fact-based discussion on the project risks and options that are available to you.  


Identify and Address Poor Team Member Performance

Project managers encounter team member performance problems all the time. In many cases you don’t feel like you have the authority to address these situations. However, usually you do have some options. You can at least better understand the nature of the performance problem. Depending on the severity of the problem you might also be able to address it.

Step 1. The first step is to collect facts that help you understand the nature of the performance problem. You should write down instances where the performance did not meet your expectations. You will need these examples to start a performance discussion. They should not be hard to gather. You would not be trying to resolve a performance problem if there were not specific instances to you can document.

Step 2. Once the factual examples are ready, the second step is to have a preliminary performance discussion. This discussion will make the employee aware of the perceived performance problem. You will also get the employee’s feedback and response.

In many cases, the manager jumps to the conclusion that there is a performance problem, pure and simple.  However, there may be other reasons why the employee’s performance may not be up to expectations. For example, the performance problem may be the result of a skill gap. The problem could be caused by competing non-project work. The problem could be caused by a personality conflict. You need some insight into the nature of the problem before you can move head to resolution.

Step 3. Once the projects manager and team member discuss the situation, he will be able to create the right action plan. Perhaps just bringing the performance perception to the team member’s attention will help to resolve the situation. The short-term plan may require work from both the manager and employee. The plan should also include a time to get back together again for a progress report. It is important to get back together to determine whether there has been any improvement in performance.  If there has been, then perhaps the situation just needs to be monitored from that point. 

As a project manager you have some ability to provide performance feedback when work is not up to your expectations. However, you do not have total control. If your preliminary three-step approach does not work, or if the team member is resistance to working with you, you will need to get the person’s functional manager involved and address the situation through a more formal performance management processes.

Ways to Ensure You Collect the Right Metrics

Most companies want to collect more data to be used for fact-based decision making. However, companies struggle actually implementing a strong metrics program. There is a reason – it is really hard! However, there are things you can do to ensure you collect good metrics without going overboard.

1. Make Sure Your Metrics Add Value

Identifying, gathering and leveraging the right mix of metrics are ways to add value to an organization or a project. The value can be quantified in a number of areas including:

  • Improved performance of the overall project fulfillment and delivery process

  • Improved estimating for future projects
  • Validation of duration, cost, effort and quality objectives for the project
  • Identification and communication of best practices

Metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information, all discussions on performance and improvement are based on anecdotal evidence, perceptions and guesses.

2. Use the Metrics that You Collect

You don’t want to collect metrics just for the sake of collecting them. That doesn’t make sense and it just ends up being a waste of time. If certain metrics are required by your organization, collect them. In addition, you should collect any other metrics that are needed by your particular project. However, if you don’t have a purpose for the metrics, or if your project is not long enough that you can really leverage the information, these customized project-specific metrics are not worth collecting for your project.

3. Compare the Cost of Collecting a Metric vs. the Benefit

Just as there is some cost associated with most project management activities, there is a cost to collecting and managing a metrics process. In many cases, the cost to collect and leverage a certain type of metric is prohibitive. These metrics should not be pursued. Other metrics are interesting, but do not provide the type of information that can be leveraged for improvement. The bottom line is that the cost to gather each metric must be balanced against the potential benefit that will be gained. Start by gathering metrics that are required by the organization. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit.

Steps to Deploy Project Management Practices

Project management methodology is a framework that allows project managers to successfully manage projects of varying sizes. Many organizations do not follow a formal, consistent methodology of any kind. How do you start with an initiative to introduce project management practices within an organization?

From a project management perspective you would probably start the project by identifying stakeholders and formally planning the initiative. But let’s assume that work is done. Where do we start in the actual work associated with this type of culture change?

Step 1. Current State Assessment

When you are planning to change organization behavior it is usually good to understand the current state. This gives you the perspective and baseline to understand what needs to change. The Current State Assessment looks at project management practices, enablers, barriers, roles and responsibilities, tools, skill levels, portfolio processes, etc.  You can uncover the nature of the current state through a formal assessment. The assessment could involve talking to many people in the organization and reviewing evidence from current projects. The assessment could also be as simple as a workshop discussion with a cross-section of staff members that can form a consensus of the current state.

Step 2. Define the More Desired Future State

While you are looking at the current environment, you also need to ask what the future vision would look like. This is usually not so difficult in may areas. For instance, if the current state shows that project managers have weak skills, the future state will probably be that all project managers have a basic skill level, and perhaps a certification. Seeing the weaknesses of the current state will help paint a picture for the more desirable future state.  

Step 3. Define the Gap Between the Current and the Future State

Many change initiatives start off by trying to define what the future vision looks like. However, describing the future state of project management in your organization is not the major deliverable at this point. The ultimate deliverable is a Gap Analysis that shows what you need to focus on to move the organization from where it is today to where you want it to be in the future. This is important because you do not want to spend your time implementing in areas where your organization already does well. At the same time, you don’t want to implement a number of changes and still see your effort fail because you did not address other important areas as well.

Next Steps

Once you have the Gap Analysis, everything else flows from there. You can describe the work required to close the gaps, the resources needed, the priorities and timeframes, etc. You can also define the organizational change management components that are required to move to the organization to your future state. You now at a point where you can move forward with the deployment project.

Deploying Project Management in Waves

There are a number of ways to deploy common project management practices within an organization. One approach is to think of everything that needs to be improved and try to deploy everything at once. Instead, our approach is to deploy items more gradually to provide some time to absorb initial changes before others are rolled out.

Like waves rolling toward the beach, you select certain aspects of the new project management practices, and then pause before rolling out the next wave. In many cases, one wave builds on a prior wave. After a period of time, you will have introduced many new skills and new processes, but the staff will not have viewed it as traumatically as if everything came crashing down on them at once. A sample scenario of waves is as follows:

Wave 1:

  • Conduct general awareness sessions to explain what is coming and why.

  • Introduce basic standard project management processes and templates.
  • Perform a “role sort” to create common roles and responsibilities for projects.
  • Provide basic project management training.
  • Roll out coaching services to help project managers utilize the training and templates effectively.

Wave 2:

  • Implement a document repository to hold the common processes, templates, best practices, standards, etc.
  • Reinforce management governance processes to ensure that the management team is implementing the new initiative within their organizations.
  • Introduce project and organization assessments.

Wave 3:

  • Build a PMO to handle the project management practices long-term.
  • Teach  project management classes focused on more sophisticated processes such as quality management, metrics management, risk management, etc.
  • Support the new training concepts with more sophisticated processes and templates.

The three waves above are for illustration purposes only. Each organization needs to determine the items to deploy, the waves and the timing.


Deploying project management processes and building project management capability in the organization requires much more than simply training the staff and then walking away. There is a process that must be followed to understand the work required to move the organization to your future vision. Once the work is understood, it should be divided into manageable waves to have a better chance of success. 

Ensure Project Staff is Available as Needed

Managing staff can be a challenge. In large organizations, or on large projects, you may have the luxury of full-time resources for your entire team. However, in many (or most) situations, the project manager must utilize shared and part-time resources to complete the work. In a matrix organization, people are assigned full time to a functional organization, but can be temporarily assigned full time or part time to a project as well. In this case, the functional manager may be responsible for part of a team member’s workload and a project manager is responsible for assigning the work associated with the project. 

Project managers in a matrix organization often feel they have responsibility for delivering results but little authority over the staff. As a project manager you need to maintain a planning window of your resource needs. This includes a very detailed understanding of resource needs over the next three months. This is also referred to as rolling wave planning. You then update and refine the staffing needs on a monthly basis. The closest month should be pretty firm. Two months out should be pretty close. Three months out and beyond is best guess.

On the other hand, if the project staffing needs are well understood, you may want to maintain a six to nine month resource window and update the plan every quarter.

Planning for your staffing needs is very important. However, proactive communication is even more important. Remember that in a matrix organization, project managers need resources to do their work, but they do not own them – the functional managers do. So, the onus is usually on the project managers to make sure that the resources are available when they are needed, and that there are no surprises. For instance, if you and the functional manager agree that a specific set of people will be available for one of your projects in two months, don’t just show up in two months and expect them to be ready to go. In fact, you should expect that they will not be ready if you have not communicated often and proactively. The project manager should gain agreement on resources two months in advance. The resources should be confirmed again at the next monthly staff allocation meeting. The project manager should double-check resources again two weeks before the start-date, and follow-up with a reminder one week out.

You are much more likely to have the resources available when you need them if you take these proactive steps.

Turn Around Marginal Performers

One problem that many project managers never get comfortable with is dealing with poor performers. Some people are such poor performers that they ultimately fire themselves. Maybe the bigger challenge is trying to improve marginal performers. These are people that constantly disappoint. The miss a high performance bar, but when you lower the bar they miss that as well. In spite of these marginal performers, you still have to complete your project successfully. You should look at a number of possible causes for marginal performance.

  • Does the person have the right skills and experience? Sometimes people do not deliver up to expectations because they do not have the right skills to do the job. For instance, you assign a person to complete the analysis for a new set of reports, but he is not sure how to ask the right questions or frame a discussion with the clients. If anyone falls into this category, you need to decide whether he could do the work with the right training or whether he should be replaced.

  • Do they understand your expectations? If people have the right skills, ask whether they really understand what the expectations are. For instance, sometimes when a team member misses a deadline, he might come back and say that he did not think the work was due at that time. If there is some confusion on the expectations, you can have the person confirm back to you in writing his understanding of the expectations for deliverables and dates.

  • Are they motivated? Some people are not motivated to do a good job regardless of the assignments and skills needed. You can take one shot at trying to motivate the person. but after that you would need to being this to the attention of the person’s functional manager. 

  • Can you assign them other work? Perhaps the person could do better – perhaps excel – if they were assigned different type of work. Look through your schedule to see if you have flexibility to assign work that is valuable to you and that they can do well.  

  • Are there extenuating circumstances? Another area to consider is whether there are any business or personal factors that could explain a person’s performance. For instance, a member of your team may not be very motivated to work if his spouse is very ill. If you can find a cause, it will give you some ability to respond or at least acknowledge the cause.

If people have the right skills and the right expectations, then the project manager’s options become more limited, and you start to enter the realm of the performance management. It is possible that some team members are not going to do be able to perform up to expectations. They may not be willing to do the job, or they may not be able to do the work regardless of the training and support you provide. If you feel you are at this point, you need to get the appropriate functional manager involved. 

It is difficult and frustrating to work with and rely upon people who do not come through. After you look at the problems and try to determine the cause, you may just decide if there are things that you can do as a project manager or if there is a performance problem that needs to be brought to the attention of the functional manager.  

Elements to Define a PMO

Before you can start up a PMO, you must first define the purpose and what the PMO will look like. Without this foundation, all of the other work you do will be in jeopardy. This helps gain clarity and agreement on what you are doing and why. You can think of this as chartering the PMO. This information is communicated to clients, stakeholders and your own staff so that everyone starts off with a common set of expectations.

The following major components are used to define your PMO.

  • Mission. Describes what the PMO does, how it is done, and for whom. It is a very general statement, usually aligning the PMO to the value it provides to the business. An example of a PMO mission statement is “The Acme Project Management Office (PMO) supports project managers to enable them to deliver projects faster, cheaper, and with higher quality.”

  • Sponsor. All organizations do not have a sponsor, but a PMO typically does. The sponsor is the person responsible for the PMO funding, and in many cases the sponsor is the manager that the PMO reports to. Sponsors are important for all initiatives, but they are absolutely critical for a culture change initiative such as this.

  • Customers. Customers are the main individuals or groups that receive the benefits of the products and services your PMO provides. While there may be many stakeholders (below), it is important to recognize who the customers are. They should be the ones the PMO focuses on – to help them meet their project and business objectives.

  • Stakeholders. These are the specific people or groups who have an interest or a partial stake in the products and services your PMO provides. Internal stakeholders could include organizations you work with, but who are not directly under the PMO umbrella.

  • Objectives. Objectives are concrete statements describing what the PMO is trying to achieve in the short-term, perhaps up to one year. The objectives should be written at a low level, so that they can be evaluated at the end of the year to see whether they were achieved or not.  

  • Products / Services. Products describe tangible items that the PMO produces, and are typically produced as the result of a project. Services refer to work done for clients or stakeholders that does not result in the creation of tangible deliverables. Services provide value by fulfilling the needs of others through people contact and interaction. The PMO achieves its objectives through the creation of products and the delivery of services.An organization assessment is used to determine the right products and services the PMO should offer.
  • Transitional Activities. Transitional activities are the specific activities and projects that are required to implement the PMO. If the PMO is new, these activities describe the work required to build and staff the new organization. Most of this work is designed to build the products and services described previously with input from the organization assessment. 

There are other aspects of the organization that can be defined as well, including the PMO vision, principles, goals, skills, roles and responsibilities.

Story Points Lead to Velocity and Rhythm

One of the unique aspects of an Agile project is that the workload for each iteration is determined at the beginning of each iteration. In other words, the workload is not laid out months and months in advance. There is only a need to plan for the current iteration. This allows the Agile project to be very flexible.

At the beginning of every iteration a meeting is held between the product owner and the project team to determine the workload for the new iteration. During the meeting the product owner evaluates the requirements backlog and pulls off the next set of user stories that are of the highest priority. The level of effort for each user story should have been assigned when it was added to the backlog. There should either be an actual estimate of effort hours, or more likely a number of “story points”. Story points are numbers used to estimate the relative size of a user story.

During the planning meeting, the project team takes on as many story points as they can complete within the iteration. The most important remaining user stories are assigned to the team. In this way, the product owner is always assured that their most important needs will end up in the final solution.

It is important that the project team determine quickly how much work they can complete in each iteration. This will allow the workload to stay relatively even from iteration to iteration. If the project team finds that it was not able to complete a set of user stories in the prior iteration, the team can agree to take on less work in the next iteration. Likewise if the team realizes that they could have done more work in a iteration, they should take on more work in the next iteration. This pace at which the team can complete story points from the backlog is also known as the team “velocity”.

User stories that are selected for a iteration need to be completed in that iteration. In a traditional project, you might delay a milestone or implementation if all of the work is not completed. However, in an Agile project it is important to stay on a steady iteration cycle If the story is not ready when the iteration is ready to move to production, the code needs to be pulled out so that the code from the iteration can be released on time. There are no delays to the iteration completion date. The team picks enough work so that it can all be completed in the iteration. The team then focuses on hitting that end-date over and over and over again. This steady pace for each iteration is also known as the team “rhythm”.

Story, points, velocity and rhythm. These terms are unique to the Agile model. Now you know what they mean and their importance to a healthy Agile project.

Use Expected Monetary Value (EMV) to Determine Risk Impact

Expected monetary value (EMV) is a risk management technique to help quantify and compare risks in many aspects of the project. EMV is a quantitative risk analysis technique since it relies on specific numbers and quantities to perform the calculations, rather than high-level approximations like high, medium and low.

EMV relies on two basic numbers.

P – the probability that the risk will occur

I – the impact to project if the risk occurs. This can be broken down further into “Ic” for the cost impact, “Is” for the schedule impact and “Ie” for the effort impact.

The risk contingency is calculated by multiplying the probability by the impact.

Risk Contingency Budget

If you use this technique for all of your risks, you can ask for a risk contingency budget to cover the impact to your project if one or more of the risks occur. For example, let’s say that you have identified six risks to your project, as follows.


P (Risk Probability)

I (Cost Impact)

Risk Contingency

P * Ic





























Based on the identification of these six risks, the potential impact to your project is $118,000. However, you cannot ask for that level of risk contingency budget. The only reason you would need that much money is if every risk occurred. Remember that the objective of risk management is to minimize the impact of risks to your project. Therefore, you would expect that you will be able to successfully manage most, if not all of these risks. The risk contingency budget should reflect the potential impact of the risk as well as the likelihood that the risk will occur. This is reflected in the last column.

Notice the total contingency request for this project is $33,500, which could be added to your budget as risk contingency. If risk C and F actually occurred, you would be able to tap the contingency budget for relief. However, you see that if risk D actually occurred, the risk contingency budget still might not be enough to protect you from the impact. However, Risk D only has a 10% chance of occurring, so the project team must really focus on this risk to make sure that it is managed successfully. Even if it cannot be totally managed, hopefully its impact on the project will be lessoned through proactive risk management.

Spreading the Risk

The risk contingency budget works well when there are a number of risks involved. The more risks the team identifies, the more the overall budget risk is spread out between the risks. In the case above, the fact that there are six risks helps pool enough risk contingency to accumulate a protective budget. If you have only identified one or two risks, you may not be able to spread the risk out enough to be as effective as you like.

Budgeting for Unknown Risks

The EMV calculations above only reflect the risks that are known at the beginning of the project when the initial risk assessment is performed. If you are managing a large project, you need to continue to monitor risks on an ongoing basis. Therefore, you can also ask for additional risk contingency budget to cover risk that will probably surface later that you do not know about now. For example, you could request an additional 5% of your total budget for risk contingency to cover the unknown risks that you will encounter later. This is in addition to the risk contingency of the known risks that have already been identified.