Project Management: Starting Deliberately

One of the things about riding a motorcycle that is different than driving a car is how deliberate I have to be when getting ready to ride, when riding and when finishing my ride. That may not be true of everyone who rides a motorcycle, I’ve seen some folks with flip flops, cut-offs and a T-Shirt riding down the road. Those that are blithely unaware of the amount of risk they are taking or that don’t care about the risk. I’m not one of those motorcyclists. Riding down the highway at 65 miles an hour (or less) in a steel cage is very different than being perched on top of a 650 pound motorcycle.

The projects that have been the most successful for me are those that I’ve approached deliberately. Those are the projects that I’ve been clear about the decisions and the risks, understanding the consequences of each action taken by the project. Those are the project where I didn’t intentionally leave anything to chance. It didn’t matter whether the project was large or small, complex or simple, long or short, predictive or adaptive. It was the deliberate way in which the project was started, planned and delivered that made the difference.

I’m not suggesting that being deliberate takes a long time. I believe that being focused ensures taking just the right amount of time. I’m suggesting that there is a balance between the two extremes of not enough planning/analysis and too much planning/analysis, that the balance comes from being deliberate about framing what is being requested by the customer and what can be done to fulfill that request.

It doesn’t matter how far I’m going on the motorcycle, I always put on my helmet, gloves, boots, long pants (jeans, chaps or over-pant) and jacket. I do this whether I’m going around the block to make sure the bike is still in good working order or to the Outer Banks and back. It isn’t complicated and I do the same thing every time no matter how far or fast I’m going to be traveling. It is my life and body that depends on my deliberateness.

Being that deliberate about managing projects is equally important. It isn’t about being able to check something off a list. I don’t simply look at the helmet and move on. There is a ritual, a familiarity that comes from doing it the same way every time. When I’m in a hurry and am not thinking about exactly what I’m doing I can forget to do the basics like fastening the chin strap. Don’t laugh, I’ve done it. I’ve put on the most important piece of safety equipment and forgotten to make sure it would stay on my head.

I believe our organizations and customers depend on our deliberateness. The projects that we are accountable for may not seem like much. A minor upgrade, package integration, or software enhancement are all very familiar types of projects. It may not seem as if “my life and my body” depended on my being that deliberate. I would argue that an organizations on-going viability is based on the ability for it to stay current technologically. The organization will only achieve that goal through project management. An organizations life blood for moving forward and for achieving change is their projects.

It is critical to be deliberate about what I do when I start a project, making sure that I am focused on what is to be done and doing it in a measured way. I can’t allow distractions to shadow the work that needs to be done. I need to make sure to slow things down just enough to be sure the team, the organization and all of the stakeholders are fully prepared. That is a basic principle of project management that knows no methodology or style of delivery.

Ride On, Manage On.

Read more...

The Project Fun Factor

Projects can be tedious if fun is absent. Building a fun factor into projects will help their success factors. Since people are the fundamental value proposition into the success of a project, shouldn't it include some fun? What is the project fun factor? Where can the fun factor be found?

While I could rationalize why I purchased a motorcycle (gas economy, greener form of travel) the main reason I started riding was to enjoy my travel, be it to and from work or across the country. I didn’t see any reason to purchase a vehicle that was somewhat restricted as to when I could ride (rain, sleet, snow are not good for two wheeled travel) unless I’d have fun along the way. The fun factor in motorcycle riding is being in touch with what I am doing. It gives me an opportunity to be present, aware, in the moment, moving with the environment and the machine. It is as if I become part of the environment. I am the twisty road, the bumper to bumper traffic, the open road. When I am on the bike I can feel the temperature drop as I enter a valley, I can smell things like rain coming down the road, I am in touch with my surroundings. I am fully engaged, aware of my relationship to the surrounding traffic and focused on riding to the best of my ability. That kind of focus or belonging is liberating. I am not driven to reach my destination by fear but, by being the best at what I’m doing. If I were driven by fear I wouldn’t ride, there is no fun in fear.

So, I’ve made the decision that I won’t ride afraid and that I will have fun. It is important to make the distinction that knowing the risks is very different than riding afraid. I won’t take a motorcycle trip unless I believe I can get to my destination safely and I won’t do it if I’m going to be miserable. A challenging ride is part of the fun of riding so it isn’t about being conservative in the rides I choose. Making sure I can arrive safely doesn’t mean that everything will go according to plan or I won’t run into trouble. I just have a realistic belief that I am able to achieve what I’ve planned. If I don’t believe it, I don’t go.

I believe work, a project, has a fun factor. The fun factor is the same as the fun factor for riding a motorcycle. It is in being “in touch” with what we are doing. The project fun factor is being present in the relationships with those whom which we work, being present in the project we are working on, believing we can reach the destination safely, being fully aware of the changes in our environment, and by moving with the organization and the customer need. The fun factor isn’t in reaching the destination although that is part of the fun. The fun factor is in the project itself. When a project is driven based on being the best and not driven by avoiding the worst, the project is more fun and more successful. Being aware of the inherent risks associated with projects should not mean that we focus on the risks.

The motorcyclist is accountable for the fun of the ride. I believe the project manager is accountable for setting the project up for the fun factor. That does seem like a lot to ask of a project manager. I admit that every moment of every motorcycle ride is not fun. I would agree that keeping it fun every moment is not possible. I would argue that the rider, the project manager, has more to do with the fun than anything else.

When I ride I focus on being the best, doing the best, being present in my environment and being fully engaged. I strive to do the same thing when managing a project. Aware of the risk I focus on the destination. I am accountable to all team members for the fun factor.

The project fun factor: focused on being the best and doing the best, being present and in the moment, aware of the people around you and your environment. Let’s have some fun.



Ride On, Manage On.

Read more...

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