Friday, October 2, 2009

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

Thursday, October 1, 2009

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

Wednesday, September 30, 2009

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

Tuesday, September 29, 2009

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

Monday, September 28, 2009

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