Article: How Agile project management practices can save the government contracting industry by allowing agencies to stay ahead of their problems

Some key points from the article:

As we said before, Agile was initially used as a business model for software development companies who found their industry becoming burdened by the same stale business interactions that public procurement is feeling. The model is based around 4 core values and 12 principles described in the Agile Manifesto, which is worth reviewing to understand the philosophy.

The 4 core values are:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

There are also 12 principles demarcated in the Agile manifesto; however, we’ve found that all 12 aren’t particularly useful for public procurement purposes, so we’ve narrowed it down to just 5. These 5 principles stand out from the rest in situations that involve securing goods and services:

  1. Welcome changing requirements, even in late development.
  2. Deliver working software (solutions) frequently (weeks rather than months)
  3. Close, daily cooperation between business people and developers
  4. Projects are built around motivated individuals, who should be trusted
  5. Simplicity—the art of maximizing the amount of work not done—is essential
1 Like

I like thinking about this because many of these are the exact opposite of what you often hear form contracting professionals. The reason for these changes is the software industry realized they needed to deliver working capability users actually enjoy using. Delivering software meeting 100% of the requirements, but the user hates should not be considered a success.

  1. Working software over comprehensive documentation

Obviously it would be great to have both…but would you be more proud of a contract file with 0 write ups and significant performance issues or a contract with some write ups delivering exceptional performance?

  1. Welcome changing requirements, even in late development.

The software industry has accepted they will not be able to perfectly define what the user wants during the initial design. It’s better to find out something isn’t going to work now, so we can work on improving it.

  1. Deliver working software (solutions) frequently (weeks rather than months)

The faster you deliver, the faster you can get user feedback and make improvements.

I think there is a lot of potential with changing how we think about these concepts.

A counterpoint or consideration is the software industry has developed things like continuous integration & continuous deployment to reduce the cost and time it takes to make changes throughout the life of a project. If you don’t have the the right tools and processes in place late changes are costly and have big schedule impacts. It’s also possible some industries don’t lend themselves to this approach. For example, software is much easier to change on the fly than hardware.

1 Like