Minimal sufficiency applies to tooling just as much as it does to documentation!

“Working software over comprehensive documentation”

This value statement from the Manifesto for Agile Software Development is a reminder to remain vigilant that the by-products of our product or project processes don’t distract us from delighting our customers and stakeholders. For organizations which have onerous, document-based delivery standards, it serves as a guiding principle to lean out methodologies focusing on the minimal set of information required to meet delivery and control needs. This is usually accomplished through elimination, consolidation and streamlining of documents.

But what about those companies who have implemented tooling to support delivery in place of documentation? Just because we have moved from standalone documents to one or more supporting applications doesn’t mean we should not apply the same principle of minimal sufficiency.

Here are three ways I’ve witnessed this principle ignored:

  • Multiple point solutions with overlapping data elements, conflicting workflows, and differing nomenclature. This often occurs when delivery tooling is procured in a distributed manner. For example, a Business Analysis leader might select a requirements tool, a Quality Control manager has procured a test case and defect management tool and so on. Project teams get confused by how the different tools connect together and the likelihood of data accuracy, consistency and completeness defects increases. While detailed reporting can usually be managed easily, project/product-wide or portfolio-level reporting becomes extremely difficult.
  • Not disabling the fields and features which are not required. You might ask who would fill out a field or use a feature which they don’t need to, but you’d be surprised at the creativity of teams at using unused fields as a means of ferreting away some information they believe is valuable. Beyond the potential for field or feature abuse, a bigger concern is team members getting distracted or overwhelmed by the complexity of a solution.
  • Tooling which does not map to the information needs of team members. Its become a cliché, but one which continues to be ignored – don’t buy and implement a tool if you don’t understand the process it will be supporting! If the tooling does not help team members do delivery activities, then they will treat it as an afterthought and continue to use more useful, home-grown solutions.

I am not encouraging the development of delivery tooling in house or engaging in significant customizations to third-party applications as neither approach is appropriate for most organizations. It does mean you should be spending some effort up front to identify the key data elements which will be needed by different contributors to the delivery process, defining the minimal set of reporting and workflows required, involving an actual delivery team in the tools evaluation process, and working with vendors to safely disable or hide all non-essential features.

So before patting yourself on the back that you’ve migrated from delivery documentation to online information make sure that you haven’t just replaced one source of waste with another!

 

Advertisements
Categories: Agile, Project Management | Tags: , | 2 Comments

Post navigation

2 thoughts on “Minimal sufficiency applies to tooling just as much as it does to documentation!

  1. Pingback: Minimal sufficiency applies to tooling just as much as it does to documentation! – Best Project Management Sites in One Place

  2. Hi Korin, I read your article. It is very interesting. You made very good points, as you emphasised the idea or practice of minimal sufficiency. I believe that it’s every organization goal to reduce cost while meeting production need efficiently. This also brings the idea of lean practices into play.

    I want to say your first point where you talked about multiple solution points with overlapping data, would have to do with the project organization structure. Every functioning manager have their requirements and what makes the work easy for them, and team members are expected to understand this facts. Where as, if managers could adapt a much more better structure that would integrate solutions, and share common outputs that hence decision manking, the need for different types of tooling or fields and the worries about data accuracy or completeness would be reduce.

    Thanks for sharing your article with me. I will take sure to follow you!!!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: