Emphasize Process over Product

I have built many work statements. One of the things I like to consider during the closing phase is writing down the lessons learned. I always look at the variance between the initial work statement and what actually transpired. The goal is that there should be no deviation; that the work that was written down matches what was delivered.

I have found that variance to personally decrease over time. Certainly some of that can be attributed to the fact that as a Project Manager I have greater experience and more intimate knowledge of what needs to be done. While it would give me great pleasure to claim that, it would not be very accurate. Instead, I made a very fundamental change in the work statements that I develop, and what I do seems to be somewhat unique. At least when I talk about it with my peers, it seems to open them up to considering new possibilities.

Years ago when I developed a Statement of Work I would go to great lengths to objectively identify the system or application to be built. I would identify the requirements, the "ilities" (reliability, scalability, maintainability etc.). Then during lessons learned, I found that I was way off. I found that at a generic level my requirements were OK, but when I made them measurable and specific, that locked us (the government) into a course of action and was a constraint that hindered the project.

I tried something new at HUD. Instead of identifying the product, and incurring all of that risk, instead, identify the process to be followed. It makes perfect sense when you think about it. Requirements are an artifact of the process, but in SOWs, too frequently people try to include them. Rather than describing the final system or application I described the process to be followed that will eventually deliver that final system. I identify how many Requirements meetings we will have and what a Requirements meeting looks like. I identify how many Design and QA sessions and what they look like. I identify how many development iterations we have and how we know when they are successful.

I don't waste effort in trying to describe the product any more. I think you need a crystal ball or an oracle or a time machine to try to describe the box that the solution should fit in so early in the process. Instead I only describe the process that will be followed, and, if you have the right development team, they will get you to the right solution.