Project Management: What Could Possibly Go Wrong?

All projects have inherent risk. Planning and preparing for what could go wrong can help make a small error from becoming a big mistake. Project risk is inevitable, consistent application of fundamental processes and tools will help the smallest efforts be successful.

One day, early in my motorcycling career, I took a trip to the local parking lot for a quick practice of my riding skills. I’d gone there many times to practice so that I would gain confidence to be able to ride with skill and awareness on more difficult roads. Might seem silly to some that I would be that cautious but I’d heard enough horror stories about death and injury to understand the risks. Besides, I had a family at home that I wanted to return to safely, no matter how far down the road I went or which road I took.

The parking lot is at a local school about 1.5 miles down the road. The roads in our town are marked 25 and 35 miles an hour so speed was not a concern. It was a September day and I knew I’d be hot moving at such a slow speed. It was a good day for a short skill building trip that was extremely low risk. I’d done this trip before and I would encounter little traffic along the way, I didn’t have to meet anyone so there wasn’t a tight time frame and I didn’t have to get home for any reason.

I would compare this ride to one of those projects that is similar to another project I’ve done before. For me, that would be like taking a piece of software and enhancing it in some way, converting data from one platform to another or even integrating a package into an existing infrastructure. I’ve done those kinds of projects during my career and am familiar with the risks associated with these types of deliveries. I don’t mean to say these types of projects are always the same. These efforts are not simple operational activities. They are projects in that they deliver a new product or service. We aren’t just plugging in numbers or plugging in existing code.

When I decided to go out on the bike I did what I was taught to do. I checked the weather, I planned my route, I planned what I would do once I reached the lot (the actual destination is the lot – getting home safely is getting everything back to a starting place) and gathered the obstacles I needed to do the skill practice, I checked my bike, I checked myself and then I put on my gear. The bike check consists of making sure everything is in good working order so that you can prevent a breakdown (or an accident) while on the trip. My gear consists of boots, jeans (Kevlar would be good), jacket, gloves and helmet. Yes, I said it would be a hot September day. Yes, that much gear can be hot. Yes, the ride itself is low risk. Yes, it sounds excessive. The riding gear I selected was made for warm temperatures. The materials are light and airy while extremely durable. The fact is that my head hitting the pavement at any speed makes a really bad sound. And my ankle getting hit with something from the pavement or skin abrasions on my hands, arms, legs or any other part of me doesn’t sound like fun. I want to avoid injuries and even though I know nothing is going to go wrong because this ride is low risk, I wear the gear. So I’m ready to go.

Wouldn’t you do the same kinds of things to prepare to execute one of those easy projects, one that is very familiar to you? I think we take the basics of getting a project ready for execution for granted. We fail to recognize that every project is a risk. Every project must be set up to succeed prior to starting the building of the product or service. We can decide to cancel the ride anytime before getting on the bike. The things I was taught to do before the ride allow me to have a successful journey. When I fail to do those things, I take on a great deal more risk. What are those things that I was taught to do before a ride in project language?

Checking the weather is like checking the organizations willingness to recognize the project as important and to provide the resources to complete the effort. There are times that delaying may be a better option than moving forward. I’ve ridden in downpours and the ride definitely looses a portion of the fun factor when you’re riding through a monsoon. Planning the route is akin to determining the methodology and the deliverables that will be used. Gathering the obstacles as part of my planning is like gathering the requirements. I wanted to test specific skills and needed to have those defined before I left. Checking the bike is like making sure that you have the tools necessary to achieve the goal. That includes things such as organizational process, software tools, and other needed resources. I check myself to make sure I can do the job, basically checking to see if I’m too impaired from a physical or mental perspective to be successful. Putting on gear? I relate the gear to the project management tools needed to ensure the destination is reached safely. Just because you have an accident doesn’t mean you can’t potentially get back on the road. The gear helps you do that.

So how did the ride go? It went well. I finished my practice and felt good about what I’d done. It was time for the ride home. This is where things didn’t go according to plan. I was pulling up to a stop sign to make a right hand turn. Before coming to a stop I looked to the left to make sure it was ok to pull out. It is surprising to me how heavy a bike gets when it is leaning over while coming to a stop. It is a good thing I had my gear on. I couldn’t hold the bike up even though I used all my strength. We hit the pavement at a dead stop. I was embarrassed and laughed at myself for such a silly error, otherwise I was fine. What could possibly go wrong? You can drop a bike while coming to a stop.

Just like the ride, every project has moments when the project could “go down”. It doesn’t matter how easy it may seem or how experienced the rider. Making appropriate preparations and making sure everything is in place before executing is essential. The right project management processes and tools in place for the type of project being managed helps the project accomplish the goal. I don’t leave my house to ride without my gear and I know there are certain non-negotiable project management processes and tools that must be in place. What could go wrong? A lot of things could.


Ride On, Manage On

Read more...

"We" Project Management

The personal accountability of each team member of a project is a key driver in the overall success of a project. The individual team member is accountable to the others to work in unison toward the delivery of the product or service. While the project manager is accountable for the outcome and sets the tone for that accountability, the team is accountable for the delivery. Every member of the team, from sponsor to developer to customer to tester, has a part to play. Without them working together the success of a project is less than it could be, if it succeeds at all.

When I was first starting to learn to ride I had to be concerned about the basics of motorcycling, I wasn’t able to take on passengers. I had to have a level of trust in my ability to ride before I could take another life into my hands. When I determined that I was a stable and capable motorcyclist, I had to consider the added weight of the passenger on the bike. It changed the dynamics of the ride, the heavier the person the greater the change. When I carry a heavier passenger I have to change the settings of the shocks on the bike. I have to remember that the bike needs more distance to stop and that when stopped holding the bike up takes more energy. I have to realize that turning the bike takes more strength and time and I can be distracted by simply having to be concerned about another persons’ safety.

My daughter loves to ride with me on my motorcycle. We discovered that the vibration, the calm, the scenery tended to put her to sleep. I knew she was drifting off when I felt her lean ever so slightly. When a passenger leans, if they are distracted, tired or trying to help, it could end in an accident. The passenger has to blend in with the bike, to trust the motorcyclist and allow the driver to control all aspects of the motorcycle. The passenger has to ensure that they are not trying to influence the direction of the bike. The motorcyclist is responsible for a smooth ride to help to instill the trust necessary so that the passenger doesn’t feel the need to adjust the ride. Communication is critical, verbal and non-verbal, although actions are much more important than dialogue. Things begin to happen too quickly to discuss what is going to be done or how it is going to be done. The time for that discussion is while you are planning the ride and before you get on the bike.

The passenger must do their part while on the ride. They are accountable for ensuring they follow the motorcyclist’s lead, that they are aware of their surroundings, and that they perform the role that they agreed to when the ride is planned. When the passenger or motorcyclist chooses to behave differently the motorcyclist is accountable for stopping the bike to discuss how the ride must proceed for the motorcyclist and the passenger to arrive safely. That doesn’t mean the driver can simply tell the passenger what to do and how to do it. The driver may be doing something that the passenger is concerned about. They must come to an agreement on how to proceed.

Projects behave in a similar manner if we think of the passenger representing the project team. The project manager must be confident in their ability to initiate, plan and deliver their own work using a standard process before engaging a team of people. Once secure in their ability to deliver they are able to take on leading others through the delivery process, to take on a passenger.

Project dynamics change based on the size of the project team. I define a project team as any stakeholder involved with the project. All too often we describe a project team as those team members who are doing the project delivery work. I would argue that every identified stakeholder has a role on a project and therefore is a member of the project team. Just as in motorcycling a larger team takes more energy from the project manager and the project manager must be aware of their personal limitations. I must admit when the team is too “heavy” for me to handle or too large for the bike (an argument for project phases). I am accountable for holding the team members responsible for their role so it is my responsibility to ensure they know their role prior to executing delivery. It is my responsibility for making sure they can perform their role (my daughter couldn’t, she would fall asleep). If they are not able to do so then a change must be made.

Once the team member has agreed to their role they are accountable for every aspect of that role. They are accountable for executing it to the best of their ability. The team member must notify the project manager if they become concerned about the ride, their ability to perform their role or the ability of the project manager. The team members should not alter their role (the same as leaning) while the project is moving rapidly along. Part of planning a safe ride is to put breaks, places to stop and check progress and ensure that everyone is enjoying the ride. A project should have the same planning for places to stop and take a look at progress and to ensure the team members are enjoying the “ride”.

The “We” in project management is a team accountable for their role, aware that they have a vested interest in the outcome, able to provide the right kind of support to the project manager, able to move in tandem with the project and able to signal when they have concerns. The project manager is still accountable for the delivery of the product or service. Each team member must play their role for the project to end successfully.

A critical component of that relationship is trust, between rider and passenger or project manager and project team. I won’t take my daughter on the motorcycle until I can trust that she can play the right role, she can’t fall asleep and she must move with the bike. As a passenger she won’t ride with me safely unless she trusts my ability to get her wherever we are going safely. That is the level of trust necessary in organizations and in project teams to ensure successful projects.

Ride On, Manage On

Read more...

Project Management: Do Accidents Really “Just Happen”?

I've heard the phrase "accidents happen" and it seems to echo along the same lines as "projects just fail". When someone says that it seems as if they have made up their mind that there isn't anything that can be done to prevent the failure or the accident from happening. Who is accountable for keeping a project out of the failure zone? The project manager is accountable just like a motorcyclist is accountable for keeping themselves out of an accident. Depending on others to keep a project from failure works in a similar nature to depending on a driver to not pull out in front of you. It is a recipe for disaster.

Every time I get on my motorcycle I know that I’m taking a risk with my life. The statistics are clear that motorcycles are a high risk form of travel. Why would anyone in their right mind take a vehicle that some call a “donorcycle”? The argument is that a motorcycle is an extremely economical form of travel, besides, it is outrageously fun, a wonderful way to unwind and a great way to stay in the moment and leave the distractions of the world behind. That being said, how do I avoid becoming a negative statistic? I think the answer is that is it my responsibility, and only my responsibility, to keep myself safe, protected and alive on the road.

Early on in my riding career I was told a number of things that have served me quite well. Each of these nuggets deserves their own post because of the magic that they contain in the simple truth that they contain. The first thing I was told is that I should always assume that I’m not seen by any other driver on the road. Even if I can see them look directly at me or clearly in my direction that I should assume they do not see me. I translated that into, if I’m on the bike, I am responsible for making it my destination. No one else is responsible or accountable. I’m the one that is supposed to be in control, the one that has taken on the risk. I’m not in control of the environment that I’m traveling in which would include the weather, the road condition, the route that I have to take and other drivers. I am in control of the road that is used, the direction the bike is going on the road, the velocity, the health of the rider and the health of the bike (to name a few). I’m ultimately responsible for how the ride is executed and accountable for my safety. I cannot give that to anyone else. If an accident does happen, there was probably something I could have done differently to avoid the accident, to keep the accident from happening in the first place.

I believe the same is true as a project manager. I am accountable for the delivery of the project, for getting the project to the destination. I cannot give that responsibility to anyone or anything else. If a project fails, i.e. it does not achieve the business value for which it was undertaken, there was something I could have done along the way to avoid that failure. I am accountable from the moment I agree to manage the effort to the point that the project is closed and complete. I cannot control the environment within which the project is being performed. I can control other aspects of the project such as my reactions to the environment, my communication about the environment, my leadership through the environment and many other aspects of the project.

In yesterday’s blog I made a clear distinction in defining the start and stop for measuring project success. Measuring project delivery success (the act of building the product or service) and measuring project definition success (the act of developing the scope/use case/architecture at the right level to be able to appropriately predict the needs for successful delivery) is, to me, an important distinction. This does not mean that the project manager is not accountable from the inception through the implementation. That accountability does not change, how success is measured and when the timer starts the measurement is what yesterday’s blog was meant to question. Just like a motorcycle ride, determining the destination and planning that ride are all part of making it a safe journey, the point is that the dynamics change exponentially once you get on the bike.

I am accountable. When I make the commitment to manage a project I am accountable for every aspect of that project. It doesn’t belong to any other team member or the organization. I am accountable for determining whether or not the destination is achievable, for ensuring the plans that are created can achieve that destination and for cancelling a project if those two things are not true. I’m accountable for the delivery of the effort once the decision has been made to build the product or deliver the service. I am accountable for the success or failure of that delivery.
Just as a note, I don’t think my accountability changes depending on the organization, the methodology, or the delivery approach (waterfall, iterative delivery, agile delivery). Yes, this is a bit of a hard line from someone who is usually more comfortable in the gray space. If I am riding a motorcycle and I have an accident I could blame so many things around me as the cause. The fact of the matter is that I still have the accident and, more than likely, there is always something that I could have done to avoid the accident.

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

Project Management and Motorcycling: Ride to Live, Live to Ride

Learning how to be a good motorcyclist has taught me quite a bit about myself, how I learn and how I manage projects. I took on learning something that has a high degree of risk and low tolerance for mistakes, sound familiar? Most of what I've learned has been through mistakes, near misses, or just plain foibles. I think it provides a new perspective to the meaning of project management and project manager and will be exploring project management through that perspective.

About six years ago I decided to take up motorcycling. It wasn't totally out of the blue, I'd always wanted to ride, I just hadn't done it "yet". It was easy to get the ball rolling, $8.00 later I had the booklet and the beginning paperwork. Two weeks later I had a permit and a motorcycle to ride and within a few months had my license.

So began my journey of motorcycle riding. When I started riding I knew I was taking on a risky proposition. Motorcyclists die on a regular basis due to accidents. I knew that I would need to be good at riding, to become proficient at motorcycling. There were a number of things I did to get there, I took a Motorcycle Foundation Safety course to get my license, I subscribed to a number of magazines to become familiar with the mechanics, the different thoughts about motorcycling, and some of the “ins and outs”. I also invested in a few books that provide tools and techniques of how to ride a motorcycle. I think the most important thing I did was to practice riding. I didn’t start out riding on the road but I practiced in a safe place, an empty parking lot. I needed to learn the basics like starting, stopping, turning, and shifting. These basic building blocks are what every driver needs to know how to do, no matter what the vehicle. It just so happens that making a mistake in a car or truck in a parking lot rarely ends in physical injury, not so with a motorcycle.

So why write about motorcycling when this blog is about Project Management? What in the world do these things have in common? I’ve come to learn that there are many correlations between them. I’ve come to believe that it is because these two things, motorcycling and project management, are both surrounded by, influenced by and driven by risk. Each time I get on a motorcycle I have to look at the risk that I’m taking on and each time I manage a project I have to do the very same thing. As I looked at my riding I began to see project management from a different perspective and began to think about how I managing projects.

There is a saying in the motorcycle community, “Ride to Live, Live to Ride”. Riding is a bit contagious. Those who ride usually love it and would rather be riding than almost anything. The rest of the world doesn’t often understand why anyone would take on the risk of riding a motorcycle. Is there a correlation in the project management community? I would argue that there are many project managers who would never choose to do anything except manage projects. They really enjoy project management and want to be proficient at managing projects. I don’t think I’d carry it so far as to say “Project Manage to Live, Live to Project Manage” but who knows?

And so begins the journey, motorcycling and project management. I’ll explore the mechanics, tools, techniques, the nuances and perhaps discover whether or not there is anything in this perspective that might shed some new light on managing projects.

Ride On, Manage On.

Read more...