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

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