Weekly tips form TenStep Inc.

You Need to Collect Metrics. Here are Two Approaches.

/in /by

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.

Consider These Five Steps When Starting a Project

/in /by

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.

Agile 101 – Estimating Work with Story Points

/in /by

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.

Do You Take Risks? Then You Understand Positive Risk

/in /by

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.

Webinar: Project and Portfolio Management Using TenStep and Planisware

/in /by

When your portfolio of work consists of one or two dozen projects, it’s possible to keep track of what’s going on with spreadsheets or simple desktop tools. However, tracking projects, resources, and costs with standalone tools becomes increasingly more difficult as your project pipeline grows.

This webinar will focus in two main topics. First we’ll discuss the critical connection between the project management and portfolio management processes. In the second part of this webinar, we’ll demonstrate how a solid end-to-end PPM software can support and even automate your project and portfolio management processes. The demonstration will be provided using Planisware, Enterprise Project, Product Portfolio Management software solutions that support the end-to-end governance of company portfolios.

Join Tom Mochal, President of TenStep, and Michel Delifer, Sales Director at Planisware, in a discussion of these important topics.

TenStep webinars… attend… learn something.

Date: 4 December 2014
Time: 12:00 (Atlanta time) / 6:00 PM – 7:00 PM CET
Live participants will receive 1 PDU.

[button align=”left” link=”http://www.projectmanagementwebinars.com/freewebinars/2014-12-04ProjectandPortfolioManagementUsingTenStepandPlanisware.wmv” button color=”white” icon=”file-movie-o”]WATCH RECORDING[/button]

Six Reasons Companies Struggle Implementing Project Management

/in /by

[image source_type=”attachment_id” source_value=”150″ align=”right” width=”300″ autoHeight=”true”] There are many companies that do not have common project management processes, templates, approach and skills. One initial observation is that companies that don’t manage projects well are usually run by senior managers who never learned formal project management themselves. It is hard for them to lead culture change around project management when they don’t understand the value themselves. In fact, sometimes these managers think of project management as a tool for managing projects, rather than as a process for doing the work. When they discover a tool isn’t involved, they lose interest.

There are a number of other reasons why companies have not implemented project management processes. These include:

  • The company does not have committed sponsorship.

Some managers want to hold a training class and hope that project management sticks. They don’t have a strong commitment to the culture change required to get better at managing projects. In large companies, it could take two to three years, or longer. The sponsor needs to be committed and focused long term to make the changes successfully.

  • The entire organization is not included.

It’s hard to be a good project manager in an organization that doesn’t value project management skills. For instance, if you take the time to create a Charter document, and your sponsor asks why you were wasting your time, you are probably not going to be very excited about the planning process on your next project. To be effective, the entire organization must be part of the project management initiative.

  • The organization does not have a lot of pain around projects.

This is very common, especially in small to medium sized organizations. In many companies, the projects are not under pressure to complete within fixed deadlines and budgets. They just need to be completed within a “reasonable” timeframe. In these companies, there is not much internal pressure to change the status quo.

  • The organization is not scaling the processes and approach.

A common criticism of methodology is that it is cumbersome, paper intensive and takes too much focus away from the work at hand.  Sometimes this is a legitimate concern, caused by not scaling the methodology to the size of your project. For instance, if you were required to develop a fifteen page Project Charter even if your project is only 200 hours, you may have been turned off. This is not usually a methodology problem as much as it is a misapplication of the methodology.

  • The project teams fight the changes.

Many people want to solve problems and do their jobs creatively, with a minimum of supervision. They fear that project management techniques will result in controls that will take the fun out of the work. Without strong sponsorship, the project teams resist the change until the pressure goes away.

  • There is a fear of the loss of control from management.

If you really want to effectively implement a project management discipline at your company, you must give a level of control and authority to the project manager. Some organizations, and middle managers especially, do not want to lose that control. They may want people to coordinate the projects, but then they want to make all the decisions and exercise all the control. Formal project management will not be possible in organizations where this fear is prevalent.

Summary

These are some common reasons why project management is not sponsored at companies, and when it is sponsored, why it does not always stick. However, almost every study that looks at project management shows that it is a discipline that will help project managers deliver on time, on budget and within client expectations. All companies should have a common project management process to maximize the chances for delivering their projects successfully.

Manage Your Project Using the New MPMM V6 Methodology

/in /by

There are not many full project management methodologies available on the market. The Method123 Project Management Process (MPMM) is one of the best. MPMM includes an entire methodology for managing projects. It steps you through every phase, activity and task needed to complete a project from start to finish.

MPMM is a methodology because it contains more than just process descriptions. MPMM includes a full set of templates, completed examples, techniques, e-learning, and much more. It also comes with a full content management system which makes navigating the methodology very easy.

We are also excited to launch MPMM V6. This new version comes with complete integration with the PMBOK Guide from PMI. Now you have the content of MPMM along with extended and related content from the PMBOK Guide. It is a great combination.

During this webinar you will also get a quick tour of MPMM Program (for program management) and IT Lifecycle (for IT development projects).

Join us. You will learn about MPMM but you will also learn how a full methodology is structured and defined.

Thursday, September 25, 2014 6:00 PM – 7:00 PM CEST (The Netherlands)

[button align=”left” link=”https://www1.gotomeeting.com/register/428805984″ linkTarget=”_blank” icon=”pencil”] Register Now [/button]
[divider_padding]
[button align=”left” link=”http://www.mpmm.com/” linkTarget=”_blank” color=”gray” icon=”globe”]Visit Method123 Website[/button]

Four Keys to Gathering Business Requirements

/in /by

Stakeholder needs and expectations are set through the gathering and agreement of the requirements of the final solution. Gathering requirements usually requires more than asking a few questions and then building the solution. Projects with any degree of complexity need a formal process to ensure the right set of requirements are gathered, reviewed, documented and approved. Learn the model

  • Elicitation
  • Validation
  • Specification
  • Verification

TenStep webinars… attend… learn something.
Date: 21 August 2014
Time: 12:00 – 3:00 three hours (Atlanta time) or 6:00 PM – 9:00 PM (local CEST)
Price: $129 USD
Live participants will receive 3 PDUs.

Register: https://www1.gotomeeting.com/register/116389504