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: Are We There Yet?

Start. Stop. Start. Stop. That is how the Motorcycle Safety Foundation Skills session started. We had sat through some class room training and read about motorcycles and riding. They had made sure we had our gear and taught us how to start the bike. The next thing we all had to do was learn how to start the bike out and then learn how to stop it safely. Start. Stop. Start. Stop.

There were a number of helpful hints that we were taught when taking our riding training. They taught us was to squeeze the brake, not to grab it. Grabbing a brake on a motorcycle can lock the front or the rear wheel since the brakes work independently on most bikes. Locking the tires can easily take a motorcycle with rider to the pavement. We learned that the bike should be upright when trying to stop. There is less traction in a turn and when you slow down you create less traction and the bike could go down. We learned there was an art to stopping, it wasn’t just mechanical.

When I was a music student I frequently had to play pieces of music from memory. When I first started memorizing, I’d start at the beginning and when I forgot or made a mistake, I’d restart the piece from the beginning. I was told by my teacher that I better learn how to finish a memorized piece well. What an audience remembers is the end of the piece much more so than how it started. I was learning how to start the piece, not how it should finish. I changed how I memorized by starting at the end of the piece first and then work toward the beginning.

When learning how to manage a project I learned how to start one long before I learned how to stop. Most of my learning was around starting. To be sure, starting a project can be a bit of a challenge, much like using a clutch on a motorcycle, there is a place where the engine becomes fully engaged. If you let out on the clutch too quickly the bike will stall, too slowly and you won’t go anywhere. Starting out isn’t any easier than stopping. I would suggest that starting and stopping occur throughout the project and the grace with which we do those two things makes a great deal of difference in the project.

I’m not talking about just the start and the end of the project. Every project is filled with beginnings and endings throughout the project life cycle no matter what the delivery method. We have to learn how to gracefully start and stop analysis, planning, architecting, designing, developing, testing and every other aspect of delivery. Learning the answer to “Are We There Yet” is a critical skill that isn’t reserved for the end of the project. It is rooted in Six Sigma, Lean, TQM, and every other method. “Are We There Yet” is not just the mantra of the kids in the back seat wanting to get out of the car.

Learning how to stop is critical to keeping a project on track. Here are a few tips from motorcycling.

Keep Your Head Up – If you look down at the pavement you can’t see what is coming down the road. The same is true for managing a project. If you are only looking at what is right in front of you it is possible to miss what is coming down the road. It doesn’t matter what method you are using – it is a matter of focus

Check Conditions Frequently – Be aware of where you are in the plan, what risks you are dealing with, and where you are compared to the agreed upon stopping place. Scan for new risks or issues and stay in constant contact with the team (stakeholders and clients are part of the team). Use a near term, medium term and longer term view (in motorcycling it is a 2 second, 4 second and 12 second interval). Checking the conditions to see if stopping is needed is the most critical aspect of stopping. It is what prevents most accidents

Be Ready To Stop (“Cover the Brake”) – When you sense that you will need to stop “cover the brake”. Prepare the team for stopping, don’t just think it in your head, take an action and make it clear that stopping may happen. Check the conditions frequently

Stop in a controlled manner (“Squeeze the Brake”) – Don’t stop suddenly. It is in the gradual deceleration of the project, the slowing down in unison.

Get the Project “Upright” – Don’t stop while maneuvering through a curve. Make sure the project is in position to stop without running into problems. Tying up loose ends, closing down contracts, making sure it stops in a good place is important.

Starting a project, a project phase or a project deliverable can be challenging. Stopping at the right moment and in the right way may be more difficult. We learn by starting when we should learn how to stop well. Our teams will remember how well a project ends, whether through cancellation or through benefits realization, much more so than how it started. Even if we start out quite well, falling down at the finish is what is remembered.

Ride On, Manage On

Read more...

Project Management: The Balancing Act

When I first got started riding the motorcycle I would just ride, purely for the joy or fun of the ride. I learned early on that to have fun I would have to decide on a destination and the timing of the ride. Knowing where I was going and when I would arrive freed me so I didn’t have to continually figure out what was coming next. That didn’t mean I always knew exactly which road I was taking next, I just knew where I was going to end up. When I took the bike to get to some specific place at a specific time I took a different approach. I knew the route I would be taking and planned it out. The amount of time I took planning either kind of trip, joy ride or making an appointment, was in direct correlation to where I was going, how far away it was, how much time I had to get there and how familiar I was with the route I was taking.

When discussing agile and waterfall the language we use can make it difficult because the words can be interpreted in black and white. To say agile is adaptive is to suggest that waterfall is not which is not the case. To say that waterfall is structured is to suggest that agile is not which is also not the case. Like our political system, project delivery frameworks, styles or methodologies exist on a continuum. Just as someone might say they believe in the republican doctrine they could mean everything from the middle of the road to the far right and the reverse is true for a democrat. If we look at project management in a similar way, agile and waterfall could be considered to be on the left and right. There are those that believe that the far right is the best and those that believe that the far left is the best. I’m a moderate. I believe that both have value and when they are practiced to the extreme neither may bring the value needed.

It is easy to make the mistake of over planning, of trying to make sure that everything has been identified, logged, noted and agreed upon. It is just as easy to make the mistake of moving forward before enough information is known or documented. The balance between too much and not enough is one of the topics when discussing the differences between agile and waterfall. I would argue that the topic of not enough or too much should be discussed as part of any project approach. Each project team has the responsibility to determine the right balance at the beginning of the project no matter what the delivery approach is going to be. Shouldn’t a project team always ask how much work should be done?

To be sure, I can over simplify. The insight into what is best for a specific project is in looking for the simplest answer. The amount of analysis and planning needed should be based on a fundamental question and must be answered by the members of the project team. The project manager is accountable for asking the question repeatedly. Is any additional planning or analysis going to help us get to our destination within the parameters set by our customer? I don’t think that is an agile or waterfall question, I think that is a project management question. The client, sponsor, project manager and the rest of team must answer this question. You will always find folks who need more detail and folks who run from more detail. The voice of balance is in the middle of the continuum. Too much? Not enough? That is the balancing act and it is part of every method of delivery.

Ride On, Manage On

Read more...