Transparency

Photo by Anh Tuan To on Unsplash

Why do we need Transparency in product development or project management?

• For the Manager?
  • No, we have a weekly meeting and we talk about the issues
• For the Stakeholder?
  • No, we have a biweekly meeting and we demo latest features or discuss product issues
• For the External Consultant?
  • No, we have a monthly meeting and we clarify expectations
• For the Department Head?
  • No, we have a quarterly meeting and we define goals

The guide implies that Transparency is for the Team (“those performing the work“) and the Stakeholders (“those receiving the work“).

BUT,

• The Team is busy with Delivery for the sake of the Stakeholders
• The Team knows the issues both positive and negative
• The Team should perform and not worry about making performance transparent
• The Stakeholders get a demo once in two weeks / once in a month
• The Stakeholders need to only ask to know
• The Stakeholders would rather have the Delivery instead of the Transparency

The guide says that “important decisions are based on the perceived state of its three formal artifacts“

• If it is anyway the perceived state, why make issues transparent in the first place

The guide suggests that “low transparency can lead to decisions that diminish value and increase risk“

• If the Project Manager has high ownership, do they need transparency
  • Will it not cramp their style and freedom?

The guide tells us that “Transparency enables inspection“

• What if Inspection is not wished for?
• What if Inspection makes work life difficult?
• What if Inspection is not supportive and encouraging?

The guide nails it in with “Inspection without transparency is misleading and wasteful.“

• If the value behind Transparency is not clear, then the next enabling step is not interesting
• Inspection with transparency can also be misleading, so why inspect?

Enough reflections on why Transparency need NOT work!

How do YOU make Transparency work?