Tuesday, March 30, 2010

Getting Results

I came to Getting Results with a history of effectiveness and success. I had a solid sense of what I felt were the best ways to get things done, a set of process and principles that had worked well for me over many years. I am a process guy, a details guy and a lover of great strategy. I sweat the small stuff and I look at the big picture in order to guide myself and my organization to maximum results. Then I met JD...

I started with JD on a project to build security guidance for the ASP.NET development platform. A huge undertaking that involved discovering, consuming, and analyzing a huge amount of information from a huge amount of sources both written and verbal and then turning that into specific, contextual, prescriptive guidance for Microsoft developers. The goal was nothing less than to change the way in which web applications were written on the Microsoft platform. In order to make consumers more secure, the applications needed to be more secure. In order to make the applications more secure, developers needed to know what to do. That's where JD and team came in. What I saw in the course of this project, changed my view on how to get things done. JD accomplished what seemed impossible. In too little time, with too little resources, with a staggering amount of chaos to deal with, JD coaxed the team into writing a masterpiece. I couldn't see how it was done, but I was curious. Luckily for me I had the opportunity to work with JD on a number of other projects over the course of several years. I learned the process as it was developed and maybe even had a chance to contribute to it a little here and there. Whether I had any impact on it or not, it had a huge impact on me.

Before I explain what I learned, I want to set some context to explain how I used to get results. I was a huge believer in up-front planning. For a new project I would spend a lot of time designing and planning what needed to get done, how it would get done, when it would get done, who would do it and in what order. I was a master of this style. I could plan a complex project with a dozen team members and have an 18 month plan with all of the tasks laid out to the day and then we could execute to that plan so that 18 months from the start we had accomplished exactly what I had laid out at the start. Impressive right? Well, not really. I learned, the hard way, that I was focusing on the wrong things. I was focusing on tasks and activities. I was focusing on what got done, which I thought were the results, but I was neglecting the real results. Most importantly, I had the wrong assumptions. I assumed that a rigorous planning process could remove risk. I assumed that I knew up-front what I wanted to accomplish. I assumed that my plan was helping me when it was actually a prison.

So what did I learn from JD and how did it change how I do things? What kind of a difference did it make? Here are the key lessons I learned, my most important take-aways:

Focus on scenarios and stories. I'd always used scenarios and stories as a tool, but I hadn't used them correctly. They were something I considered, they were an input to my plan, just one more thing that mattered. What JD taught me is that they are the only thing that matters. If you get this one thing right you win. If you get it wrong you lose. Planning should be about determining the right scenarios and stories you want to enable. Execution is about making these scenarios and stories real. You know you are done, you judge your success, by measuring against these scenarios and stories. Everything else is a means to this end.

Expose risk early, fail quickly. Planning is an exercise in risk discovery and mitigation. You plan so that you can create a path to success while imagining the pitfalls and avoiding them. Planning is a mental exercise, it is not doing, it is imagining. JD helped me realize that the world is too complex to plan for every possible problem and it is too complex for you to be able to plan the best possible path. I learned that I should be exploring and optimizing as I go instead of trying to do it all up front. If the price of failure is not extreme (lost lives, destroyed business) and I can afford the exploration, I discovered I am better off reducing my up-front planning and jumping into the 'doing' sooner. By 'doing' I can expose risks early and I can determine if my chosen path will fail so I can pick another. I think JD calls it "Prove the Path". I like to think that mistakes and failure are bound to happen and I'd rather discover it fast while I have the chance to correct than discover it too late when I'm over-committed.

Ruthless effectiveness. I thought I was ruthless already. I thought I went after results like a Pit Bull and didn't let go till I'd chewed it to a pulp. I was right, but that's not the most effective path. Ruthless effectiveness isn't being a Pit Bull and never letting go. Ruthless effectiveness is knowing when something is good enough and knowing when it will never be good enough. Ruthless effectiveness is learning to let go. I am a perfectionist, I like things to be more than good. I want them to be great, exceptional even. I can forget the rule of diminishing returns once I have my teeth into something. JD taught me to let a project go, to ship the book, to release the software when you've maximized its value and when it will make the most impact. Let go when there are external reasons to let go, don't let your own internal attachment cause you to hang on to something too long. It felt crazy to me when I first saw it, almost irresponsible. But it works. Its a ruthless focus on results. Nothing personal.

I'm sure your take-aways from Getting Results will be different from mine. We are all different, have different goals and are all in different places in regards to our abilities and motivations to be effective. There is so much in this guide, it has so much to offer, that I think anyone who reads it will get something out of it. If you are lucky, it may even change your life like it did mine.

After a painful year and half R&D project in the semiconductor industry I learned a few of my own lessons about project planning. This comment isn't meant to be inclusive of best practices, just a few highlights I found interesting.

First, don't over consider the deadline when writing your schedule. You can reconcile the deadline with your project plan after the initial planning. It's more important to realistically determine how long a project will take than to over commit.

Second, if you and your team are dependent on work from others to complete the project, get together with every other functional area involved and align on priority and timing. Make sure an equivalent owner/responsible party is assigned for the other areas you are dependent on.

Third, don't plan for success from the start. In other words, plan on cycles of learning. Determine your critical points where you will learn if a milestone is met successfully and budget time in the schedule for learning cycles at critical points.

Last, when someone else tells you how long their part of the project will take, assume they are lying. Just kidding...but be skeptical and sanity check their input with others if you don't already have a frame of reference. Some people pad their schedule and some over commit. In my experience, more people over commit and assume all will go well. Few are accurate unless it's a very standard task.