Yesterday I got a call from an old friend. We talked about life, kids, and all those things which generally dominate my thoughts these days. After we got though all that, he turned the conversation to one of our oldest discussions – how to make a project management office work without driving everyone completely insane. It’s an important topic in his life, given that he builds formal and informal PMOs for various corporations.
We drifted onto the eventually into the bugbear of scope control. It is the kind of discipline which causes problems from the beginning of the project though its inevitable future incarnations as change orders coming in throughout the project. After going back and forth, I proposed to him a rule of thumb I’ve developed over the last few years. It goes like this:
A project manager’s control of his project is directly proportional to the specificity of the scope statement.
What the heck does that mean? Let’s use a silly example to explore various scope statements that I’ve seen over the years. The initial statement reads something like this:
Company ABC will create XYZ software package by XX/YY/ZZZZ. This software will be able to slice bread, toast it, butter the toast, and put it on a nice warm plate.
Now, this is a lovely statement. Assuming, that is, we want a piece of toast. But, what if during discovery we learn the business really needs us to to make peanut-butter and jelly sandwiches? Well, our little toast making software can probably adapt to do that. Therefore as, design and discovery complete we reformulate our scope to read more like this:
Company ABC with the help of contractors and their subcontractors will create or buy a software package which will slice bread, toast it, butter it, cover it with peanut butter, pick berries, make jam, spread the jam on the sandwich, put the pieces of toast together, and serve it on a warm china plate.
Great. Now we’ve got the design for a PB&J sandwich making monster of a product which will provide us with various types of jelly when fed the correct ingredients.
At some point, though, a director pipes up that the company doesn’t own any berry farms or jamming equipment. Fortunately for us we have an answer. Dealing with that is outside the scope of our project. We just need to pick the berries. It’s someone else’s responsibility to figure out who will provide us with the bushes to pick. Hopefully we know who that someone is; if not the selection of berry bushes becomes an executive function.
Say we progress a little further down the project path. Now our team (or more likely several teams) has moved though the various product development phases. We are busily coding, building, testing, and working away at our little piece of the puzzle when we run into some small snags. It seems that the bread slicing team can only work with square loaves of a particular size. The buttering team needs circular slices so they develop a way to mill the squares down. The spreading team came up with an innovation which allows them to spray rather than spread but it requires the slices to be in form of isosceles triangles. To meet this requirement, they apply their own cutting process. The end product, the PB&J sandwich, needs to be square, so the assembly team can just fit the triangles together – after a long discussion about whether Pythagoras was a loon or a mathematician. The resulting sandwich goes shooting off into the factory because the plate team put the warmer a few feet too far to the left.
Eventually, someone realizes that no one wants butter on their toasted PB&J. Except, after a dozen focus group meetings, it turns out that one executive vice president actually likes his that way. So the buttering team gets a reprieve and their feature is back in the product. Everyone else will just have to learn how to deal with the butter and the project eats the slicing expenses.
The good news about this is that slicing expenses are outside the scope of the project. We don’t have to worry about waste; we just have to create sandwiches. So is delivering the PB&J sandwiches. If someone comes to complain about the size, shape, or the taste of the sandwiches, the project manager can pretty much ignore them. None of it falls into within the boundaries of his responsibility. He’s supposed to deliver software which creates buttered PB&J sandwiches and he’s almost there.
Finally, the time comes to deliver the product. Some poor fool suffers though the deployment of 300 PB&J machines, costing him most of his hair and several trips to the emergency room. During the deployment process it’s decided to take the connections between the physical devices wireless, not that the company had any wireless networks (or wired trolleys for transporting bread). But that’s okay – it was outside the scope of the project. That was some other project, probably in the hazy realm we dismiss as “infrastructure”.
When all is said and done, the systems work flawlessly. Not that anyone cares. Some plucky secretary at each facility installed a toaster in the break room so everyone can have their toast for breakfast without running the crazy, loud machine. That’s okay too – following up on business use is outside the scope of the project.
Now, in the real world we try to write ever more complex and complete scope statements and to adopt “agile” methods involving rapid prototyping in order to avoid fandangos like the one described above. Unfortunately humans are still humans; we define our responsibilities by our boundaries not by abstract goals. We have also broken the actual activity of work up to the point where, even with iterative methodologies, it can be very difficult to conceive of the effect one part of the system has on the whole. This is, naturally enough, fixable with the addition of ever more layers of communication, intricate methodology, and the specialists necessary to support them.
Things obviously don’t have to get this far out of control. Addressing how to build projects by goals, rather than boundaries, is something I’ll talk about sometime in the future.