Applying the Rule of Least Surprise to Projects


I just read Jim Coplien’s paper about teaching design called “Close the Window and Put it On the Desktop”. He references the “Rule of Least Surprise,” which is to do the “least surprising thing.” In design, it means the user shouldn’t be surprised or confused by what the program does. But what does it mean for projects?

Here are some thoughts-in-process for applying the Rule of Least Surprise for managing projects:

  • The project manager helps the project team focus on the final deliverable, not interim deliverables, so the project team doesn’t fall into the “crossing the desert” mode, where it looks as if the project will never finish.
  • The project manager helps the team set the goals and refine the project’s goals, so the project team knows what they have to do at all times. (“Does this task help us accomplish the goal?”)
  • The project manager helps make the project state visible to all team members so they can see where they are with respect to the goal. (So the project team isn’t surprised by the work remaining.)
  • The project manager makes the project state visible and understandable to the stakeholders, so they can see the project’s progress. (So the stakeholders aren’t surprised by the work remaining and the risks to accomplishing that work.)

I’m still thinking about this. But since I believe the project manager leads the design of the project, the rule of least surprise should apply to projects, as well as to products.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.