Specifications and Discovery in Project Management
Written by Jeff on February 1, 2017 in blog

Two words to clarify Agile : Specification and Discovery

Agile is a mystery to many project managers. They are confused. That’s because they don’t understand how Agile fundamentally differs from traditional Project Management.

Specifications and Discovery in Project ManagementTwo concepts help clarify things, specification and discovery

  • Specification : Most 20th century Project Management methods (PMBok Prince2, etc.) are specification based. You specify your deliverables, then deliver to specification.
  • Discovery : Agile is discovery based. You start work with only a broad idea of needs. You deliver iteratively. You discover your solution, iteration by iteration.

Specification based methods are still widely used in many projects. For example, for a construction project or an IT infrastructure project, you need specifications. You start by writing specifications. These specifications then drive delivery and help to control quality.

Discovery techniques appeared in the 1980s. Software projects using specifications were failing. Software teams abandoned specifications and turned to discovery techniques. In the 1990s, SCRUM was born, and in 2002, Agile.

Where to use discovery techniques

You need discovery techniques in specific areas such as:

  • software development
  • product innovation
  • web site development

You need to discover the solution, using iterative development. At each iteration, you improve the user experience (the “look-and-feel”). You make it more friendly, easier to use. It’s hard to specify ease of use.

Discovery techniques help to discover knowledge. If you are working on product innovation, you are almost certainly in discovery mode. Iteratively you learn how meet your customer needs, sprint-by-sprint, release-by-release. You discover knowledge at each iteration.

Where to use specification techniques

In many projects, you should use specifications (and not discovery). If you have solid upfront knowledge, you should create a specification.

That can mean knowledge about

  1. the problem to solve
  2. the solution to deliver
  3. how to do the work

So, for example, most construction projects are specification based, because they do have enough knowledge to create specifications. The problem is clear: the client explains their needs. The solution is clear – the architect draws up plans. And how to do the work is clear – in most projects, builders will use proven construction techniques. This all calls for an upfront specification, rather than discovery.

Using both within a single project

The choice is not binary. It’s not “either-or”. Both types of work are often needed within a single project. In those parts of the project where you have knowledge, you need specifications. In those parts where you have doubt (insufficient knowledge), you need discovery.

  • discovery-driven project may have some specification-driven deliverables. For example, on a web-site project, you may have both. The core of the project is discovery-driven: the user experience should be refined iteratively. However, complex credit card rules may be specification-driven.
  • specification-driven project may have some discovery work. For example, a construction project is typically specification-driven. But it may use an iterative approach to optimise work with innovative building materials.

That’s two new words to add to the vocabulary of every Project Manager. Understanding the difference between specification and discovery is vital for understanding Agile.

Facebooktwittergoogle_pluslinkedinmail
Leave Comment