what we learned as children we should use in projects
Much of project success stems from how we learned to play games when we were young.
by Neal S. Gray, PMP
IT MAY BE HARD TO ADMIT, but projects are just an adult version of the playground games we played as children. I was sitting in my car watching my 5-year-old son playing with a bunch of other children on the playground. As I watched, I noticed two things: First, everyone appeared to be having a good time laughing, running, bouncing a ball, chasing, falling, and laughing again. The second thing I noticed was that I couldn't tell what the rules were, but these children all seemed to understand them.
Off to the right was another group of pre-school-aged children, but something was different. They were not having any fun. In fact, they were yelling at each other. From the few words I could hear coming across the field, it appeared that the little boy who was clutching the ball tightly was trying to make up new rules in the middle of the game that would be more favorable to him (or his team, I wasn't sure). The other children were yelling that he couldn't do that. Some sat down and refused to play. Others stomped off mad. Eventually the boy with the ball left with the ball and the game was over.
Turning back to the first group of children, I saw that they were still playing happily, but it was time to go, so I honked the horn and waved my little boy over to the car. Once my son got into the car (which took a while since he didn't want to stop having fun), I asked him what he was playing. His response, “Just a game, Dad.” “Who was winning?” I asked. “Everybody!” he answered with a smile on his face. What a contrast between the two games I had watched. And then the parallels to projects began to hit me.
No matter how sophisticated the project, much of project success goes back to how we learned to play games when we were on the playground back in our youth. Projects that don't have their playground rules established beforehand won't go well. Not that playground rules make all problems go away, but they do set parameters and guidelines when issues come up. In projects we use the project charter and the statement of work to write up our playground rules. Let's look at why playground rules are so important for project success.
Agree on the Rules of the Game. If we can't agree on the rules, then the game either won't last very long or will go on in chaos far longer than it should. Games have rules to prevent arguments before they happen and to give guidance when arguments do happen. Rules provide a sense of fairness to all the players. There is also a secure calming feeling for most people when they know the rules before they begin playing. Projects are much the same. If rules are not set before the project begins, it will either crash in failure quickly or ramble on in chaos. Some project rules include what's the scope, what are the risks, who will be contributing and doing what, and how do we know when we are done?
Neal S. Gray, PMP, is a senior principal consultant with Keane Inc., a software development and consulting firm. He has been involved in developing software applications for over 20 years, and is currently an international seminar leader in the areas of project management, estimation, risk management, and project manager competencies.
Decide What Is In-Bounds and Out-of-Bounds.
I can remember playing basketball on a friend's back driveway. There was a basket hung on the front of the garage, grass on two sides of the driveway, a flower bed in one corner, and the driveway went along one side of the house out to the street. The grass and the garage wall were out-of-bounds, as was the driveway that went along the side of the house. The flower bed was not only out-of-bounds, but if you were responsible for damaging a flower with the ball or your foot, then you would also get punched by my friend for “damaging Mom's flowers.” Everybody knew and understood the consequences of out-of-bounds. If you didn't like the rules, you could just sit and watch from the sidelines. If you wanted to play, you followed the rules. From a project point of view, this is a scope issue, with associated risk management and consequence. We need to be very clear for both the project team and the business customer as to the boundaries of the project. Setting initial agreed-upon boundaries is the first essential step in controlling scope creep, budgets, and schedules.
If Anybody Has to Go Home Early, Find Out Before We Start Picking Teams. Leaving early could easily change the balance of power and fairness in the game. If you knew that you had to go home early, you needed to declare that knowledge. Usually this was factored into how the players were picked or at least led to a brief discussion about substitute players. A key player leaving could change how the game was structured. Projects are the same. It is vitally important to understand any and all known constraints before the project is structured. This will help minimize surprises that can be managed from the beginning and help to better understand what can and cannot fit into the project scope.
Decide What Determines When the Game Is Over. Understanding how the game ends is always important. Do we play for a set time and then stop? Do we play until so many points are scored and the first team to earn that score wins? By establishing what determines when the game is over, you are setting goals and expectations, you are agreeing on acceptance criteria. Children and adults need to know what the goal is and what they should expect. Many projects never really know (or soon forget) what the goal really is. Without a goal there is no focus. Without focus there is no win. By establishing the goal and how we know that we have achieved it, we know whether or not we really want to play the game or do the project. It is critical to a successful end game that both the team and the business customer not only understand but also agree to what done means.
Be Nice. We preach this to our children and then forget it on the adult playground called work. When people treat each other “nice,” games and projects have fewer arguments and problems. This leads to more fun. When people are having fun, they are usually more willing to play harder (work harder) to win. Consider this: Projects do not succeed or fail; people do. Be nice to the people in and around your project and you will increase the chances of success because people like to go the extra mile for those who are truly nice to them.
Look Both Ways Before Chasing the Ball into the Street. In the course of a game or project, we often get so focused on winning our part that we forget to think before we act. For children, you see them chase a ball out into the street without looking both ways because they are too focused on one small task—get the ball. If they are lucky, they get the ball and the game continues. If they are not, disaster strikes and the game comes to a sudden end (and for what? … a ball?). For adults, you see them chase a pet project or a project that is already in the budget and “go for it” regardless of whether the economics or logic of it make any sense. “We have to continue the project. It is already in the budget and we must spend all our money this year if we hope to get more for next year.” We get so focused on the doing that we often forget the goal of the game. Is the goal just to “get the project done” … or is it something more meaningful to the organization?
Share. Most games are not won by having one superstar. Usually it takes working together with a common goal. Projects are the same. Finger-pointing is meant to lay blame. Games are not lost just because of one person or one coach. Projects are not a success or failure except that the people involved together are a success or failure. Risk is not mine vs. yours, but ours to manage together. If we share the work, the risk, and the management, we can share the reward. I am not suggesting communal management, but sharing in managing and controlling those things that each of us has better authority over.
Don't Leave the Play Area Without Permission. Knowing the boundaries of a game or project scope is very important. For safety reasons, parents do not want their children wandering out of the playground without permission. For budget and timeline reasons, managers do not want their projects wandering out of the agreed-upon boundaries without permission. When players wander to where they want to go vs. where they should be, chaos quickly takes over. Managers and parents get angry and scared when they lose control. If everyone understands the need for getting permission first, and follows that rule, control is better maintained.
Stop, Drop, and Roll. Risk-mitigation planning is often set aside because managers don't believe something bad will happen to their project or else they “don't have time to worry about it.” If we really don't believe that our children will ever be on fire, why teach them to stop-drop-and-roll? Because even though the likelihood is small, the consequence is extreme. Therefore we invest in this simple effective risk management technique. Many risks are more likely to happen to our projects than our children catching on fire. Why then do we spend so little time on risk mitigation for projects? Most common reasons I have heard include not enough time, not enough information, and nobody wants to hear the negative stuff. If we don't have a mitigation plan in our projects before the fire, we will run around in a panic, fueling the flames rather than being prepared to stop, drop, and roll when fire hits our project. Just as we do with our children, let's spend a little more time upfront with our projects, discussing potential risks and devising a plan for managing the most likely or most devastating risks.
Can There Be a Winner? We all hope the answer to this question is yes. But just because there is a winner, that doesn't mean someone else must be a loser. In the game of projects, winner means that the project team and business customer both believe that the project has useful goals and is going about getting to the goals in a way that is reasonable and realistic for both. In fact, if the team believes that the project is reasonable and realistic the team will be more likely to put more time and energy into doing what has to be done. When people see a project as doomed to fail, they will not put forth the extra effort to try and make it a success. If the business customer believes that the project is reasonable and realistic, the customer will be more likely to make it happen through support, commitment, and resources. If both sides do their part, there will be a stronger feeling of winning for each side. This winning feeling can happen even if the project is somewhat over budget and behind schedule (although on time and on budget would be icing on the cake).
Have Fun. I believe that this is one of the best project motivators, yet it is the least remembered by project managers, business customers, and teams. If the game isn't fun, it isn't going to be played with as much energy and enthusiasm. Projects that have little or no energy and enthusiasm are not likely to be completed on time and on budget since the players aren't contributing at a level that elevates the likelihood of success. This isn't to say that projects should be all jokes and laughter—real work needs to be done. But we have to remember that basic human nature craves enjoyment and fun in the things we do. Too often projects are filled with disagreements, demands, counterdemands, and beating each other over the heads with missed budgets and schedules. I don't know about you, but that doesn't sound like fun to me. Working together to establish mutually agreed-upon rules of the game and then following the rules will go a long way toward making projects more fun.
Will There Be a Referee? In other words, is this project more like a playground pick-up game or is this being played in the big arena for the championship. Smaller projects for internal use that have been designated as nice-to-have-but-not-critical can usually be established with rules that require fewer rigors. Big projects with higher risk and bigger budgets will most likely require more formal policing and control. This comes down to how formally the project charter and statement of work need to be detailed. On smaller projects the charter and statement of work may only be a couple of pages long. A multimonth project will require a more comprehensive set of documents. These documents detail the agreed-upon work (and rules) with formal change and acceptance procedures, as well as designated individuals with authority to sign off on changes and completions. This agreement establishes who is the referee so that the project can move along and reach a successful end of game. Can you imagine what a professional sports event would be like if there were no referees?
IF WE WANT EVERYBODY to “play the game” of projects so that we all can get along and win, we must work together to agree on playground rules before the game begins. These playground rules are established in the project charter and statement of work. Projects are adult games, and adults don't like playing unknown games with unknown rules any more than children do. If we want to minimize the crying, yelling, and people quitting the game to go stomping home, we must establish our playground rules, get everyone to commit to those rules, and then play the game by the rules. If you do this, you too may be able to answer the question, “Who was winning?” the same way my 5-year-old son did: “Everyone!” ■
Reader Service Number 102
September 2000 PM Network