«    »

Mistaking Plans for Goals

I believe there are two primary flaws in focusing on plans. The first flaw is the assumption that following the plan will achieve the goal. Sure, the plan is assembled with the intent of meeting the objectives, but what guarantee is there that this will actually happen? The second flaw is putting one's primary attention on the plan. People generally have difficulties dividing their attention between multiple things. Focusing on the plan means that from their perspective the goal loses importance. If this only happened to a limited degree then I would not feel the need to write this article. Let me provide some examples of the extremes to which I have seen people and organizations go.

In one prior project as we approached the planned deadline for starting user acceptance testing (UAT), I warned the project manager that the code quality was poor and only limited testing had been done so UAT would likely be a disaster. My advice was to miss the deadline and ensure good quality prior to entering UAT. Unfortunately, the manager decided the milestone was more important than getting the software to a working state. The code went into UAT and was soon thereafter rejected as being too buggy and unstable.

On another project a number of factors including excessive bureaucracy and externally-driven requirement changes caused delay after delay. After a few years (yes, multiple years) of delays, everyone from the project sponsor down to the project team members were so tired of the project dragging on that scope was massively cut and it was essentially rammed into production in a mostly non-functional shape, leaving the maintenance team to pick up the pieces.

Instead of focusing primarily on the plan, I propose to focus primarily on the goal - the real objectives. Progress should be evaluated as much as possible in terms of achieving objectives. I expect a common objection from plan-driven proponents would be goals are at too high a level for tracking progress. The solution is to decompose goals into the smallest possible objectives that retain meaning. In software development this means decomposing requirements or features into the smallest possible size that is still business-meaningful. Ron Jeffries calls this the minimum marketable feature (MMF) and views the delivery of working software that achieves MMFs as the fundamental unit of progress for software development.

Focusing on the goal means that a change in objectives should result in a change in action as soon as possible. Plan-driven methods seek to limit change, often explicitly, in order to stay aligned with the plan. This leads to misalignment with the goal, which over time leads to unhappy customers/users or effort wasted on pursuing the wrong direction. Most software development projects involve continual learning by both the business and by the developers about the problem domain, the solution domain, and the technical implementation of the solution. This inherently leads to objectives changing over time.

I do believe in planning, but it must remain subordinate to the objectives. The plan must remain flexible and easy to adjust based on how the objectives are being met and how they are evolving over time. Dwight D. Eisenhower is reported to have said "Plans are worthless, but planning is everything." This quote captures the essence of my philosophy. The act of planning is critically important - determining the correct course of action based on current understanding - but plans based on old and likely outdated knowledge are not.

If you find this article helpful, please make a donation.

«    »