Some people say we cannot manage what we cannot measure. I say we cannot solve what we cannot see, or at least visualize somehow.

Projects are problem-solving exercises. The entire project is one big problem. We might be building a new product; that's a problem to solve. Or we might be trying to create something well understood but within a challenging amount of time, to a tight budget, and demanding specification. Or we could be moving our organization forward through a change initiative. These are familiar project environments that are puzzles or problems to solve.

Then within this large problem environments, we have hundreds of everyday challenges to answer, too. "How are we going to manage without the installer today?" or "The pilot group has requested 400 changes, now what do we do?"

It’s easy to believe that work breakdown structures (WBS) have been around since the pyramids were built in Egypt, and that product backlogs are new inventions by youngsters in too much of a hurry to plan correctly. However, like most things, the truth is more complicated.

In 1957, the Program Evaluation and Review Technique (PERT) approach was created by the United States Department of Defense (DoD) and described organizing tasks into product-oriented categories. However, they did not use the term “work breakdown structure” or WBS until 1962 when DoD, NASA and the aerospace industry published a document about PERT that described the WBS approach.

Meanwhile, in 1960, Tom Gilb described his Evolutionary Value Delivery approach (or Evo for short) that is widely accepted to be a forerunner of agile approaches. Evo contains principles such as: