Build Resilience in Any Kind of Project

Johanna Rothman, known as the "Pragmatic Manager," offers frank advice for your challenging problems. She consults with leaders and teams to help them learn about practical and possible options. They can then decide how to adapt their product development. Her most recent book is "Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility." See www.jrothman.com for all her books.

  Agile   Quality   Testing/Test Management  

I like to think about resilience as a way of using past performance and data to inform our next steps.

Agile approaches tend to build resilience into the work because of the frequent build-release loop. The team builds something useful for the customer and then releases it. It then builds the next thing and releases that. The faster the team can finish work and release, the faster it can get feedback about what it built.

What if you can’t use an agile approach for some reason? You might not have a project that lends itself to an agile approach because your product contains hardware that’s not easy to upgrade. The cost of frequent releases dwarfs any profit you make from the product.

Sometimes, your customers don’t want agile projects—especially if they are (or think they are) too busy to offer you feedback. I would argue that those kinds of projects desperately need an agile approach. I might be correct, and that doesn’t matter. If you can’t get the feedback, you might not want to try to create or use an agile approach.

However, you might well want to create a project where you can take the relative past and use data and information to inform the next bit of work. In that case, I recommend you consider these three ideas:

1. deliverable-based planning
2. frequent internal releases
3. frequent kaizens or retrospectives

(Note: …

Please log in or sign up below to read the rest of the article.