Project Management: Measures of Success

When I was taking my first Motorcycle Safety Foundation course, I defined success as passing the tests. That meant that I had to be able to control the motorcycle enough to get it through the course without too many errors. I’ve taken the same course two more times and each time my measure of success changed. I still wanted to pass the test. However, I wanted to pass the test confidently. I could measure the time, points, and missteps because they were objective, visible and very measurable. How do you measure confidence? I couldn’t tell you what the exact success measure was, but I knew when I reached the level of confidence for which I was looking.

Measuring the success or failure of a project can be a bit like measuring confidence. It is possible to identify when you’ve met your scope, time, budget and quality measures. The data for those measures are relatively easy to capture. The more difficult aspect of gathering the measures of success is gaining agreement on what the tolerance is associated with those measures. The exercise for determining tolerance may seem a bit like defining when confidence is achieved. How far off can the scope, time, budget and quality be on a project for it to still be successful? Is it truly 100% or nothing? That narrow a project is filled with risk, we must provide a tolerance for less than 100%, or we warp our behaviors. Perfection is always a goal, never an outcome.

Successful project delivery is determined based on the successful delivery of the business benefits. We must look past the simple delivery of a product or service. We must measure our success based on what the product or service we are creating will provide. If we stop short of the benefit, we have missed the reason for doing the project in the first place and the consequence can be project failure.

“The bike will go where you look” is a motorcycling lesson that is critical to remember to be a successful rider. I was riding, it was a beautiful day for a ride, and I went into a turn a little fast. I was concerned because I couldn’t see around the bend very well, and I was approaching the center line. The harder I tried to stay away from the center line, the closer I got. I was staring right at it when I remembered “the bike will go where you look”. I lifted my head, looked through the turn and successfully navigated the turn without touching the center line.

This same lesson is true in project management. The project will go where the project manager is looking. When we focus on where we are going, it causes the success measures to fall into place. The tolerances for budget, time, scope and quality become clear. We are able to lead the project successfully because we are clear about where we are heading and why we are heading there. We can communicate with the project team based on business value rather than project deadlines, the business benefits rather than 0 tolerance and project success based on reality rather than perfection.

Ride on, Manage On.

Read more...

Project Management: Take Control?

I was riding to work on my motorcycle, and it had just started to drizzle when I felt my wheels lose traction. It was such a subtle feeling, the sense of no control. After what seemed like an eternity, the wheels grabbed the road, and I continued my journey. In that moment, actually more like seconds, I chose to do nothing and to let the bike “fix itself”. That is an unusual reaction for someone who takes control of situations that seem to be going differently than planned. I enjoy feeling like I am in control. The problem is that I can sometimes believe that I am in control. I’ve learned that the only control I have is in how I react to information.

One of the biggest problems we face in project management is control. Project Management literature is filled with lessons in how to control projects. We have metrics that tells us how we are doing in meeting our cost, budget and quality measures. We have books discussing project control, tools for controlling projects and systems designed to control projects. All of these are designed to keep a project “on track”, like guard rails designed to keep vehicles on the road. You can imagine what a car looks like after playing bumper cars with a guard rail and projects look the same way when they play “bumper cars” with the project controls designed to keep them on track.

Must projects be controlled to deliver business value or is it that business value must control project delivery? What should be the driver for project delivery? On time, on budget with an appropriate level of quality is still the rallying cry. The underlying assumption is that the business value is based on project delivery that is on time, within the scope, on quality and on budget. When we set projects up correctly, focused on the benefits, we establish guard rails that are based on the business value. If the cost benefit is tight, the controls are tight and there is a higher likelihood of project failure.

Projects must have controls to establish predictability. W practicing A L or Classic project management predictability is needed to ensure delivery. The issue is that we establish controls that are too narrow and cause more damage to projects than they add value. When I ride, I’m focused on what lies ahead, I don’t stare at the guard rail concerned about hitting it. The guard rail is in place in case I lose control, it does not to help me maintain control.

We must focus on why the project is being done, on the value it is creating rather than on what the project delivers. When we do this the project keeps forward progress, and we are less likely to respond to input that makes us sense the project is “losing traction”. Paying too much attention to the guard rails makes them more important than where the project is headed, the business value. Trying to correct small anomalies is like braking when a bike loses traction for a moment, it causes more damage rather than letting the project “fix itself”. Too much control can damage a project. What is needed is business value focused control.

Ride On, Manage On

Read more...

Project Management: Who Me?

I am accountable. As a project manager, I am accountable. I am accountable for my role on the project. The actions I take are based on project need. Are the actions I take the same for every project? No. Is it based on the organization, the goal, the team, the method and a myriad of other variables? Yes. While the role is the same, lead the project, the actions will vary. That is true for every other team member on a project. Is it possible to define a role and then assign that role to an individual? Yes. The problem is that assigning a role is different than as having someone determine what they can and should do for a specific project. Too often we simply tell folks what their role is, we don’t solicit from them what their role should be.

When I manage a project, or more importantly when I have agreed to manage a project, I’ve made a commitment to achieve some goal. I am accountable for that goal. In order to be accountable I have to believe that I can understand and achieve the goal and as the project manager I need to ensure that the team is committed at that same level. It is easy to commit to delivering some form or piece of documentation. I can deliver checklists quite easily. It is possible to commit to delivering a piece of software. The real challenge is to be able to commit to delivering business value. Is it possible for a project team to commit to delivering business value? We are asked to deliver software to provide business value. How can we stop short of the value commitment by suggesting that the project is done when the software is implemented? Is the business the only accountable party when we talk about projects delivering business value? We won’t ever become partners in delivery until we come to an agreement that the project manager is accountable for the benefit realization, not just software delivery.

Changing our mind set to look at the end of the project as when the benefits are realized changes the dynamic of the project team. The project team is put in a position that requires them to commit to something greater than delivering software. The business sponsor is held accountable by their management and the project team regarding the business value of the project. The project team must understand the business case of the project. When we take a look at the entire project delivery process, from an idea to achieving business value, project close cannot occur until benefit realization has reached closure.

When a project manager is accountable for the benefits, they have the responsibility for ensuring that the benefits can be realized. Once the project manager knows the benefits can be realized they can make the commitment to build the solution needed to achieve those benefits. Project success is based on benefit realization, not software delivery. Why is this distinction important? Cancelling a project because there are no benefits is a successful project. The project team prevents money being spent chasing a non-existent target. Shared success and mutual commitment are what makes a project team successful. The project team must have the same goal. The goal must be business value. Delivering software is part of project delivery, the goal is business value. When discussing project delivery, the project manager must be accountable for the business value if we are to ensure project success.

Ride On, Manage On.

Read more...

Project Management: Have We Started Yet?

Measuring project success or failure from initiation through achieving the business value that was agreed upon may not give us the information we need to improve our delivery. Initiating and planning a project correctly can end in cancellation or continuation into the build phase of the effort. A measure of success for initiating and planning a project correctly could be cancellation. The more precise the metric the better the information we will have for improving our ability to delivery projects and achieving the business value necessary.

One of my favorite books on motorcycling starts out by discussing motorcycle accidents. The reason for starting with the accident seems pretty obvious. If we know why accidents happen then we can develop skills for avoiding those types of situations. They gathered statistics on single and multiple vehicle accidents and categorized the primary cause of the accident. The causes were articulated in simple terms such as people pulling out in front of the motorcyclist, turning left in front of the motorcyclist, gravel in the road and such. While the details of the study are fascinating to me as a motorcyclist I think the value to me as a project manager is not in the outcome of the study but in the study itself. Most important to me is the boundary used for collecting the data.

Most motorcycle rides start before the motorcyclist actually gets on the bike. Choices are made long before pulling out into traffic. If it is a short ride fewer plans are made but the number of choices we’ve made along the way are about the same. The typical decisions are going to be where am I going, what route am I going to take, do I need to have storage available on the bike and what am I going to wear. In order to make those decisions I have to ask some questions (e.g. Do I have enough gasoline? Am I picking anything up along the way? What is the weather like? Is anyone coming with me?). The point I’m making is that the study captured data based on failure during the execution of the ride, not failure during planning or any other phase of the ride.

How is project failure measured? In the Standish Group’s Chaos report of 1995 (used here because of the popularity of use for project failure statistics) project failure was defined as any project that “is cancelled before completion or never implemented”. Should project failure be based on a similar measure as the motorcycle accident study (The Hurt Report)? Is a project a failure if it does not deliver the agreed upon service or product? How should we define that delivery, simply implementing the product or service based on the standard project delivery metrics (time, quality, and scope) or achieving the business value for which it was undertaken? And when do we start measuring? Is there value in measuring the projects that start and never get to the “build” phase which correlates to the actual act of riding the motorcycle? Using the Standish Group definition, a project could be cancelled before the project gets to the build phase and be considered a project failure. Why does it matter how we define the start and end for project failure?

The metrics we’ve been using have helped define the project management industry as a whole. The methodologies, tools, techniques, certifications and training classes have been in existence to try to solve the problems identified in studies such as the Chaos Report. While project delivery has improved I believe we can improve faster in efficiency and effectiveness if we can agree on the definition of project failure and when a project starts and stops being measured to determine failure (the ride).

I don’t want anyone to get the wrong idea – I believe the project studies have been valuable and have helped the project management industry – project performance has improved. I also believe that we must put in metrics that measure a projects success or failure based on delivering the business value, not in measuring time, cost and scope. While these may be delivered successfully, if the effort does not deliver the value it was designed to deliver then the project is not successful. That would also mean that we would need to be clear on when we call a project a measurable project. We don’t measure motorcycle accidents as any time a person thinks they are going to take a ride and decide against it. Why would we measure project failure based on thinking a project is a good idea and deciding differently? Let’s start measuring projects when they get “on the road”? Thinking about the motorcycle it would mean that someone had an idea, did some analysis, planned it out, got everything ready and then started the motorcycle. I think project failure and success should be measured based on “starting the motorcycle”. In a software project it would mean that the initiation, analysis and a majority of the design would be done prior to measuring the success or failure of the project. Is that too late in the process?

I have some concerns about measuring a project for success or failure following the completion of the high-level design. My main concerns are how much time, energy and money are spent doing those activities. How do we ensure that the effort is not excessive or wasteful? In other words, how do we end the wrong projects quickly and keep the right projects, the ones that will succeed, moving along quickly? I don’t think we can gain the insight into those questions measuring a project from inception through ROI.

I think measuring project success/failure based on “the ride” or “the build” portion of the project through ROI is critical. I also believe that the inception of a project through to the start of the build (the start of project failure/success) is part of business operations and therefore measured differently than the remainder of the project. Have we started yet? I would argue, not until you get on the motorcycle.

Ride On, Manage On

Read more...