Remember These Five Often Overlooked Activities to  Start a Project

Remember These Five Often Overlooked Activities to
Start a Project

Larger projects definitely need time up-front to define and plan the work. If you do not adequately plan a small or medium project, the consequences will probably not be too drastic. You don’t have that same luxury in a large project. The planning process is very important. But there are some things to consider before you even start planning. These activities would be a part of project initiation and the work is often overlooked.

When you are assigned as a project manager on a project, don’t forget the following.

Gather baseline information

Look for all the information that may already be available for this project. This includes any previous project deliverables, memos, emails, etc. In many cases, before the project begins, the sponsor must perform a cost/benefit analysis or  Business Case. All of this information should be gathered as a starting point for understanding the work.

Determine the initial approval process

Work with your manager and the project sponsor to understand the approval process for the Project Charter and any other initial project deliverables. For instance, you can determine the people that have to approve the Project Charter versus those that should just receive a final copy.

Discover high-level requirements

The project manager needs to have some understanding of the high-level requirements of the project before he can even begin to plan the work. The project manager is getting the essence of the project during initiation. You are not uncovering the detailed product requirements at this time. The detailed requirements will be further defined as a part of the project lifecycle once the project is approved. 

Identify the key stakeholders

Your manager and the sponsor should have a pretty good idea of the appropriate project stakeholders. These are people and groups with an interest in the project. You need to understand these people and their interests to be able to gather the correct information for project planning. If possible you should also meet or talk with the stakeholders at this time to start to get an understanding or their interest and attitude about the project.

Estimate the resources you need for planning

Depending on the size of the project, the planning process can be time-consuming. The project manager needs to quickly understand the resources needed for planning. This might be a part-time or full-time project manager, and it may require other resources as well.  

To summarize, when a project manager gets assigned to a new project he needs a set of initial activities to get grounded and start to understand the nature of the project. These five activities will help you gain context and prepare you for the planning process.


Project Quickstart – Another Way to Define your Project 

TenStep can quickly guide you through the project definition process. In one facilitated sessions we uncover project objectives, scope, deliverables, risks, assumptions, constraints, organization, approach, etc.  By the end of the session you will have:


  • Project Charter
  • High-level Milestone schedule
  • Project Management Procedures


Whether you are starting a crucial project, or just need general help with all projects, TenStep Consulting Services can help you get started right. Contact Tom Mochal to discuss further.


Agile 101 – Estimating Work with Story Points

Agile 101 – Estimating Work with Story Points

In each iteration, Agile project teams  implement a set of user stories pulled from the product Backlog in priority order. These stories make up the iteration backlog. The number of stories implemented in each iteration depends on the amount of effort it takes to fully implement each story, as well as the capacity of the team.

The question – how do Agile teams estimate the size of each user story? Although estimating by effort hours is very common in traditional projects, it is actually not used very often on Agile projects. A more common approach is to use a technique called “story points”. Story points are an abstract method of estimating the relative complexity of implementing a user story.

Each project team can establish their own story point scale. For example, let’s say user story A is estimated to be 5 story points (whatever this means). If the team thinks user story B will take twice as many hours to implement, the team would assign 10 story points to user story B. There is nothing magical about the use of 5 story points or 10. Another team might scale these same two user stories at 25 and 50 story points respectively. Even though the numbers are different, the key is that the story points represent relative sizing of the user stories. In both examples user story B will take twice as much effort to implement as user story A.

Once the relative size of a story point is set for an Agile team, the team can estimate how many story points they can deliver in an iteration. Again this is relative based on the scaling process used for the story points themselves. Using the above example, the team that estimated stories A and B to be 5 and 10 story points might be able to implement 45 story points in an iteration. On the other hand the team that estimated those two stories at 25 and 50 story points might be able to implement 225 story points in an iteration.

The general characteristics of story points include:

  • Story points represent the work required to fully implement a user story.
  • The stories are estimated independently by team members and then the team collaborates toward a consensus opinion.
  • If a user story is too large to be implemented in one iteration it needs to be broken down into two or more smaller stories that can fit within an iteration.
  • Many of the estimating models are designed as games that are interesting and engaging for the project team. This includes planning poker and animal points.

Over the course of a few iterations the Agile team quickly understands how many story points can be completely implemented in one iteration. This is known as the team “velocity”.


Agile projects have a number of unique techniques that are not easily transferable to traditional waterfall projects. One of these techniques is the estimation of user stories using abstract story points, and the use of story points to determine how much work can be completed in an iteration (velocity). These are simple yet very effective techniques that are the hallmark of an Agile project.


Two Essential Techniques to Manage Schedule

Two Essential Techniques to Manage Schedule

Managing the schedule  is one of the most important activities of a project manager. These are many great techniques to help manage the schedule. Here are three important ones.

Don’t manage activities by percent complete. Manage by due date.

When an activity starts it is zero percent complete. When the activity is finished it is 100% complete. In between is trickier. If a team member was 20 hours into a 40-hour activity, you could say he is 50% complete. But is he? Just because the hours are 50% used, does that mean the activity is 50% complete? Usually no.

The project manager could ask team members to report on their percent complete, but the answer is usually highly arbitrary. If a team member tells you he is 60% complete. how do you really know? How do you know he is not 58% complete or 62% complete?

A better way to get the information you need is to ask ‘When will the work be done?’ If the schedule shows an activity should be completed on Friday, and the work is not done, don’t ask the team member for the percentage complete. Instead, ask the team member ‘When will the work be done?’ Asking when the work will be completed gives you the concrete information you can place on your schedule, while also getting the team member to make another commitment to the new end-date.

Validate the work can be done in the designated time

One of the best ways to estimate work is to ask the people that will do the work. That being said, often the people that do the work were not asked for their estimate. The work was estimated by someone else. Therefore, when the project manager assigns work to a team member, it is a good practice to ask the team member to validate the estimate is correct. The team member may know immediately if the estimate is accurate, but it is also likely they may not know until they have started the work.

In general, the project manager should allow the team member to validate whether the estimate is correct. The team member is also obligated to tell the project manager if they disagree with the estimate – as soon as the team member knows. It is not acceptable to miss a due date and then claim later that the estimate was not accurate. The team member must communicate this early – as soon as they know. This allows time for options and adjustments.  

Use Expected Monetary Value (EMV)  to Create a Risk Contingency Budget

Use Expected Monetary Value (EMV)
to Create a Risk Contingency Budget

Expected monetary value (EMV) is a risk management technique to help quantify and compare risks in many aspects of the project. One use of EMV is to make risk-based financial decisions. Another use is to help you create a risk contingency budget.

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 and “Is” for the schedule 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 at its full impact level. 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 is calculated by multiplying the probability by the impact of each risk, and then summing the individual results.

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. (This same “pooling” concept is applied to insurance as well. Small individual risk probabilities are pooled across thousands of entities to absorb the impact when an individual risk does occur.)

Budgeting for Unknown Risks

The EMV calculations above only reflect the known risks. 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 risks that you will encounter later. This is in addition to the risk contingency of the known risks that have already been identified.  

Here are Six Ways to Communicate Project Status

Here are Six Ways to Communicate Project Status

Most of us still create some variation of a paper status report (free template here) to communicate progress on our project. I remember when these reports were printed on paper. An old manager of mine once asked me to review a large binder of paper status reports and tell him if there was anything interesting that he should know about. There were probably over a hundred paper reports in the binder.

Even though most organizations no longer print out status reports, the need for status updates is still here. Here are some old and new ways to report status.

  1. Status reports. Yes, what is old is also new. Many organizations still create status updates. Usually, these are reviewed online instead of printing in large binders.
  2. Email. Many organizations send the status information in-stream in an email These emails can still follow a common format so they are easy to read and digest. The information can be easier to digest if it is directly in the email instead of having to click on an attachment.
  3. Status meetings. Some organizations do not have a status report but go over the status in meetings. The Agile community does this through their daily stand-up status meetings. This can limit the status update to the people in the room, but in many projects that is acceptable.
  4. Discussions. Some organizations do not have formal status reports, but just hold formal or informal discussions with the sponsor and others with a need to know. This is very informal. Usually, if a person such as a sponsor wants an update they set up a time to talk to the project manager – may be just as a hall discussion.
  5. Tools. There are a number of tools that can help. These could be specialized status reporting and consolidation tools, or perhaps a general purpose environment like SharePoint.
  6. Phone messages. You could leave a status report voicemail. This eliminated the initial need for a paper-based report. Usually, you are also time bound to complete the report in two or three minutes – the length of a voicemail.

Remember that although there are many options for the format and technology of reporting project status, the need to communicate status. Status reporting is the way you manage expectations on a project and it is the minimum communication requirement for a project manager.

Use These Two Great Techniques to Help You  Plan Your Projects

Use These Two Great Techniques to Help You
Plan Your Projects

Project Planning – Work on the Project Charter, Schedule and Budget Simultaneously

There is not a sequential order between chartering a project, building the schedule and estimating the total cost. That is, you do not have to completely charter the work first and then build the schedule and budget second. Some of the sections of the Project Charter (click here for free template), such as the estimates for cost and duration, and a milestone schedule, cannot be completed without starting to lay out the overall project schedule. At the same time, you cannot complete the schedule without gaining agreement on some elements in the Project Charter such as deliverables and scope. 

Defining the work, and building the schedule and budget need to be done simultaneously. The main deliverables, the Project Charter, schedule and budget, should also be developed in parallel. You will find that as you gather information about scope and deliverables, you can start laying out a high-level schedule. As you gather more information about the work, you can fill in more details on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information to complete a high-level schedule. You can then use the high-level schedule to estimate the necessary budget – which in turn are used to complete the Project Charter.

Make Sure Everyone Understands Project Roles and Responsibilities

For small projects, the project organization is pretty simple – maybe just the project manager and the sponsor. The person who is managing the project may be the only person actually working on the project.

However, for large projects, there may end up being an elaborate and formal organizational structure. You may have team members, an executive sponsor, a project sponsor, a customer manager, a project director, a steering committee, vendors, clients, and others involved. You do not want to get overly complex, but the more people that are involved in the project the more important it is that everyone be clear on their roles and responsibilities. For example, the last thing you want is to have someone give you direction as if he were the sponsor when really he may just be a management stakeholder.

One aspect of defining the project is to define the organization structure and the roles and responsibilities of all the major participants. The typical roles and responsibilities can be defined ahead of time for your organization and then reused as appropriate from project to project.

You Need to Collect Metrics. Here are Two Approaches.

You Need to Collect Metrics. Here are Two Approaches.

There are two approaches for organizations looking to start collecting metrics. One is a formal, structured approach and one is an unstructured “let’s just do it” approach.

The Structured Approach

One way to get a metrics program started is to get a set of key stakeholders together and go through a planning exercise. This takes some discipline and forward thinking. The overall steps would include:

  • Identify criteria for success. First you need to define what success means to your organization. You would normally look at your business plan, strategy, vision, departmental objectives, etc. 
  • Assign potential metrics. Identify potential metrics for each of your criteria that provide an indication of whether you are achieving success. This is a brainstorming exercise so that you identify as many potential metrics as possible.
  • Look for a balance. The potential list of metrics should be placed into categories to make sure that they provide a balanced view of the organization. For instance, look for metrics that provide information in the areas such as cost, project success, quality, productivity, client satisfaction, business value, safety, etc.
  • Prioritize the balanced list of metrics. Depending on how many metrics you have identified, prioritize the list to include only those that have the least cost to collect and provide the most value to the organization. You usually want to end up with 5-8 metrics.
  • Set targets. The raw metric may be of some interest, but the measure of success comes from comparing your actual results against a predefined target.
  • Collect and analyze the information. Now the hard part – set up the processes to collect the metrics and analyze them on an ongoing basis.

The Unstructured Approach

There is another approach that can work. The basic philosophy is “just collect something, even if it’s wrong.” In this approach, some key people in the organization get together and look for information that can be easily captured that provide some indication of success in some areas. Then you start to collect and analyze. After you collect the data over time, you get a sense for whether the metrics are providing value and whether you need to find more or different ones. This approach may seem haphazard, but it gets you into the habit of collecting and analyzing metrics first and allows you to improve your metrics over time. I have seen this method work for some organizations.


Deciding to start collecting metrics is a great first step, but then you must decide how to get started on the work. Many organizations like a deliberate and thoughtful process to determine the metrics program. This can help you be more successful the first time.

The problem is that sometimes you don’t get past the planning to actually collect and analyze the data. Many organizations are not sure what information they need, so they just start to collect and analyze what is available. They then improve the collection and analysis over time. For many organizations it is better to develop good habits than to try to get things perfect the first time.


Do You Take Risks? Then You Understand Positive Risk.

Do You Take Risks? Then You Understand Positive Risk.

Risks are future events or conditions that have a probability of occurring and an impact to your project. You usually always think of risks as being bad. That is classic risk management. However, is it true that all risks are bad? Let’s say your project was going to utilize a new tool or new technology. This introduces some risk since you have not used the tool before. If it is true that projects are generally more risky when you use new technology, why would you ever undertake a project with new technology? The answer is that you perceive there to be a benefit to your project. In other words, the potential impact to your project is a positive. This still meets the definition of risk.

  • There is an impact to your project. Normally risk events have a negative impact on your project. However, with positive risk there is a potential positive impact.
  • There is a probability of the event occurring. This is still the case with positive risks. In the prior example, if the benefits of moving to new technology were guaranteed, you could make the decision to move forward with 100% confidence. However, the implementation of the technology could turn out bad, in which case you might be worse off than when you started.

Positive risk is also called “opportunity risk”.

One of the key aspects of positive risk is that you put yourself in a position to take on the risks. Negative risks are potential events that can happen to you. They are the ones that you want to avoid or eliminate. Positive risks are those that you knowingly take upon yourself since you perceive there to be advantages to do so.

Generally when you are doing risk management on projects you are talking about potential negative events. In all the projects I have managed or coached, I have never seen a project manager account for positive risk. However, you can identify and manage the risk events that lead to positive outcomes. These opportunity risks can be managed the same way as negative risks except that instead of eliminating the risks, your risk plan will include activities designed to give you the best chance that the risk event will come true.  

If you look at both types of risks, you can compare the negative risks with the positive risks to understand the overall risk level of the project.

Templates, e-Books, e-Classes and More

TenStep, Inc. is a leader in the development of business methodology products and services. The TenStep Store is full of products that we have personally purchased and/or evaluated. All products in The TenStep Store come with a full 14-day money back guarantee. If you are not satisfied, notify us within 14 days for a full refund of your purchase price.

Use These Eight Elements Within Your Procurement Plan

Use These Eight Elements Within Your Procurement Plan

There are many documents used in the procurement process. The Procurement Plan is a part of the overall Project Management Plan. The document describes how items will be procured during the project and the approach you will use to manage vendors on the project. Specific areas of the Plan include:

  • Purpose. Briefly describe the purpose of the project. This can be copied from the Charter. Some people may read this Procurement Plan without reading the Charter, so this section provides background and context to the reader.

  • Procurement Definition. Describe what will be procured, for what purpose, and under what conditions.

  • Procurement Responsibilities. Define who within your organization will participate in the procurement process and their responsibilities. This could be the buyers, the approvers, the investigators, the team members, the procurement specialists, the contract specialists, etc.

  • Decision Criteria. Define the process by which products and resources will be evaluated and selected. This could be a formal RFI, RFP, proposal evaluation process, etc. This could also be a longer or shorter process that is specific to this project.

  • Contract Type. Document types of contracts to be used and what actions need to be taken to initiate procurement. This can include fixed price, cost reimbursable, master agreements / statements of work, etc.

  • Contract Standards. Provide the contract standards that will need to be initiated and maintained for each contract. These will likely come from the Legal or Contracts group.

  • Ongoing Vendor Management. Describe steps the team will take to ensure that the vendor provides all products and/or services that were agreed upon, and how quality will be measured and maintained. This ongoing contract administration occurs throughout the project.

  • Project Procurement Plan Approval. List the individuals that need to approve this Plan. This may require a hard copy signature or some type of electronic approval.

The Procurement Plan is not required for all projects. However, if you have a large project with many procured elements, you should plan and frame the procurement approach with this Plan. 

Five Things You Need to Know About Action Items

Five Things You Need to Know About Action Items

An action item is an ad-hoc work activity that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an as-needed basis during meetings or as a by-product of working on something else. There is no Knowledge Area in the PMBOK® Guide for managing action items, but they can be important to the smooth running of the project. They are an important aspects of time management. 

  1. An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.
  2. Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be completed.) Examples of action items include forwarding specific information to someone, arranging a meeting and providing a quick estimate on a piece of work. 
  3. Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes called “issues”. However, this is not right. An issue is a problem which will have a detrimental impact on the project if left unresolved. Issues are not the same as action items.
  4. Trivial action items may be tracked and managed with a standalone Action Item Log

    . If the action item came from a meeting, you can create a section in your meeting minutes for action items. These trivial action items are usually less than two hours of effort and are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list. 

  5. If the action item is non-trivial (greater than two effort hours) you should add them as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal schedule activity. This is the better approach to follow, because it keeps the work activities in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on’. This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 4 hours of work. If you assign this action item to a person on the critical path, you will see the resulting delay to your project. This may result in you assigning the action item to someone else instead.

In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Track non-trivial action items in your schedule. Leave the true trivial action items on the Action Item Log. Projects tend to generate lots of them and you need some method to track and close them to ensure the project work continues to run smoothly.