The Two Most Important Words in Business (Part 4)

Outcomes, Actions, and Change Control

There are at least two ways to kill a project with change control. The first killer is to enforce no change control. Many software project, in particular, die a death by a thousand cuts because nice features are so easy to add. The second killer – possibly an overreaction to the first killer – is to enforce total change control. Imagine a project plan that contains great detail but no change can be made in the plan without the formal approval of a Change Control Board. Again, it is death by a thousand cuts, but it is a different kind of knife.

So, what is the answer? Is the answer to stop planning details so the details never have to undergo scrutiny? Of course not. Software contains hundreds or thousands of detailed features, and all of them should be the result of outcome analysis, so don’t dumb down your plans and don’t keep your destination a mystery.

Do we search for a compromise or a balance by drawing an arbitrary line (say, at the third level of the work breakdown structure)? Of course not. Arbitrary decisions rarely work.

Recommended Practice: I believe the best answer is to understand that intended outcomes demand 100% change control and actions demand 0% change control. I may plan a work breakdown structure with five or six levels of outcome analysis, but changing any intended outcome is equivalent to changing our destination. That demands some measure of change control, and some measure of formal communication with the team.

On the other hand, changing a list of actions may be as simple as updating your to-do list, and that certainly doesn’t require formal scrutiny and approval. So, I believe the answer is in knowing the difference between outcome analysis and action synthesis, and exploiting that difference!

By the way, I am not advocating 100% freedom of action. For example, if I’m working on a government contract that requires accurate cost collection, I won’t allow team members the freedom of not recording their time this week. The distinction is that timesheet duties are not defined as discrete actions of the project; they are part of an ongoing process.