April 23, 2008
Project Transparency: It’s a Tricky Balance
Have you ever worked with a software project team that treated the project as a black box, providing regular updates but little insight into their daily workings? Whether the team is internal or external to the company, this is a frustrating experience. It does little to create trust in the schedule or confidence in the outcome.
More transparency is better when it comes to software projects. It means that both team members and senior managers know WHEN the project will achieve goals and milestones. But, more importantly, they know HOW the team will get there.
In Applied Software Management, Andrew Stellman and Jennifer Greene recommend that project managers do everything out in the open, first by publishing the work products and second by making decisions based on known guidelines.
Publishing your work in a public repository gives everyone access to the project information at all times. No one has to be concerned that they don’t have the full picture or that someone is hiding something. It also improves the quality of everyone’s work. If a person knows that their work is visible to everyone, it provides a big incentive to produce quality work.
Making decisions based on known guidelines also reduces concerns. Team members and managers learn that the project manager makes decisions in a predictable manner.
Transparency is about letting the entire team see who does the work, how the work is done, and what results it produces. It enables managers and other team members to speak with each other as needed and reduces the risk of individuals feeling left out of the decision making process.
Can transparency go too far? Yes, when transparency is abused and pushed beyond what it is intended for, a software project can suffer from inefficiency, delays and eventually a complete breakdown. Team members need to get work done, and can’t constantly respond to unnecessary inquiries.
The solution to this communication issue lies with clear roles and effective project management, not with information transparency. We’ve found that transparency has to be coupled with good communication between the lead members of the project team and the senior managers.
These leads can include the project manager, technical and QA leads, and relationship managers and others.
Once you set up the responsibilities of these key people and how they communicate, your internal customers will become comfortable with their ability to manage their risks. They’ll know how and where to the get the information they need. And they’ll know who to talk to when they have questions or issues to resolve.