Project Management Checklists

Checklists have been around a long time as a project management tool. There are checklists for everything from initiating to closing a project. Checklists are an important part of preparing to move forward and validating accomplishments. The problem I have with checklists is that they are used too frequently, and they are relied on too heavily as static pieces of information. I’ve seen many failed projects with a multitude of checklists. A balanced approach to using checklists is critical.

Some examples of useful checklists outside of the realm of project management may be useful to show a healthy application. I’ve used a checklist when packing for travel for years. Interestingly enough I’ve always created the checklist before each trip. I know that some folks use a template and some start from scratch each time. Whether you’re a template person or not, reviewing the checklist to make sure you have everything for your trip is good advice. I use a recipe as a checklist to make sure I have all the ingredients. These two checklists serve different purposes. The recipe checklist is used to ensure that the result is the same every time. The travel checklist is to ensure the result is right for the specific trip being taken.

Checklists in project management can serve different purposes as well. It is when checklists are used like recipes that project managers get into trouble. Here are some guidelines for using checklists.

Checklist as a Planning Tool

Use the following questions when using a checklist as a planning tool. First up is “Do I need to do the item on the list?” When this question is omitted work is done that may not add value to the project, this is a waste of dollars and effort and can frustrate the Sponsor, Stakeholders and Team. Make sure you are doing only the work that adds value. It is like packing a winter jacket when going to Hawaii – it isn’t used and just adds weight. The second question that needs to be asked is “Is there anything that isn’t on the list that must be done?” This question should be asked every time, whether conducting a project such as repetitive roll out once the product is developed or new development, there is always something associated with the effort that could be different.

Checklist as an Inspection Tool

Establishing a planning checklist is only part of the equation. The checklist becomes an inspection tool once the contents have been established. An inspection tool is valuable to the project when it is relevant. That implies a continuous review of the checklists’ content. By that I mean a validation that the work that has been identified is still needed as changes to the project occur. Without that review, work is done that is not needed and work that is needed is not done.

Project managers who are new to the craft rely on checklists as guideposts. The issue is not their use, the issue is using them without due diligence. As the Project Management Institutes Project Management Body of Knowledge (PMBOK) suggests, using expert judgment and historical information is a must throughout a project. Checklists are no exception.

Ride On, Manage On

Read more...

Agile Principles and Project Management

I attended my PMI chapter meeting last evening. The presentation was about agile principles and project management. Since agile project management is such a hot topic I thought I’d give a quick critique of the presentation and the topic in general.

Let’s start with the things that annoy me about this topic and then get to the good stuff. My biggest complaint is that people who present this topic seem to slam the traditional form of project management. I don’t suggest that the traditional form is fantastic. Like I’ve said, project management has changed over time and continues to evolve, much like the manufacturing processes have changed. I am not sure what the value is to the audience, since most of the audience practices traditional project management it can be a bit offensive. Next up is that there is not context given to the agile principles that they believe can be adapted for traditional project management nor do they mention that some of the principles have been used, to some extent, in traditional project management in the past. There is no mention of the fact that agile requires the principles to work. That being said, the practices that the speaker mentions are good practices for traditional project management.

The two fundamental points that formed the basis of the presentation are that agile represents a more active management approach than traditional project management. I’m not sure I agree. Either I’ve been managing projects incorrectly or counter to the suggested method or that is an agile message that folks who practice agile use to provide the perspective that they are agile. Second, the premise is that agile is meant to help project teams “fail faster” and accentuated four points; closed feedback loop, increased control, a strong and well maintained team structure and identification of issues sooner.

Some principles were omitted and should be mentioned because their supporting concepts differentiate agile software development from traditional delivery. A couple of the principles have to do with the management style and how the team is viewed. First, the team members are considered motivated and should be trusted to do the next right thing and the team members are self-organizing, they are not assigned work as much as they assign themselves work. The second group of principles has to do with the technical aspects of delivery, which are to have rapid continuous delivery of useful working software and to ensure that technical excellence and design are part of the rapid delivery (can’t cut corners). These principles are more difficult to adapt to a traditional project management method, and I believe they deserve some exploration in future posts.

Ride On, Manage On

Read more...

There are two kinds of motorcyclists, ones that have had a mishap (accident, falling) and one that hasn’t had one yet. One thing every new motorcyclist learns is that, at some point in their motorcycling career, they will drop their motorcycle. When I started riding, I knew it was just a matter of time before I fell. The same can be said of project managers. At some point in their career, they will have a project that falls. The extent of the damage to the project and the project manager, just as in the case of motorcyclist and motorcycle, is based on the amount of risk that the person took on for the effort.

Projects aren’t conducted in isolation, which means that the environment will change, sometimes for the good and sometimes, well, in the opposite direction. I haven’t met a project manager yet that has a perfect record of “on time, on budget, with quality delivery” for every project they’ve managed. I have met many project managers that have managed to avert disaster, where the project was not considered a failure, although it wasn’t considered a success either. Project errors, mistakes, miscalculations are part of maturing as a project manager. We have “opportunities” for growth where our best laid plans meet with unforeseen circumstances. These project errors are part of project management.

The trick to being a successful project manager is to manage the project difficulties and avert project disaster. The characteristics of the project managers that have been most successful in their careers have been those that have managed to stay “out of harms’ way”. There are some specific skills that these successful project managers have that have helped them to deliver projects successfully.

First, they know their stakeholders. That is more than identifying the stakeholders and capturing their needs and expectations. They have gone beyond those tasks and are able to identify the significant few, those that require more attention because of their role in the organization, their expertise for the specific project, or their influence. The project manager connects with those specific individuals differently than with the rest of the stakeholders. Obtaining direction, buy-in and support from those stakeholders can make or break the perception of success or failure of a project manager or a project. Since perception is reality, their backing is critical.

Second, they understand risk. It isn’t that they identify risks and perform the risk tasks. They understand the cumulative nature of risk and make specific choices about how to frame a project, present information on a project and strategically manage the project. They have mastered the art of ownership of project risk and are firm regarding the degree of risk that they believe is appropriate for the project they are managing.

Third, they can communicate project information accurately to the right people at the right time. They don’t cry wolf and they don’t cover potential problems. They are transparent in the communication and are not willing to gloss over potential problems and are willing to stop a failing project.

These are not the only reasons a project manager is successful. I would say these are my top 3. Know your stakeholders, know how to manage a risk portfolio and be able to communicate effectively. When you don’t have the right backing and the risk is above tolerable levels it won’t matter how good you are at controlling the other aspects of the project.

Ride On, Manage On

Read more...

Project Systems

One thing I've learned from managing a large number of vastly different projects is that creating the appropriate project system is one of the ways a project manager adds value. The project system is made up of the relationships, methods and tools for the project. The components of the system are what provide the structure for the project. The interdependence of the relationships, methods and tools provide the boundaries inside which the project team can achieve the objectives of the project. Without these components, project teams struggle to know how to work together, which usually contributes to project failure.

Project systems are evolutionary. The reasons for this evolution are rooted in the fact that most projects are designed to make money, to save money, or to avoid spending more money than necessary. It wouldn't be necessary to have any form of project structure except one type if it weren't for money. The newer structures are designed to enhance the projects' ability to deliver value sooner. The project system is a value proposition and there will continue to be growth and evolution to provide value at the earliest possible moment based on the project. Project management will evolve in conjunction with the project systems to continue adding value to project delivery.

Projects aren't conducted in a vacuum. Every organization has multiple active projects at any given time, which suggests that, as project systems evolve, an organization must evolve their program and portfolio management. This dynamic suggests that project managers must be knowledgeable about more than just project management. Project managers must understand how the organization handles the programs and portfolios since the methods used will impact the types of project structures that will work best for an individual project.

The simple truth is that each project is unique, which causes each project system to be selected based on the unique qualities of the project. Which structure to use for a project is determined by the following factors (not a complete list):

The level of experience and competency of the team members

The size and complexity of the project

The maturity of the Project, Program and Portfolio Management

The culture of the organization

The risk tolerance of the customer

The number of stakeholders

When we view projects as systems acting within a portfolio management system it becomes easier to identify the best structure for the project. Employing predictive, adaptive or extreme methods to achieve value quickly is only possible by considering the entire system. Creating the right project system allows team members to work at the highest level possible, allows adaptation to change occur, and support the customer in the right way. No method is the best method for all projects, there is a "good, better, best" selection that, when made, enables success.

Ride On, Manage On

Read more...

Agile Project Management Experiences

I first started hearing about agile software development about 5 years ago. The company was working on a project designed to develop a web based incident reporting system. The lead technical team, new to the organization, was experienced in agile delivery wanted to use agile for the project. The project management staff was trained in traditional or classic project management and the organization was used to the language, tools and techniques associated with traditional project management. Agile software development wasn't a movement in the company, hadn't been introduced as the next great thing, the project wasn't even tagged as an agile project. After some debate at the senior management level it was determined that agile delivery was the best method for this project.

The project used paired programming, test driven development, iterations, regular builds and many other benchmarks that "make" a project agile. A project manager who had no agile delivery experience was assigned to the effort. This is where some issues began to be noticed within the organization. The project manager used the predictive, plan based management method they were familiar with rather than adapting to agile concepts. The project was going well based on the clients perspective. The client was able to dictate the next two weeks worth of project work, was heavily involved in the development of the software, and the software changed on a bi-weekly basis in their favor. Everything that was being requested by the client was part of the scope of the project. There were problems though, and the project manager was under the gun to answer the concerns.

When the question of "when will it be done" came up, the project manager wasn't armed with the language of agile or the metrics and wasn't able to present information to the stakeholders in a meaningful way. The stakeholders that were struggling with this new form of delivery were not the customers of the software. The stakeholders that were concerned were those that needed the resources next. The software had to be "done" at a point in time so that other software development could commence.

It seems to me that the example above could be any company. Company's are looking for THE way to get to market quickly, THE way to get software completed with less cost and THE way to maintain a competitive advantage. This isn't new, company's have been looking for that since the first company started. What is different today is that there is more than one acceptable way to manage a project. That is a good thing. There are a few things that must be in place to allow projects to work using different methods. First, the methods have to be defined and agreed upon. Notice, I didn't say create mountains of documentation. They must be defined so that team members know what is going on. Second, there has to be a reason to use one method instead of the other. Third, metrics need to be in place to support both the metrics and the communication of the status of the effort. Lastly, there should be one portfolio of projects that all projects report information to so that the organization understands how the money is being spent. As a project manager it is important that the portfolio view exists, otherwise I don't know when I'm going to get what I need to be successful.

Ride On, Manage On.

Read more...

Now Project Management

The Motorcycle Safety Foundation Basic Rider Course is divided into classroom and hands on training. The purpose of the course is to help motorcyclists understand the risks of riding, the fundamentals of a motorcycle, and how to ride. I was sitting in the class room portion of the course and the instructor was discussing the 2 second, 4 second and 12 second rule and how it helps keep a motorcyclist out of harms way. The 2 second view helps avoid immediate dangers, the 4 second view for is for preparing for things that could occur and the 12 second view is for fewer pressing concerns, although critical to view traffic patterns as possible warning signs. The course then uses a video to help accentuate the point. Viewing the video is like playing the game "how much can you see given 2 or 3 seconds to look"? After we described what we'd seen they asked us to explain what actions we would take based on the what was happening in the video. It was a good way to think through hazards and determine the actions needed at the given moment to maneuver safely through to safety.

I was managing a project when my lead architect came to me with an issue. We sat down and discussed the problem to determine what our next steps should be and decided that, based on the criticality and impact of the issue, we should move into the problem solving process we'd outlined at the beginning of the project. Long story short, we implemented a solution based on the best alternative possible. After that problem was solved I pulled the team together to gather leasons learned. We covered the standard leasons learned and discussed how we handled this particular issue. I then moved into a leasons learned about the timing of when this problem was identified. The team had mentioned that this issue should have been identified as a risk earlier so I thought it important to uncover the reason for this apparant miss.

One of the things a project manager needs to balance is the past, the present and the future. This lesson learned covered all three. We retrospectively reviewed the problems' path within the project. We discussed the apparent miss when gathering risks, the manner in which the problem was handled when it became an immediate issue and how we could prevent this type of "fire" next time. "NOW" Project Management doesn't avoid the past and nor avoid preparing for the future. It emphasizes what needs to be done "Now", in this moment, at this time. Whether we are looking at 2 seconds, 4 seconds or 12 seconds, there is something we should do NOW for all of these elements. Whether it is simply to put something on a watch list, to do an immediate corrective action or to put together a plan of action, there is something in this moment that should be done. The most important thing to remember is that, whatever we did yesterday is complete and we have new information. When we stay in the present moment we have both a changed past and a changed future. Nothing about our present is stagnant.

When we stay in the Now, in the present, we have a clearer picture of what is going on in our project, we have a better understanding of the relationships between what has happened and what may happen, and we have a greater appreciation for the project dynamics. The great thing about having a project team is the opportunity for perspectives outside of our own to look at the project landscape and be able to view the past and the future differently. Making sure to review todays' information such as tasks, decisions, risks, issues, assumptions and constraints is important. None of the activities associated with managing a project are a "once and done" endeavor, hence checklists can be deceiving. It would be easy to manage a project if nothing changed, if our predictions all came true and our plans were always correct and the past always supported the future. That isn't the case.

Managing projects in the Now is important for the stakeholders. Providing a lens into the current state of a project, not a predicted past state or a hoped for future state, a present state. When we speak in the language of "if" we are not in the present state. The language of "if" is one of conjecture and hope. The language of "Now" can seem impersonal, cold. The language of "Now" is factual in nature, like a snap shot. It is a picture with a caption of what the project team sees and what it is doing today to prepare for what it sees. That is what "Now Project Management" is designed to do for the project. Keep the language to what is being done today, not about what will be done "if" something occurs. Don't misunderstand, contingency plans are important, more important though is that a contingency plan has been put in place today. The question that is most important in a project is "What must we do today". What the plan is is secondary to having a plan. "Now Project Management", stay in today and answer: What did the project complete yesterday? How did that affect the project tomorrow (2 second, 4 second, 12 second view)? What needs to be done today as a result?

Ride On, Manage On

Read more...

Project Management Decisions, Decisions, Decisions (Tools and Techniques)

I've introduced the importance of the team planning a decision-making process (team agreement to the process is very important), I've provided some principles associated with a decision-making process, and I've sited some sources for decision-making processes. I thought it might be helpful to talk about some tools and techniques associated with decision-making.

The first stop is to take a look at what is already available rather than invent any new information. The number of sites and texts providing guidance in decision making tools are numerous. Let's start with the Web sites available.

Mind Tools supports both problem solving and decision making. The list of tools associated with each are listed under the associated headings. The information is free, the instructions are clear and the site outlines when and why you should use the specific tool. This is the easiest and richest site I found for tools and techniques.

Decision Making is a very interesting site. It contains a well researched process for making various types of decisions in a team environment. Everything on the site is not copyrighted and is free for the taking. It contains a decision-making worksheet in short and long form. The short form is four steps and the long form is 14 steps. Be sure to apply the principles to this tool.

The Businessballs.com site contains links to some of the tools and techniques for making decisions. It provides both process and the tools and techniques during the different steps of the process.

Wikipedia has a site on group decision making containing links to a laundry list of tools and techniques. I mention it here for purely providing the information regarding where you can find more information. The other sites cover the topic well and this site doesn't add much additional value.

The next list is for books available. These are for tools and techniques only. The drawback to these is that you have to spend money which the sites above don't require.

Goal/QPC has a number of helpful reference books for process and decision making. The Memory Jogger II has always been a favorite. When I got my copy, I spent all of $5. It has a great list of tools and explains their use and provides an example. It is a great pocket companion.

How to Make Meetings Work is another favorite. Michael Doyle and David Straus authored this book some time ago and it is still useful today. It provides guidance on the facilitation skills needed to effectively use the tools listed on the sites above. The price of less than $10 makes this one a great bargain.

There is a whole class of books for decision theory and making decisions under uncertainty which I haven't mentioned. These books are helpful in studying how we get to the decisions we make or our internalization of decision making We'll touch on that information some other time. The keys to effective decision making are to have a process in place before the emotions of making decisions take hold and to have the ability to call upon the various tools and techniques available based on the project, the decision and the available information.

Ride On, Manage On.

Read more...

Project Management Decisions, Decisions, Decisions (Principles)

Accepting the fact that the project management plan will change in unknown ways is part of managing projects. The fact that change happens is the reason to put a plan in place for making decisions. Decision-Making occurs in traditional, iterative, agile, extreme and lean project management methods. Putting a team based decision making process in place will make achieving project objectives easier.

I am a project manager which means I'm accountable for the delivery of the product, service or result of the project I'm managing. I am accountable for delivering the objective based on some group of constraints such as time, budget, scope, technology, risk or resource. I work with the project team (including sponsorship and stakeholders) to outline the project management plan that will accomplish the goals and objectives of the effort. I am always aware that the plan I put in place today will change due to realized risks, unforseen opportunities, a stakeholder changing their mind, or changes in the market conditions. Approaching decisions in a similar manner throughout the project helps stabilize project outcomes.

I thought I'd do some research for those of you who like to have a few places to look for more information. In the book Project Management: A Systems Approach to Planning, Scheduling and Controlling, Harold Kerzner dedicates a chapter dedicated to Trade-Off Analysis. In the chapter he describes, in detail, a six step process. In the book Implementing Six Sigma, Forrest W. Breyfogle III outlines a six step process for problem solving. Rober K. Wysocki suggests a six step process in his book Effective Project Management: Traditional, Agile, Extreme. Answers.coms' site on decision making outlines a six step process and businessballs.com outlines a six step process as well. Even though each of their approaches has six steps each process is a bit different. The good news is that all contain the same basic principles. The main reasons for the differences is the emphasis they put on the different problem solving principles or characteristics. I also took a look at the approach outlined in the Project Management Body of Knowledge (PMBOK), an ANSI standard for project management processes. It also contains a six step process which is similar to the other processes sited. Because the PMBOK is considered by many to be the standard to follow I've summarized the process they suggest as: define the problem, generate alterative solutions, select the "best" alternative, make sure you have key stakeholder participation and commitment for the selected alternative, conduct post-implementation lessons learned, and review how well the solution met the need. Rather than suggesting 4, six, 9, or more steps I'd like to outline the principles or characteristics that a problem solving process should contain.

Principle 1
Know who decides what and who should be involved in the decisions. Nothing is worse than getting to the answer without the right people in the room making the decision. Determine who has accountability for which types of decisions and the breadth of control that the project manager, stakeholders, sponsors and team members have. You don't want the business team members making architectural decisions and you don't want your architect making business decisions. Although this is a rediculous example I've seen worse things happen. Avoid disasters with clear decsion making roles.

Principle 2
Make sure that everyone is working on the same topic. I've been in meetings where there is a lot of passioned debate about something without defining what the debate is about. The English language is a challenge and determining the issue, question, or opportunity is critical for the rest of the process. It is the garbage in, garbage out notion. If we aren't in agreement to what we are working on there is no point in going further.

Principle 3
Facts are better than instinct and fiction. Don't get me wrong, instinct is awesome and uncovers and resolves a host of issues. The underlying problem with instinct is that it is usually based on some truth, some fact. It is important to know what the facts are and what the facts are not. The facts will help define and solve most items that cross a project managers desk. An important follow on is to use the facts that are available TODAY. Performing analysis is helpful and provides factual information and it can chew up time and dollars pretty quickly. Be aware of how quickly the decision needs to be made and the potential effort necessary to bring the decision to closure. Some decisions feel like a project all by themselves. Be Wary of Decision Scope Creep.

Principle 4
Breadth before Depth. Dream of the possibilities, think outside of the box, blue sky and open mindedness. The team doesn't get to stay in this space for long so making sure it happens is important.

Principle 5
You can have only one. Whatever the solution is going to be, it has to win in some way. The decision making tools for coming up with a winner vary widely and can be statistically oriented or simple vote oriented. Whatever the tool is, the team should agree to what the decision criteria are and that the solution "won".

Principle 6
The team (project team members, stakeholders and sponsorship) must actively support the solution. Enough said.

Principle 7
Plan the implementation. The solution must have an implementation plan which should ensure that your solution is indeed viable. It doesn't have to be a formal plan unless the solution complexity warrants it.

Principle 8
Know what you implemented worked. Review the solution after it is implemented solution should be reviewed to see if it did what it should have done. The same principle holds true for a project. It ensures success.

Principle 9
Remember what you decided and why. Hind sight is always 20/20. If you have the facts about the process, the alternatives and the decision you will be able to provide yourselves with insights when similar questions arise.

Principle 10
Nothing is ever set in stone. Whatever the process for making decisions is, it can always change based on team, project or organization need. Don't get stuck.

The number of steps that your decision-making process has aren't as important as the principles on which the process is developed. These ten principles will help ensure that your decisions are built upon solid ground.

Ride On, Manage On

Read more...

Project Management Decisions, Decisions, Decisions (intro)

I was heading down the road on my motorcycle and could see the sky ahead grow darker. The skies weren't a solid stretch of darkness, there was some sunshine mixed in so that I carried some hope that I wouldn't be riding into a downpour. I didn't know the road well and the curves would take me away from the bad weather and then back towards what looked like soaking rain. I'd been riding for about 2 or 3 hours so I pulled over at a gas station to fill up and assess the situation. Time to put my project manager hat on.

Project management, as defined in the Project Management Body of Knowledge (PMBOK), consists of applying "knowledge, skills, tools, and techniques to project activities to meet the project requirements". It goes on to mention that it requires "balancing the competing project constraints". There are other books that define project management similarly, project management requires planning, organizing and controlling activity to obtain the project objective. All of the definitions boil down to making decisions or, at the very least, pulling together the information needed for making decisions by a project sponsor, change control board or other group responsible for decision making within the project structure. Whether making the decisions or presenting the information, the project manager must determine the decision making process(es) for the project to ensure consistency and ease of use for all team members.

I finished filling the tank and moved the bike over to think through the situation. Storm clouds were moving briskly and there was a bit of a wind. I knew I was looking at a 50% chance or more of getting caught in some rain. I didn't have much of a ride left, maybe an hour or an hour and half. I'd ridden in the rain before so I knew how it would turn out, actually, I'd ridden in a storm before. The criteria that I looked at for my decision was my personal experience, my motorcycles ability in the rain, the likelihood of getting soaked, and how much longer I had to go to my destination. What's a little water anyway? I took off down the road.

Decision making processes don't have to be complex, cumbersome or take a great deal of time. There are a few things that can be done to make it easier such as determining the process ahead of time (inputs, tools and techniques, outputs), determining the roles and responsibilities involved in the process and then simply following the same process each time. Minimizing the importance of making clear decisions is counterproductive and making the decision making process complex slows progress. The goal of making decisions is to do so with the available information when the decision needs to be made. Maintaining simplicity in the process is critical to keeping the project team, including stakeholders and sponsorship, engaged. A good process ensures appropriate participation and ensures healthier decisions.

Good decision making is at the heart of good project management. Setting the project up for successful decision making is a critical part of being a good project manager.

Ten minutes after I started down the road the rain started, just a drizzle and then sunny skies. Well, sunny skies for a moment. When I arrived at my sisters’ house my legs were soaked but I had a smile on my face. I was safe at my destination and got to play in the rain.

Ride On, Manage On

Read more...

Constraints – Again

While writing yesterday I discovered that the topic of constraints was larger than a single post. What came to mind is the negative connotation that the word carries. I once managed a project manager that suffered from “the sky is falling” perspective. I’ve been there so I can relate. It comes from a belief that “the client wants what they want when they want it and we’ll never be able to do it”. The constraints that project team is handed will doom my project to failure. These are not the self imposed constraints they are the organizational constraints that every project faces. Since each project has constraints, I thought about the successful project managers I’ve known over the years to see how they handled project constraints. There is a common thread.

I did a little more research into the project management world of constraints. Harold Kerzners’ book Project Management: A Systems Approach to Planning, Scheduling, and Control (seventh edition) discusses constraints as “Trade-Offs” and has a chapter dedicated to this topic. The key to his chapter is the discussion on the decision-making process associated with the “Trade-Offs” or constraints. He mentions the big three of time, cost and performance (quality) but goes further to show resources (not just human resources) as forces (which could be described as constraints) influencing the cost, time and performance “Trade-Offs”. A text by Robert K. Wysocki called Effective Project Management: Traditional, Agile, Extreme discusses the constraints in terms of a “Scope Triangle” and emphasizes the need to balance these constraints. His big three are Time, Cost and Resource Availability with Scope and Quality in the center. He goes on the show the application of the “Scope Triangle” in the areas of problem solving (decision making) and scope change impact analysis. Lawrence P. Leach has two texts that discuss the Theory of Constraints (TOC), a management philosophy developed by Dr. Eliyahu M. Goldratt. TOC suggests that complex systems are inherently simple and that the numbers of constraints that limit achieving a goal are few in number and could be as few as one. The texts are Lean Project Management: Eight Principles for Success and Critical Chain Project Management.

So, back to “the sky is falling”. Constraints can make you feel as if you are in a corner and you can’t find your way out. They restrict your movement like a cast keeps you from moving in ways that could be harmful. They are like the boundary of a sandbox in which you can play to your hearts’ content. You just can’t go outside of the sandbox. The common thread in those successful project managers is that they used the constraints as a catalyst for creative ideas. They saw the constraints as part of every project. It isn’t that they didn’t question the constraints, try to stretch the constraints or work to alter the constraints. They didn’t see the constraints as the enemy of the project and they didn’t deny the constraint existed. They had a clear sense of what the constraints were, how important each individual constraint was to the project sponsor and organizations leadership (their primary stakeholders). They used constraints as a tool for effective decision making. That is what a constraint is in the project world, a tool for effective decision making.

Determine your decision making model and then apply the project constraints to close out your decisions with the knowledge that your constraints will drive you in the right direction.

Ride On, Manage On

Read more...

Project Constraints

I was riding my motorcycle from Manteo in the Outer Banks to Chapel Hill, NC when I came across a road sign that made me want to stop in my tracks. The sign warned of constant, strong cross winds on the bridge between the Outer Banks and the NC shore. Since it was a bit windy anyway I was concerned. Besides thinking I was crazy for taking the trip from Columbus Ohio to the Outer Banks to Chapel Hill and back home alone, I thought about the constraints influencing my decision about what I would do with this new information.

Constraints are a normal part of every project I’ve ever managed so I have gotten used to events, processes, technology or people that limit my options to making forward progress. The dictionary definition of constraint is “limitation or restriction” with synonyms such as “force, obligation, pressure”. Constraints are information for the project team and are defined in the Project Management Body of Knowledge (PMBOK), a standard for project management processes published by the Project Management Institute, Inc (PMI), as:

“The state, quality, or sense of being restricted to a given course of action or inaction. An applicable restriction or limitation, either internal or external to a project, which will affect the performance of the project or process.”

Based on this definition almost any project parameter could be a constraint. A constraint is imposed upon the project and must be taken into consideration when performing project activities such as planning and problem solving. The PMBOK goes on to emphasize that project management includes “balancing the competing project constraints” and the project manager “manages the constraints”.

The reason there is a focus on constraints is because constraints provide the filter through which most project decisions are made. In the world of motorcycling the constraints include the weight the bike can carry, the speed of the bike, the road surfaces, the weather, the condition of the tires, the hours in a day, and so on. If that is a partial list of the possible constraints for a motorcycle ride think of the project constraints that can exist. In order to provide focus to a project it is important to be aware of the possible constraints while focusing on the significant few.

The triple constraints of time, quality and cost have been called a triple constraint. The “good, fast, cheap” rule of thumb was that a client could have two of the three, “good and fast” is expensive, “fast and cheap” has poorer quality, and “good and cheap” is slow to deliver. The formal list of constraints that require project management focus has grown over the years. More recently I’ve seen the list include scope, cost, schedule, resource, quality and risk. I’ve also seen technology listed as a constraint. Identifying the project constraints is important for making knowledgeable decisions.

As I continue riding I thought about the weight of the bike, how strong I am, how awake or tired I am, the length of the bridge, the width of the road, when I said I would arrive, what other roads would take me to my destination and every other constraint that I was able to think through. I thought about my experiences riding in heavy cross winds before and decided to continue forward. The impact of my decision would be I would get tired sooner which could impact my drive time.

Projects work the same way. Each time a decision point occurs, which is any time an issue or opportunity arises, the team must use the constraints as the filter for the decision. They should also have a working knowledge of the relative importance of the constraints to the project sponsor. Making decisions based on an understanding of the impacts on the constraints and knowledge of the importance of each of those constraints to a sponsor, decisions can be easier to present to the project leadership.

Ride On, Manage On

Read more...

Flick of the Wrist, Getting Out of a Project Jam Quickly

I was on my way to work one morning and I had an uneasy feeling. I was coming up to the side of an 18 wheeler on the right and had a car on the left. There was a line of cars merging onto the highway and I could see their heads turning wanting to get out from behind the 18 wheeler as quickly as possible. I knew that my motorcycle was not visible to the people in the cars and I knew I had a decision to make. I could slow down to let all the bigger vehicles go ahead. The problem is that there was a load of traffic behind me as well and they don’t take kindly to motorcyclists slowing down. I could try to change lanes but there wasn’t anywhere to go. I chose to give the bike some gas, flick my wrist, and get ahead of all the traffic. Turned out that was the safest thing to do, my uneasy feeling went away and I was safely on my way to work.

If you’ve ever managed a project during a project traffic jam you may be able to relate to that uneasy feeling of not being able to get the job done. The traffic jam is usually caused by a constraint like not enough funding or resources. Each project has a similar need and each project must meet their objectives in a certain time period. And like morning rush hour, no matter how much contingency you give yourself, there is always something that can go wrong that is not preventable. This particular morning I had visibility of the traffic, I had an understanding of the traffic dependencies and I was able to make a decision to move quickly through the traffic.

Project Visibility

Being able to see the projects in an organization is critical to be able to understand potential impacts to a project. Since projects never operate in a vacuum visibility is a must. Visibility is caused through communication. Whether the organization uses standard project reporting using spreadsheets or a tool designed for portfolio management being aware of the active and the pipeline projects is needed. It doesn’t matter whether the organization is Functional, Projectized or Matrix. There are always limited resources and constant changes to the market, business priorities and strategies which cause projects to start and end. Because of this, the portfolio operates much like our highway system and projects operate much like the vehicles on the highway system. Some are large and take a great deal of effort to maneuver like an 18 wheeler and some are easier to maneuver like a motorcycle. The fact is that visibility must exist. Visibility is not built by an office but by each project manager making sure their project is visible to the organization.

Project Dependencies

Visibility is the first ingredient and dependency is second. Much like building a project schedule and determining task dependencies, projects have dependencies. Project dependencies can be based on a few criteria but the main criteria when discussing a portfolio are resources and funding. Since projects within a program are related it the capability or objectives of one project may need to be implemented before a dependent project can be started. In the case of the portfolio, the projects aren’t related so the dependency is usually people and dollars based. Understanding the dependencies is like understanding that none of the cars can merge safely until the 18 wheeler passes or that they can’t move into my lane unless I’m not in their way. Project dependencies help provide the basis for decisions.

Decision

In the traffic example I decided to “flick my wrist” and get away from impending doom. Being on a motorcycle, I could go from 65 to 75 to 65 in a matter of seconds. The decision seemed fairly straight forward. I would make a different decision if I were driving an 18 wheeler, a delivery truck, a pick-up truck, a luxury sedan and on down the line. When I hear someone say “It Depends” I usually feel like rolling my eyes but the truth is the decision made depends on the size and complexity of the project. The decision to gather the project team together, explain the convergence of the projects, discuss crashing the schedule and moving forward with the plan is the equivalent of “flick of the wrist”.

Additional Thoughts

It is very possible to achieve this type of quick response in a projectized, agile project management environment and much more difficult in a functional traditional project management environment. I’m not suggesting that we all adopt agile since the project environment will have all size and complexity of projects. I am suggesting that the decisions associated with project management must take into consideration many parameters.

“Flick of the Wrist” is only possible if there is visibility of the project portfolio, an understanding of project dependencies based on resources and dollars, and an environment in which quick response is possible.

Ride On, Manage On

Read more...

Project Management and Motorcycling

I started this blog in hopes of putting into words the wonderful similarities between project management and motorcycling. I began venturing into the blogosphere by putting my thoughts to the test. Since I’m a little behind the blogging curve (the world of blogging has been around since about 1994) I found myself trying to get a better handle of what sites exist for project management, agile project management, lean project management, and software develop in general. As I expected, the world is full of blogs for this purpose, some are award winners and some are, well, not. Needless to say, finding a voice in this blogosphere is a bit interesting. I won’t bore you with the details of getting this up and running (there are many sites about starting a blog). I will continue to venture into the project management and motorcycling realm, discussing the correlations that exist. For those that ride I hope to provide a perspective that is meaningful and for you that haven’t ventured onto a motorcycle, it may prove interesting since I will use examples from the road, and I’d venture to say that would include most folks. To keep things interesting, I’ll be taking a look at some of the other blogs, articles and books and let you know what I find. Hope to see you on the road.

Ride On, Manage On

Read more...

Project Management: Facilitation Skills

I was riding my motorcycle down a quite stretch of road on a nice sunny afternoon. The steady hum of the engine and the sound of the wind were muffled through my ear plugs. My brain was wandering off to dream world, not a good idea on a motorcycle, when a pothole jarred me back to reality quickly. I was jostled and my adrenalin pumped through my veins.

I’ve had similar experiences managing projects, things are going very smoothly, on time, on budget, with the agreed to scope, achieving the project objectives, when something “bad” happens. My primary analyst who’d been on the project since its inception has to quickly leave the country. This example of losing a critical resource is a risk on most projects. The risk is usually accepted (unless there is additional information that increases the probability since creating contingency plans associated with the more improbable risks uses valuable team time and energy. Having a risk management plan that defines the process to use when an improbable risk is realized is the simplest way to manage this type of an event. Whether the complexity and size of the project requires formal documentation or not, the project manager must be prepared to put on a facilitators hat when these types of events occur.

I started learning facilitation tools and techniques fairly early in my project management career and I’m grateful it worked out that way. I’d like to say I had a grand plan laid out to hone my project management skills but that isn’t the case. I wanted to learn how to run meetings better because of the time that was being wasted, I wanted to close open items sooner since open items chew up time and resources and I wanted to be able to manage the team effectively and efficiently. I believed that being a good facilitator and gaining an understanding of the associated tools and techniques would help in all of those cases.

I best course I took is Interaction Associates Essential Facilitation. I was able to apply the tools and techniques I learned right away in my project management job. I found that the meetings I had became much more effective and my ability to lead improved as well. The book How to Make Meetings Work by Interaction Associates founders Michael Doyle and David Straus has been an invaluable source of tools and techniques for continuing to develop my facilitation skills and as a gentle reminder of managing time wisely.

There are a host great facilitation methods and tools that provide project managers a wealth of knowledge for managing meetings, creating plans that work, making decisions, resolving issues and creating contingency plans for risks when needed. There isn’t a one size fits all when discussing facilitation techniques. Different teams need different guidance and the project manager must find the tools and techniques that work best for their team. Facilitation skills ensure that the project manager understands team dynamics and ways of dealing with time sensitive set backs or opportunities. Being knowledgeable in the field of facilitation is an important ingredient to project success.

Ride On, Manage On.

Read more...

Simple Tools for Complex Problems

One of the key ingredients in successfully managing a project is the ability to make timely and appropriate decisions. The projects that are the most painful are those where the decisions created the pain. Whether the decision was delayed, premature or non-existent, the decision caused the project distress. Making decisions requires a few ingredients. It requires an understanding of the question, available information influencing the decision and an understanding of the consequences, positive or negative, of making or not making the decision. Armed with this data and a process for making decisions, project managers and project teams can navigate the decision making realm.

A decision making process can be fairly straight forward and doesn’t have to take very long. A decision log can help track the decision that need to be made and those that have been decided, much like a risk or issue log. Tracking decisions is helpful. How many times have you heard “I thought we already decided that” or “I know we decided that, I just can’t remember why”. The mechanics aren’t as important as tracking that it was done. Simply put, the question that needs to be addressed is documented, possible options are identified, impacts of the options are determined, a recommendation is formulated, the decision is made and the consequences of the decision are tracked or monitored. The process is similar in nature to the Deming Cycle, a science experiment or an issue resolution process.

The tools for making decisions are similar to the tools used for process improvement or issue resolution as well. There is a great little book called The Memory Jogger. It contains tools for brainstorming, categorizing ideas, analyzing results and other capabilities associated with quality improvement. The book provides an easy to understand format for the use of the tools including the purpose, reasons to use it and the process of using the tool. Armed with these types of tools the decision making process can be straightforward.

There are some tools that aren’t in the memory jogger that I have found extremely helpful in making decisions. The main one is the four quadrants. Much like the quadrants of First Things First by Stephen Covey, the tool helps provide focus and narrows the options fairly quickly. It is possible to use the four quadrants by providing a two values for the x-axis such as easy to implement and difficult to implement and two values for the y-axis such as low cost and high cost. The diagram would look something like the diagram below.

The team would then place the ideas associated with the options in the quadrants, relative to the other ideas. This would quickly narrow the options that the team would review. This tool is a very simple to use tool and can be used whether the question is simple or complex.
The important aspect of making decisions is having a process to use. It helps maintain an objective rather than a subjective review and decision making process. It also will help put together information for others to make a decision with. Simple tools for complex problems helps to reduce the complexity and the risk.

Ride On, Manage On

Read more...

Project Management: Checklists

Project managers have a checklist for just about everything. There may even be checklists for making sure all of the checklists are done. The point of this is not to slam the use of checklists. My parents used checklists to pack for vacations, there are checklists for our cars servicing and I’m sure we all have started hundreds of checklists to remember our list of weekend “To Dos”. Checklists are a good tool and like other tools, we tend to over use them until we learn the strength and weakness of the tool. So it is for checklists in managing projects.

When I first took the Motorcycle Foundation Safety course we were first taught using a couple of checklists. The key ingredient to teaching the use of the checklist was to help us understand the purpose of each component so that when it was checked we had knowledge behind why it was on the list. Having a checklist isn’t the key, having an understanding of what is getting checked, the purpose of the action item, is the key. Knowing why an item is on the checklist will help determine whether or not the work is actually completed and completed at the right time.

I actually like checklists, checklists give me a sense of security. Being able to check off a list of actions can give a sense of accomplishment. The sense of security and sense of accomplishment can be deceiving. Just because it has been checked off doesn’t mean that the appropriate work has been done. We had pre-defined checklists when starting our motorcycles, these pre-defined checklists are what cause problems for projects and project managers. Learning to manage a project through the use of checklists is helpful but, checklists won’t be the answer to managing projects. It is like doing risk identification once in a project, you can check it off your list when you finish the risk identification, the problem is that risk identification is never “done” and is needed throughout the project life cycle.

Checklists are designed to help reduce risk, the risk of missing something that is important to a project. That makes a checklist a useful tool. I’ve been most successful with a checklist when I’ve used a pre-defined checklist as a starting point and addressed each item on the list in some way. I’ve asked the simple questions of who, what, when, where, and how to each item so that each item was well defined, was questioned each time and then addressed as part of the project. Checklists don’t replace knowledge, experience or understanding. Using them blindly will not improve delivery, it will hinder delivery.

Checklists are friend and foe, strength and weakness, useful tool and an anchor around the neck of the project manager. They should be used wisely. If you are new to project management be aware that every problem is not a nail and a checklist is not a hammer. It is simply a tool to walk through the questions of who, what, when, where, and how for an item that must be done. Remember that many of the tasks that are part of managing a project are recurring and on-going. Many of the project management activities aren’t complete until the project is closed. Rely on the project team to build checklists and use them to ensure the completion of agreed upon work that is to occur once in a project. Otherwise, everything will be a checklist.

Ride On, Manage On.

Read more...

Project Management Focus

There are few things that matter more in project management than focus. The areas to focus on include objectives, team, stakeholders, outcomes and many other project variables. In fact, there are so many areas that it can be difficult to decide which area is most important and the most important area can be different depending on the project and can be different depending on where the project is relative to the delivery life cycle. It is also important to remember that the project will go in the direction that the project manager is focused. Let me elaborate. When the project manager is focused on risks then the project will be about the risks, when the project manager is focused on resources then the project will be about resources, when the project is focus on metrics then the project will be about metrics and when the project manager is focused on outcomes then the project will be about outcomes. The project manager focus creates the project focus.

Methodologies are created to help teach project managers when to focus on certain areas or aspects of the project during the project life cycle. A methodology suggests that during the initiation of a project the primary focus is on the stakeholders and scope and during the planning the primary focus is on the team and schedule. The other thing that a methodology provides is a specific language for the various areas or aspect of the project life cycle. Armed with the “what to do when” and a common language, project managers set out to deliver a successful project. It would be great if it were that easy. A project manager could use the right language and check off whether the work that should be done is done during the right portion of the project life cycle. A checklist here or there would be all that is needed. We all know that it just isn’t that easy. Checking off whether something has been done is not the same as providing the right focus at the right time.

It is true that stakeholders have a primary focus during initiation, they have to be identified, their needs have to be captured and they have to become engaged. The project manager must maintain enough focus on the stakeholders throughout the project so that they stay engaged. Missing a stakeholder causes problems in most projects, losing one can cause a similar problem. The project manager must focus on developing the right schedule during the planning phase and must maintain enough focus on the schedule so the project stays on track. Staying focused on the schedule may mean a project delivered on time but it doesn’t mean the project is successful. Focus must move fluidly like the waves of the ocean. A successful project occurs when the project manager changes focus based on the project need.

The primary focus of all project delivery, from initiation through close, must be on the business benefit seen through the lens of the project constraints. There must be a balanced focus, primarily on the benefits the project is to deliver, without ignoring the constraints of the project. When the focus is only on the constraints the opportunities may be lost and when focused purely on the benefits the constraints may be forgotten. This balanced focus for all activities provides the right view into who needs to be engaged, what needs to be delivered, when the work needs to be done and how the work needs to be done. This balance can provide the project manager the right focus for project success.

Ride On, Manage On

Read more...

Projects Need Slow To Go Fast

If you’ve ever watched a tennis tournament like the US Open or a golf championship like the British Open you’ll notice something very important. Each and every player takes time before they take their swing or serve the ball to think through what they want to accomplish. The tennis player bounces the ball before the serve and the golfer takes a few practice swings. They aren’t focused on the amount of time that passes but are focused on the end result. Projects, like tennis and golf, need that same deliberateness, projects need the appropriate time and thought before the start of activity. Project managers must set project activity up for success before starting, that doesn’t mean once, it means throughout the project. Project managers must be deliberate in the time that they take for project success.

When discussing Agile Project Management it becomes clear that there is a point when the project slows, it doesn’t stop, it slows. At the end of an iteration, which occurs every 1 to 4 weeks, there is a retrospective or, more simply, a review and planning period. The team, in conjunction with the client, reviews the completed work and plans the next iteration. This is the place where the player bounces the ball or takes a few practice swings. There is also a discussion of what went well and what needs to change during the next iteration to improve the process. Having grown up in a traditional project management world it seems strange that this seems new. While the duration of an iteration is fixed and agile adapts easily to such a process, most projects benefit from this type of review and planning. There isn’t anything in any traditional methodology that prevents project managers from using a similar construct, no matter how long the project is. Agile also suggests daily stand-ups, another way to take some time to see how things are going. While traditional project management says little about daily stand-ups, employing daily stand-ups doesn’t go against traditional project management methods.

Project managers are challenged to go beyond checklists, templates and tools to be successful. They must employ techniques to allow the project to recalibrate, rejuvenate and recharge when the project is challenged by difficult stakeholders, unclear objectives, new technologies and changing priorities. These challenges will occur on every project in some way. Creating a moment in time for the project team to pull together and plan the next “point” is one of the most important things a project manager needs to learn how to do effectively. Using an Agile construct like the retrospective or the daily stand-up allows project managers and team members time to breath, time to think through where the project is headed and time to make better decisions. Projects, like tennis and golf, need to slow down just before the activity starts so there is clarity and deliberateness to what they are doing. Delivering a project quickly, requires moments of slowness.

Ride On, Manage On

Read more...

Slow Can Be Good When Managing Projects

Moore’s Law, although focused on the integrated circuit, can be generalized for other technologies. The law, established in a paper in 1965, suggests that the rate of change in processing speed of the integrated circuit doubles every two years. The digital age has made it possible for many technologies to advance at roughly this same exponential rate. While Moore’s Law is technology based it has been generalized to show the exponential rate of change within business and businesses have been trying to keep up with that rate of change ever since. We continue to evolve our management practices recognizing that change is inevitable and that change will continue to accelerate as technology drives us forward. While it is critical to “keep up” with the rate of change it is also critical to learn when and how to slow down long enough to ensure we are spending our limited resources on the right work at the right time. Slow is a tool that needs to be used regularly to gain perspective.

In my last post I presented the Slow, Look, Lean and Roll mantra of cornering in motorcycle riding. This tool is used to corner efficiently and safely. The idea is to slow down prior to entering a corner retaining enough speed to increase speed throughout the turn. When you slow down too much you risk losing momentum and when you don’t slow enough you risk losing control. While neither one is favorable, losing momentum is less disastrous than losing control. Project and Program Portfolio Management provides an organization the opportunity to slow down to ensure they can navigate through the next curve.

When discussing IT project delivery the “next curve” can be anything from a new version of an existing package to a new business opportunity that requires technology to support it to new technology that can change the businesses competitive advantage. Whether it is technology that maintains a business’s current position by providing basic needs, keeps a business competitive by staying in line with the competition or provides the business the ability to differentiate itself in the market place, taking the time to review the portfolio of projects in flight is not only necessary, it is a strategic move. Learning how to slow down enough to maintain momentum and ensure safe navigation of a turn is a skill that must be mastered.

We have learned to start better than we have learned to stop and we are focused on accelerating more than we are focused on when to slow down. A person learning how to juggle is focused on the catching of the ball rather than focused on the tossing of the ball, a person learning how to ride a motorcycle is focused on going more than focused on stopping, and a project manager learns how to start a project much sooner than they learn how to stop a project. We are focused on making things go which is understandable. Having active projects provides a sense of accomplishment, moving feels better than stopping, especially if you are stopping before you’ve finished your project. It is clear that taking time before moving forward, to think things through, to plan the curve, is important. Otherwise tennis matches, golf tournaments, and other sports would move a lot faster. There are time outs for a reason. Slowing down, taking a breath, and squeezing the breaks allows time to make good decisions. Losing momentum is not the right answer, going into a curve too fast is not the right answer, becoming skilled at slowing down at the right moment is the answer.

Ride On, Manage On.

Read more...

Simple Is Not Easy When Discussing Project Management

It was sunny, in the 70’s, and I was riding on some quiet back road near home. The bike was riding smoothly over the small hills and I was relaxed. I was coming to a familiar curve so I slowed, looked through the turn, pushed on the bar to lean the bike and slowly increased the throttle. This is the text book process for negotiating a corner or turn on a motorcycle. The mantra we are taught is slow, look, lean and roll. It is a simple process and will work every time. It is critical to slow down enough for the type of turn being made. Once you are in a turn on a motorcycle you must continue to slowly increase your speed to maintain traction. This is the part that isn’t so easy, especially when you start the turn with too much speed. The natural instinct to slow down when you are going too fast will lead to disaster on a motorcycle. Increasing speed to increase traction is simple, it isn’t easy. Just like cornering a motorcycle, the project management process is simple, it isn't easy.

Every person manages some project in their life time and probably manages their daily lives much like managing a project. The process can be expressed in a simple manner. The fundamental process flows something like this:

1. Identify the problem or opportunity
2. Determine what is needed to solve the problem or exploit the opportunity (scope/requirements)
3. Create the plan for achieving the need outlined in step 2
4. Execute the plan
5. Make sure things stay on track
6. Check to see if everything was completed

It doesn’t seem very complicated and is pretty straight forward. So why isn’t it easy? The answer lies in two dimensions. The first dimension is the selection of which items to move from step 1 to step 2 and the second dimension is everything that can go wrong (or right) from step 2 to the end. In project terms these two dimensions are known as Project Portfolio Management and Risk Management. Organizations lose traction when the right opportunities or problems are not effectively selected and projects lose traction when risks are not effectively managed during project delivery. Effective selection of projects and effective management of risks follows the same model as turning or cornering in motorcycling. Slow, Look, Lean, and Roll.

In motorcycling, each word holds significance to maneuvering a bike effectively, efficiently and safely. Each word has a specific purpose and must be done in order. Slowing first allows a motorcyclist the time and space needed for the other three tasks. Looking through the turn sets the motorcycle in motion to change directions, a motorcycle goes where a motorcyclist is looking. Leaning the bike through the turn and then increasing speed to maintain and increase traction through the turn. When these are done out of order it can end in an accident. It is important not to slow a motorcycle when it is leaned over in a turn. The bike will lose traction and will go down. When a motorcyclist doesn’t think they can negotiate a turn that they have already started they are taught to increase speed and increase the lean to maintain and increase traction while turning more sharply.

This model works for Project Portfolio Management and for Project Risk Management. In the next few posts I’ll present the model for both. This simple mantra will assist organizations and project managers remember that simple is important to ensure adoption and simple doesn’t mean easy.

Ride On, Manage On

Read more...

Project Failure or Portfolio Failure?

Successful projects are hard to achieve. That was true when The Standish Group, West Yarmouth, Mass., a research firm focused on project management first published their findings in 1994 and is true in their 2009 report. Project management organizations and certifications have been in place longer than these studies and have not been able to break the simple truth that projects are challenged or fail more often than they succeed. As a matter of fact the 2009 news is worse than last year. This news isn’t about project failure, it is about an organizations ability to select projects that will succeed.

"This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions" says Jim Johnson, chairman of The Standish Group, "44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used."1

Project managers and their organizations continue to work to move toward more project successes, fewer challenged project deliveries and an overall reduction in project failures. We have evolved from project management to program management to portfolio management. We have discussed a traditional approach to projects (waterfall), an iterative approach, agile and lean. We’ve employed Six Sigma, TQM, CMMI and other process and quality tools to increase quality of delivery. We are diligently working to solve the problem of project success.

We compare IT delivery to building bridges, building homes and other visible, tangible projects and hope to find answers. We won’t find the answer to successful IT project delivery through those comparisons until we find the answer to a couple of fundamental question. We first have to answer the question of accountability. Is the project manager accountable from inception of an idea to delivery of the idea’s solution? When we answer that question we then need to determine the project boundaries. When do we start measuring a project to determine whether or not it succeeds or fails? Again, if we look at a project from the inception of an idea to the delivery of the idea’s solution then we will be looking at a much larger number of project failures (cancelled projects).

It isn’t a surprise that the numbers of projects that are challenged or have failed have increased. In today’s economic climate the number of cancelled projects has increased and there are fewer resources to do the same amount of work which will cause projects to be challenged. In reviewing this information it becomes clear that there is a gap between measuring project success and measuring project management success. The project manager must be held accountable for the results of project success, failure or challenge and project management methodologies, techniques and tools must provide the guidance needed for successful delivery. The simple truth is that organizations must include portfolio and program management to create an environment for successful project delivery. Organizations cannot have successful projects if they are not set up for success before a project manager is assigned. The project manager builds software. Organizations must plan what is to be built based on organizational strategy through a portfolio view. The Standish Group study reveals more about portfolio management than project management.

Ride On, Manage On
The Standish Group. 21 April 2009. http://www1.standishgroup.com/newsroom/chaos_2009.php

Read more...

The Art of Simple in Project Management

Project management is simple. That doesn’t imply it is easy to do nor does it minimize the value it brings. Keeping project management simple is what brings the most value to any organization. When a project requires complex project management processes to keep it on track it may be too large. The project management processes should remain simple and projects should be framed to be managed as simply as possible. Organizations are filled with processes that have been built to take into account everything that can go wrong with a project. The processes are built for the exception rather than for the average or norm. Building processes based on what could be called the “happy path” will maintain simplicity. Teaching project managers a standard way to handle exceptions is far more valuable than building a process to handle all the possible exceptions that can occur.

The driver behind all the reams of paper, checklists, processes and complexity is fear. Fear is understandable in the world of project management. More projects fail than succeed so why wouldn’t you ensure you have all the “I”’s dotted and “T”’s crossed? The only thing that all the “I” dotting and “T” crossing requires is time, so why not spend the time? The problem is that time costs companies a large amount of money. The litmus test for creating documentation of any kind is whether or not it will be used for any reason (formally or informally), and whether it adds value to the organization. It is true that we don’t always know ahead of time what information will be needed a few days, weeks, months or years down the road. Is the possibility that information may be needed any reason to create documentation that may never be viewed again? Are we creating all of this paper to prove that we are doing our job or because the project will be more successful because the paper exists?

Traditional project management for software development has always struggled to prove that work is getting done and value is being created throughout the project life cycle. Questions such as “What do you have to show for all these weeks of work?”, “When will I see something concrete?”, and “How much more time and money is it going to cost before I get some results?” from clients are valid. Project managers must challenge themselves to see project management from the client perspective. Project management must be kept simple. Having project management activities appear complex does not create respect nor does it increase the value. Project management is respected when it can make project delivery easier for teams and organizations and that is only possible when it is simple.

The primary driver in keeping project management simple is trust. Developing the level of trust necessary requires rampant communication. Creating rampant communication is possible when project managers embrace the value from the Agile Manifesto, “Individuals and interactions over processes and tools”. This value is for all types of project delivery and should not be relegated to agile delivery. Project management communication must be transparent. It must provide a window into the true performance of the project. The project manager must be fully accountable for all aspects of delivery, not sort of accountable. The good, the bad, and the ugly must be visible to the entire team, from the sponsor to the client, from the analyst to the tester, from business to IT. The simplicity of project management is found when the degree of project team work is in direct proportion to the business benefit the project provides.

Ride On, Manage On.

Read more...

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