Risks and details

“The devil is in the detail”.
In many job descriptions, the “attention to the details” is an essential value for evaluating a Project Manager. It seems to be contradictory with the holistic approach (Aristotle in the Metaphysics: “The whole is more than the sum of its parts”). However, the key is in the ability of understanding the work of managing the project itself.

Working with details (prioritizing)

Any small project contains a huge amount of details that are almost impossible to be managed with the single human brain; furthermore, besides the importance of their value, there is the timing of each single element. This brief analysis points out five major topics:

1. The people detaining the (fragmented) knowledge.
2. The relationship that transforms each data into meaningful information and possibly in fruitful actions.
3. Tools, techniques and processes for easing the flow of information from the owner/producer to the user/evaluator; where these roles are often changeable within the whole project life.
4. A scale to measure their weights for distributing the needed resources.
5. A calendar (or clock) for making sense of their both specific timing (namely, when they will become important for the output) and timeliness (how long will take to complete the task).

The actors and their scenario

The previous list can be reduced to three elements:

1. People who write their scripts full of details.
2. Timing that allows every actor to deliver his/her cue with all eyes on him/her.
3. A “theater” that allows to accommodate the paying public that loves the happy end (delivery of what has been agreed)

From this viewpoint, the project manager work resembles to the director. The good knowledge of the screenplay is still necessary; however, it is much more important to maintain the support to each person than privy his/her own knowledge.

This confirms the difference between Responsibility and Accountability in the RACI model . While each team member is “responsible” for the best delivery of his/her own part, the Project Manager has to answer for the whole performance.

Evaluation needs confrontation (benchmarking)

Details differ from the guidelines from their strict adherence to the reality. Alas, every person has his/her own perception of the reality; therefore, the role of Project Manager needs to be “super-partes” not only within the team, but with the other stakeholders as well.

However, picking up the correct detail from the huge flow of information is close to choosing the right fish within a school. In fact, the famous needle in the haystack supposes that everything is still; while, in a project the time factor is essential.

Is it possible to create an effective and efficacious process for evaluating details?

Once the guidelines are set by stakeholders (e.g. public, writer, actors) to put up a system (e.g. CMS and wiki, more to come about the Product Description in Prince2) with the capacity of a catalog the different instances that will be confronted each other using the same scale.

The system and people

No project can rely on a single system for its survival if not success. People are still at the center of the arena. There are many reasons for this:

1. Most information needs to be distilled. The business analysis process consists in capturing which data are essential for the project and looming them into a “readable” model; therefore, a system can support the process with the capacity of storing data in a meaningful way.
2. There is a huge difference between knowledge and information. The former belongs to human beings that render each bit of data useful for colleagues, customers and users. So that, the turnover damages the project because of the difficulty of creating and maintaining the empathy that allows the natural flow of information among the stakeholders.
3. No system can be considered “accountable” or just “responsible” for doing choices.

Reducing it to its extreme (absurd) consequences of this logic, the Project manager role includes the following responsibilities:

1. Supervising the tuning of the system for the project’s specific needs in accordance with stakeholders.
2. Managing the process of collecting information that will form a huge checklist.
3. Monitoring the quality of the process, otherwise stepping in when people are not able to cope with the alternatives offered by the system itself.
4. Facilitating the flow of information among all stakeholders.
   

Real examples

This is a very makeshift list of already available tools and techniques:

1. Automated testing based on Ant’s scripts is very common and almost inexpensive.
2. Timesheets can offer a gold mine of data, when they are configured and synchronized with the Product Description and other Plans.
3. Schedules (IMS) can supply the timing to be used as guidelines (the risk of micro-managing the team is always incumbent).
4. Issue and Risk registries should be viewed in both ways. As input for specific analysis and as a tool for gauging the  information flow either general or specific.
5. EVM techniques.
6. Glossary based on the common methodologies. They will be tailored on each project’s needs; how many times discussions are kicked up by a different interpretation of the same word?

Conclusion

Thinking a system that forms the project’s memory resents a (Kafkian) joke. However, the importance of a honed repository is still an essential part of the project management.

More references