Profiling reports

By Eugenio, on October 15th, 2009

“The secret of life is honesty and fair dealing. If you can fake that, you’ve got it made.”

In almost every project I managed, every stakeholder had his/her “little” dirty secrets. And it was not related to the security needs; whether they were essential or just important.

Managing is about dealing with information

The accountability is the key value; however it depends upon the correct information available. It has to have (at least) the following properties:

True. Corresponding to the actual reality; therefore it can be measured with the common (accepted) measurements units/tools.
Updated. It is a corollary of trueness; however any effort spent on checking if the data are still valid is just a waste. This confirms the need for a working versioning system that will not limited to the recording of changes. Any modification to the previous baselines (the reference for the truth) has to be justified and approved.
Available. The forest remains the best place for hiding a tree. Instead of trying to understand the reasons for this common behavior, the best solution lies in the construction of a system that collects and distributes the needed data. Seldom, everyone needs to know all about everything. Usually a clear picture of the whole situation can respond to all stakeholders. From this, possibly realized through dashboards published on the project’s web site, should start a carefully planned work of profiling the details.
Clear. Concise is a good synonym for this concept. If the wordsmith job is not an easy one and different cultures (even if among different departments) ask for a plain language, it is important that descriptions are issued in the most captivating way. Using the same concept of WBS/OBS, the information should be flexible as a steel cable. Each wire is connected to the others preserving its maneuvering space. Weaving connections among concepts is one of the things that IT is championed for. These branches can be easily shown with a mind map .
Complete. The last adjective is the most important. There always some areas that remain outside the sphere of out knowledge and ability to understand it (there is a nice post from Peter Taylor on this topic). Therefore, highlighting what we already know in a way that can be confronted with the other people (i.e. sharing at least a similar strategy for naming and measuring the items forming the reality), allows the difficult process of locating the “unknown” areas. They are those bigger and most dangerous risks live prosperously.

Accountability and Responsibility[1]

In yesterday’s post, there is the definition of “Risk Owner”. It is defined as the person who is “responsible” for monitoring the event that could fire the problem. There are some considerations to be made about the necessity of publish the person’s name to all stakeholders. It resembles to the “Scarlet letter” a sort of label used to mark the scapegoat. From this reasonable viewpoint, no one wants to accept this unavoidable role.

Based on RACI the responsible is who carries through the assigned task. He/she has to apply the best of his/her knowledge and ability in order to complete the chore in the shortest possible time within the given quality parameters.

Accountable is the person who must respond of the correct result produced by the resources reporting to him/her.

This should make clear enough the reason for shielding some information from the “public”. Namely, in case of problems the person to ask for sound explanations is the Accountable one (e.g. Project Manager / Technical Leader).

Reporting and communication

John Astrello’s blog is a good source of sound advices. In his post, he describes the importance of good reporting to senior management. In this case, the profiling gains another value. Having the information available without cluttering the document can improve the quality of relationship. From the project manager side there is the certainty of being complete, for the senior management[2] the precious time is invested more freely.

Conclusion

There are two interesting posts in PM Hut[3]. They are about the importance of using a formal contract between the Project Manager and each team member. RACI is an excellent tool – easy to be used with an Excel sheet – and can form a strong basis for deciding which information can be published, when and how.