Yes, You Need to Estimate the Project Size Before Gathering Detailed Requirements

There is concern from many project managers that they are expected to estimate the effort, duration and cost of a project at the end of the planning process before the detailed requirements have been gathered. It seems like a valid question. Yet, when you talk about gathering detailed requirements, you are usually talking about the Analysis (or Specification) Phase of a project lifecycle, not the up-front planning process.

Of course, you need to have a high-level understanding of the requirements before you can provide project estimates. However, the details are gathered after planning.

The following three approaches will allow you to execute the project before you have gathered the detailed business requirements. (As with many aspects of project management, iterative and Agile requirements are gathered differently.)

  • Estimate the work to within 15% after planning. This is the traditional approach. Many projects are estimated this way because the project is not so different from projects you have done before. If you have experience with similar projects you can make a reasonable estimate based on the characteristics of the project.
  • Break the work down into smaller pieces. If you don’t feel comfortable to provide an overall project estimate within 15%, you can break the larger project into multiple smaller projects. When you use this technique, you usually end up chartering an initial project to gather the requirements. You should be able to estimate this requirements gathering project to within 15%. After this requirements project is complete, you can use the information to charter a second project to perform the rest of the work, also within 15%.
  • Estimate in two parts. This is a variation on the first technique above. In this approach, the project manager provides a “best guess” estimate of the work at the end of planning. This estimate may be within 25% (or higher). However the project manager is not accountable for this estimate (unlike the first option above). This estimate is just best-guess given the information at the time. After the requirements are completed, the project manager provides a more detailed estimate of the work within 10-15%. This is the number for which the project manager is held accountable. Unlike the second approach, these two estimates are both made within a single project.

The first estimating approach is within the control of the project manager. The second and third approach likely require approval of your sponsor and manager. But either approach is better than taking a guess and having to live with the consequences of a bad estimate. That is not good for the project team or the organization.

Do you need help with estimating skills or estimating processes? Contact Menno Valkenburg or Dick van Schoonhoven for more information and to discuss your specific needs.

/by

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 gets you into the habit of collecting and analyzing metrics first and allows you to improve your metrics over time.
Summary

Deciding to start collecting metrics is a great first step, but now 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.

Let 2015 Be the Year for Getting Serious About Metrics
Yes, We know. Metrics are hard. Every organization knows they need to get better at collecting and analyzing performance data. But few do a good job. Yes, it is hard work.
At TenStep, we have a great model for setting up a metrics program. We can help you collect and analyze the right set of metrics at the project, program, portfolio orr organization level.
Contact Menno Valkenburg or Dick van Schoonhoven for more information and to discuss your specific needs.

/by

Consider These Five Steps When Starting a Project

Every time you’re given a new project, you first start with a process of initiating and planning. There are additional things to consider to ensure you start the project off right.

  1. Take responsibility. Take responsibility for delivering the project, and ensure other stakeholders are accepting their responsibilities as well. Be sure the sponsor will provide strong sponsorship, and that you have adequate funding and resources to complete it on time. Be sure you have a gut feel that the project is achievable. If you have concerns about the viability of the project raise your concern. Taking responsibility does not mean to be an order-taker. It means you also take responsibility to push back when needed.
  2. Understand the background and context. You really need to understand as much as possible about your customer’s business to know why the scope and priorities have been set as they have. Ask your customer what’s driving the deadline of anything, why you can’t reduce the scope further and why the deliverables have been prioritized as they have. This gives you good information to start the planning process.
  3. Identify the stakeholders. This is one of the most important aspects of starting a project. You need to know who the players are and their roles and responsibilities. You will need this information to know who to talk to for planning the project.
  4. Clarify the scope. You need to uncover the scope of the project to ensure that all of the deliverables to be produced during the project are adequately defined. You don’t want to get part way through the project only to find that your customer actually wanted different or additional deliverables that weren’t planned. Sit down with your customer and clarify all of the deliverables on day one. The complete set of deliverables forms the “scope” of the project and it’s critical that you document these before you get started.
  5. Understand if there is a fixed deadline and budget. Many projects have their deadline and budget set depending on the scope of work and the resources available. On the other hand, some projects are assigned to the project manager with a fixed deadline and budget. These projects can be harder to deliver. When a project starts it is important to know if you can propose the budget and deadline based on the work, or if these will be constraints given to you ahead of time.

…

Many teams struggle understanding how best to initiate and plan a project. Invite us in to help. We can facilitate a Project Quickstart session that helps identify project objectives, scope, risks, assumptions, constraints, milestones and more. Please call Menno Valkenburg +31(0)649417755 or Dick van Schoonhoven +31(0)611045033.

/by

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. The number of stories implemented in each iteration depends on the amount of effort it takes to fully implement each story.

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 has 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. O

The general characteristics of story points include:

  • Story points represent the total amount of work required to fully implement a user story.
  • The stories are estimated independently by team members and the team drives 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.
  • Many of the estimating models are designed as games that are interesting and engaging for the project team.

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”.

Summary

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.

TenStep Agile Services (English only)

TenStep has offered Agile speaking, training and consulting since 2001.

Training

Agile Overview Learn the basics in 1-2 days.
Prep for the Agile Certification Exam Learn what it takes to pass the PMI-ACP exam.

Content

Agile Combo. A 110+ page e-book and e-learning session.
/by

Do You Take Risks? Then You Understand Positive Risk

Risks are future events or conditions that have some probability of occurring and some impact to your project. You usually always think of risks as being bad.

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”. In these instances, the project manager or project team may introduce risk to try to gain much more value later.

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. They are not out there ready to get us. They are the risks that you step up to 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. However, you can also identify 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.

Does your team need additional training and coaching on how to manage risks? Please contact us.

/by