I met with a company this week where they really get the transparency religion. They have a project knowledge base built from Bugzilla code and a source code repository in CVS. They allow their clients to have password controlled access to all of this. The client can see the source code. There is total transparency. The company provides access to CVS and the client can pull down newly built code every week. There is a conference call with the programmers to discuss "what's new this week". It truly is eXtreme Programming at its best - and its verified CMM Level 2 compliant just for good measure.

What impressed me most with the management was that they also understood that they were providing transparent access into the data ocean of their projects. The chances that an executive from their client companies would be able to interpret all the data remote to non-existent. So transparency for them had somewhat reached its own limit to growth. I showed them some material from the book, particularly Chapter 14 Operations Review and we discussed how Feature Driven Development uses a roll up parking lot diagram and how TOC provides a way of distilling out the vital leveraging information such as buffer usage in a Critical Chain plan. I then showed how I had merged the parking lot with the buffer usage to provide a truly accurate objective parking lot with drill down into specific projects.

Eli Goldratt writing in The Haystack Syndrome described data as the input to a question and information as the answer to a question. If you are to provide useful transparency then you must provide information (transparently) which answers the questions in the viewers mind. Do you need to be a mind reader? Not quite! Just put yourself in their shoes and ask, what would I need to know about this project, if I were the CEO of the client?