My parents live in Louisiana and unfortunately got hit hard by Hurricane Gustav a few weeks ago. Their home was damaged by a very old very impressive tree, and a long-time family lake house was so badly rain-damaged that gutting of the entire place was required. The three weeks after the storm reminded me strongly of what teams at the beginning of a particularly difficult project often face: and tools I’ve used on my projects to counter the issues.What could a hurricane-recovery project and our difficult corporate projects share in common? Picture a team facing and huge tangle of mess, feeling rather helpless as they look at the pile and wonder where to start and what will become of them as they wrestle with that mess.
This is literally how my parents felt those first weeks as they dealt with storm debris everywhere, worried about how to get an 80 foot tree off the top of the garage, and scrambled to get to the lake place and its furniture before any more rain hit, before mold formed: Truly a mess of an undertaking. And they experienced huge angst as they wondered and worried. Overwhelm, dread of the unknown, the seemingly huge size of those first steps, all the questions. How long will we have to wait to wait for the insurance people to show up? Will they pay adequate money for the damage? Will we have enough cash for our share? What do we do with all this furniture? How do we keep from being gouged by contractors? How do we decide whether to rebuild the lake place? Many, many unknowns, some complex interactions among decisions, not to mention a whole bunch of work they weren’t counting on having to take on. Lots of questions, lots of anxiety, and understandably so. But no way to get around the uncertainty, all they could do is start dealing with the questions and issues. But tied up in tight stressful knots from worry about what they didn’t yet understand, it was a recipe for a very unpleasant project experience.
I’ve actually experienced this same effect with project teams during the fuzzy front end of major projects, and more so as the years of my career have gone by. In my early project days, things felt very orderly and downright leisurely. “Here’s the spec. You have x months. Go do this design.” Fun creative time in my cube with a few reviews here and there. What could be better for a project team member?
Fast forward a few years and the front end of my projects felt very different. So many constraints! Time, money, people all incredibly limited: but of course the requirements lists were never constrained, the customer wants the world. The early days of major projects could get really stressful. How to make our way through this tangle of decisions? What CAN we get done by this aggressive deadline? How DO we meet these cost targets to make the product profitable enough, without taking on too much risk? What can we really commit to here? What gotchas may we hit along the way?
I have seen team members experiencing just as much angst as my parents over their hurricane project, especially those who came from my background where we THOUGHT we were just going to get to work on fun stuff in our cubicles with other people making the tough tradeoff decisions. The constraints are so tight and complicated, though, we often need everyone participating in investigation, alternatives analysis, and trade-off decision making around project goals and implementation options. Sounds reasonable: but that doesn’t mean our team members want or like that unexpected stress!
So how do we lead teams through this uncertainty and take the edge off the angst? I got a reminder from my hurricane experience as I watched my parents start to feel better once the first few steps were taken. “OK, got in touch with the insurance people. They’re not here yet, who knows when they will be, but at least we got to the right place. OK, now we’ve found a guy with a crane to come get the blasted tree off the garage. That’ll be done by Friday. OK we got a tarp on the roof at the lake so no more damage as Ike comes through: .” My parents felt better when they could see at least partway down the path and see that a few concrete steps had been accomplished, and increasingly get a sense of the possible timeline for full resolution. (Notice I said a sense of the possible timeline: still uncertainty but not as stressful.)
I think this works for our teams too. I realized I use project tools to create a frame for the fuzzy front end and pace and acknowledge progress through the mess. I do a lot of this in a big kickoff meeting with the team:
– I have the team create a project vision together on flip chart paper on the wall, a 1 to 2 page document that expresses the reasons for doing this project and the most important value to deliver to its customers: and set the expectation that we will focus on that value to guide our decisions. Why does this help? In my experience, if the only thing you show the project team members is a really detailed spec, with everything seemingly weighted the same and a really long, hard-to-process list to boot, it is way more overwhelming to think about making decisions about and among requirements. Two pages with guiding principles make it seem simpler.
– We brainstorm a list of already-worrisome issues and prioritize them for attack, with team discussion about why a certain issue needs to be tackled earlier than others. (They’re there, might as well get them out.)
– We brainstorm a list of implementation suggestions and questions that are already forming in people’s minds. (Half the team is already designing the solution in their heads anyway, possibly prematurely. Get it on the table, we’ll need the info anyway, for the next step in the kickoff meeting…)
– We identify possible project alternatives people are already seeing or wondering about. Hey, we already know that feature X is a killer time and risk wise. Is it an option to leave that out? Is that an option we’d want to pitch? Make it alternative B. Hmm, is the end-date flexible? We already know about some new stuff coming onto the market that we could use on our project, but to use it and save ourselves that resource time, we’d need to adjust the deadline. Let’s make that alternative C. I don’t think I’ve ever held a first kickoff meeting where these kinds of tradeoffs weren’t already on people’s minds. Great! Let’s capture them and discuss; and we’re already hacking through that impenetrable forest! We create a tradeoff table with each alternative forming a column and rows for possible customer satisfaction, scope, schedule, risk, cost, and other implications of each alternative.
– We come up with a desired date for ending the initiation (kickoff) phase. (At the end of this phase we want to have reached decisions on mandatory scope, approach to the project, and its budget and schedule. Even if I’m taking a more agile approach with iteration cycles, I have some high level requirements and architecture and initial investigation time like this up front to set the stage appropriately for the subsequent iterations.)
– Then we map backwards from that date and define some investigation iterations. What’s the first step we need to take? I.e. what project/product/system/etc. alternatives do we need to look into first for feasibility? What “big ticket” decisions should we try to get to first and what will it take, like getting particular executives’ OK? We set targets for interim reviews and decision making to slowly take steps and work off the uncertainties.
– Then as we proceed through the rest of this phase, we keep the issues and questions progress very visible. Record the decisions, mark off the issues. People keep being reminded of how far we’ve come through the forest, how much tangled string we’ve unraveled. (And we have a record of path and all the decisions, too.)
So these are key techniques I use. Why does all of this help? In my experience, it simply gives some structure to tackling the unknown, making it all feel less tangled and inscrutable and intimidating. “Oh, ok, we don’t know all the answers yet but I can kind of see how we’re going to work through this piece by piece: and I get what part I have in supplying information into the decision-making process.” The fuzzy front end isn’t so fuzzy anymore! And thus the difficult, complicated, and even emotional aspects of the front end don’t seem so negative anymore to the people who have to go get it done. And of course it gives a pacing through this time, rather than leaving a big blob of time for “investigation” with little assurance that what you need will come out at the end.
Working with my parents reminded me of how important it can be to shine a light on a possible path for our team members, especially on difficult, twisty, uncertain projects. It provides clarity at a challenging time, it lessens the stress of the unknown, and it helps the team get where it needs to go in a timely manner, and in the best possible frame of mind.
Cinda Voegtli
