Laws of Project Management

A project's goal rarely has anything to do with implementing a list of features. It is usually about solving a problem for users, the business, or both.

The original specification is a guess about what will solve that problem. It is almost certainly wrong, and it will change as the team learns more about the problem and the solution, as explained in Law 2.

Considering that the original specification is likely wrong, the only way to materially influence the outcome of a project is to understand the problem it is trying to solve so that you can adapt the solution as you uncover more information. If the team does not understand the problem, it cannot change the solution without risking failure.

• *Recommendation:** Make sure the team understands the problem before it starts working on the solution. Keep the problem in mind as the work progresses, and be willing to change the solution when new information is discovered.

A project's initial scope is based on what the team knows before it starts doing the work. That's when the team knows the least about the problem it is trying to solve. The initial scope is therefore a guess, and it is almost certainly wrong.

As the project progresses, the team will discover constraints, missing requirements, and incorrect assumptions. Some parts of the solution may be more expensive than expected, while others may turn out to be unnecessary.

The scope must change to account for those learnings. Otherwise, the project remains committed to decisions made without enough information.

• *Recommendation:** Don't plan for too long before starting the work. You will uncover more information as you go, and the scope will change. The team should be able to adapt the solution to what it learns.

Committing to a particular scope and an exact date may seem reasonable at the start of a project. However, if you accept that you don't know the scope before the work begins, you must also accept that it's impossible to know how long it will take…