Do you know Project Police? They visited us this month. We dread their visits. Do you know why? Because their audits are a very big drain on the company’s resources; And spending 1 hour every week with them and spending 40 hrs a week on documentation would not be what I call as productive usage of my company; Month on month, project police were unleashed on us by our management. Well, project police is the pet name I’ve given to the folks who’ve taken it upon themselves to police our projects. In short, they are the “other quality team”.

Well, there are two teams that claim to be quality teams all over the place these days… one is us, the testing team, the other is the process team.  This team looks at CMMi, 6-Sigma, processes, etc and I call them Project Police. They are a necessary evil for us.

In an informal discussion, I did tell the process teams that all our code is written in English and we don’t need documentation, but only knowledge of a programming language to understand the code, but they don’t appreciate what I said.

Do you know the work of the CMMi process team in my company? They come to our desks at least once a week and tell us that they are doing an audit. Now, what is an audit? Well, it’s a process wherein they tell how mature we are by looking at only our documentation. What do they look for in our documentation?

1) They insist on reviews and meetings to be documented;

2) They insist on following a particular format and a header and a footer in all those documentation;

3) They insist on huge planning documents and sign-offs from all stakeholders in the planning documents; they don’t worry about the content of the documents, they only insist on an email stating that this is signed-off; they don’t insist on the credibility and knowledge of the person signing it off, they only insist on a documentation which proves his designation;

4) They insist in the existence of a change control board, which has to be documented;

5) Every change has to be documented;

6) They insist on project kick-off, project post-mortem, status meetings documented, progress meetings documented, steering committee meetings documented, reviews documented, reviews of reviews documented, comments on reviews documented, comments on comments on reviews documented.

They don’t review content; only existence of documentation.

Well, Process boards, let me ask you this

1) Will all this documentation save my project from disaster?

2) Can all this documentation save my company revenue?

If the answer to both these questions is NO, then why do you insist on documentation?

With your project audits, maturity level of our projects is determined solely on the amount of available documentation. Do they question the project members on the process? No!! Do they wonder if the time taken for documentation is more than that of the project? No. All they are worried about is documentation.

If you are reading this, CMMi is about maturity; if a project acquires enough maturity to avoid necessity for documentation, then that project will be tagged an immature project since there’s no documentation. How sad.

Is process about documentation? No, process is about discipline. For calculating discipline rates, don’t you folks feel that there’s a better process to identify disciple rates?

Do they realize that process is about practicing something? Do they look for our practices? Do they talk to us to understand our understanding of the processes? Do they interview project team members on if they understand why they need to do a particular chart? Not at all.

And these days, every project that has enough documentation is given a highly maturity award… Maturity and documentation are totally different; but do you think the experts realize that? Is that maturity or fake-maturity?

Maturity in process is all about practicing discipline; somewhere on the way, disciple and practice are forgotten, since documentation takes over.


Fake Software TesterA Fake Tester's DiaryFake Tester,Fake Tester's DiaryDo you know Project Police? They visited us this month. We dread their visits. Do you know why? Because their audits are a very big drain on the company’s resources; And spending 1 hour every week with them and spending 40 hrs a week on documentation would not be...
The following two tabs change content below.

Fake Software Tester

What has this author achieved in testing? This author has tested more than a million lines of code and has logged more than a billion defects; He has reviewed other test cases and found at least a trillion missing test cases and has coached his peers to log more than a quadrillion bugs; He has talked more than a Quintillion words while participating in triage meetings and he has been a part of sextillion arguments convincing the developer of the bugs. He has done good researching on septillion testing conferences; every day, he has Octillion thoughts that come to his mind on the problems that plague the world of software testing. He has selected Nonillion testers from his Decillion testing interviews and has unsuccessfully attempted to coach Undecillion testers about testing. His writings are followed by DuoDecillion readers and the comments on his blog are more than Tredecillion; he has answered Quattuordecillion questions on testing in various forums. And by the way, like the monthly columns, the above contains Quindecillion amounts of exaggeration on what I have done so far in my life.

Latest posts by Fake Software Tester (see all)