Apr 7, 2011

Documentation Conundrum

Take a sample poll in any organization, ask people what they think Quality is about. Few can talk about Quality with reference to documentation. Insistence on paperwork to verify compliance led people to believe Quality is all about documentation and paperwork. If paperwork is in order, reality is (naively or conveniently) assumed to be just fine. Sometimes it looks as if Quality is more about documentation and less about customer - that predicament still bugs many of you like it bugs me. But is documentation and paperwork really necessary for Quality?

In sensible servings, documentation is beneficial: as reference and as communication tool. Policies and high level processes should be documented. But traditional approach for pushing documentation for consistency, accountability, completeness is outdated. Documentation (in its traditional sense of paperwork) is as necessary as cheques are necessary to withdraw cash from your bank account. There are better and more effective ways of bringing in accountability, consistency and completeness, just as there are faster and convenient ways of withdrawing money using an ATM, electronic transfer/clearance etc.

Focusing on Quality rather than Documentation

When processes are seamlessly unified with requirements for workflow automation, built into a workflow tool, documentation takes different, more effective form . Benefits of documentation are achieved, but differently, through automating and implementing the processes. When document changes automatically mean workflow changes - changes become seamless needing minimal manual intervention. Business can focus on service provision and Quality can get workflows to reflect processes. This opens up a host of other possibilities too and focus shifts to Quality from documentation.

For this to happen, processes should directly address business requirements, not requirements of a standard. Often, processes are designed to comply with a standard and to get a certificate (The argument is not against certifications - in fact, no standard requires processes to be defined in a particular way, only broad guidelines are laid out). When certification is the goal in itself, business needs take back seat.

Even when that is not true, requirements for workflow automation are something and processes are something else. Quality owns processes and somebody else owns workflow tools and automation requirements – their goals are not common. Often these people don't see eye to eye, perhaps even be at logger heads with each other – and business needs take back seat. It comes down to a silly turf war, yet, no one dares ask executive management to intervene and to break the silos. Consequently, Quality remains a back office that can’t reach out to the end customers, cannot influence the way services are provided.

If ineffective leadership, egotism, personal agendas (like personal brand building) take precedence over everything else, paperwork and other trivial stuff takes precedence and Quality remains a back-office business.

What are your thoughts? You agree? Disagree? Just share your opinions (you don’t need to login to comment)


  1. Quality can be delivered without documentation only if everyone does the required ACTIVITY as required in FULL FAITH. All the documentation that we ask today is only to "ensure" that the activity is performed as intended - though we know it is all post facto. Hence we need to imphasis on seriousness in performing the required activity to the extent possible - even if they do not document the same. If the activity is not peformed then it will result in failure - which is a REWORK. In order to avoid this we ask for documentation as proof. In today's practice, we need not have the documentation done on papers which are produced by cutting trees. Evidences can be maintained by a simple configuration tool which is fool proof and there will not be any SCAPE GOATS :-)

  2. I suppose your title is misleading. As your question goes like "Is Documentation Necessary for Quality?", there is only one answer - "Yes". No product can sustain without some level of documentation. I suppose you are not dealing with whether documentation is necessary or not, but when documentation doesn't add much to business requirements, are they necessary. If so, the article comes to life. May be you could try to give some specifics or examples to drive your point when documentation is done for the sake of it rather than its value. If it can bring how one can systematically ensure that they ensure right documentation levels, it could become a class article I suppose.

  3. Quality never asks for documentation,but if you can prove all the artifacts that are required by whichever standard u are following will answer this query.

  4. @ Ravindranath...

    I understand your point of view. Actually the point is not about saving paper, we are worried about saving unnecessary paperwork (so to speak)just to verify compliance. If paperwork or need for documenting is reduced somehow, both the purposes are served anyway.

  5. @ Moses

    You got it right...the argument is not about avoiding documentation altogether - but having just what is necessary and make sure that it is not overwhelming and consequently counterproductive.

    I will definitely think about your suggestions and will try and include your suggestions in future posts. Thank you.

  6. This comment has been removed by a blog administrator.

  7. I agree with your point. The intent of quality Assurance was to make sure that the process are understood by all in similar way and are practiced. But unfortunately the organization people see quality as compliance rather than quality assurance, it is not limited to external people but people within quality teams. Many believe that compliance is our job. I strongly believe that compliance is just to check and see that process is followed but now essentially everything.

    Even within Quality Team hierarchy, top guys think that quality is compliance. very sad part :-(

  8. The amount of documentation that is made out to be, I feel is an overdose. If you have come across sw dev methodology called SCRUM or Agile or Xtreme Programming you will get a feel what I am saying. The QA and programmer sitting side by side one reviewing the work and one reworking and all the comments automatically gettting noted. Basic planning documentation is what you need.