A couple of times people have said to me that sharing the project budget with their team members is Not A Good Idea. I don’t know why that is the case – they are stakeholders too. I think it is essential to be transparent about the budget, how it was created and how you, as a team, are doing with spending it. It helps the project team come together with a common objective, and it helps build trust in the way in which things are being done.
In his book, Employees First, Customers Second, Vineet Nayar talks about 5 ways that transparency helps build trust among the stakeholder community.
1. Understanding the bigger picture
“Transparency ensures that every stakeholder knows the company’s vision and understands exactly how his or her contribution assists the organisation in achieving its goals,” Nayar writes. In project terms, it is difficult for a project team member to contribute effectively without knowing what the bigger picture is. In budget terms, if team members don’t know how things are going overall and how much their elements are costing, they cannot help work more efficiently to get the job done.
2. Generating personal commitment
Nayar says that transparency ensures that “every stakeholder has a deep, personal commitment to the aims of the organisation.” I don’t believe this is true. Transparency may contribute to building this, but it is not the only way you get people to feel as if they are personally committed to a project.
3. Transparency is a given for Gen Y
The younger project team members will expect full transparency, and without it they will be suspicious and untrusting. “They post their life stories in public domains,” says Nayar. “They expect nothing less in their workplaces.”
Again, there is more to this than I think he brings out in the book. Transparency about the budget and all other elements of the project will help generate trust in team members of all ages. Generation Y team members may have a different expectation of what is appropriate to share, but sharing (or not sharing) will have an equal impact on the trust levels across the entire team.
4. Corporate transparency promotes customer transparency
Nayar says that in a knowledge economy, it is important for customers to share their ideas with companies. This is the way that we find out what products they want, how their lives are evolving and what would make their lives easier. They may also have ideas about solving problems with our products or corporate challenges that we are facing. “Why would a customer be transparent with a potential partner like us if that company does not trust its employees enough to be transparent with them?” Nayar asks.
This is a fair point. While I would not advocate sharing the project budget with customers (unless your work is in the public sector and this is therefore expected), it is a good idea to share the budget predictions with your suppliers and partners. Why not? It will help them pitch their services at a price that creates a win-win situation for you both. In one case I heard about recently, a supplier opted not to pitch for work when they heard the budget figure that the company in question had available. It saved both the company and the supplier a lot of time in the tendering process. Share your budget figures with people outside the immediate project team. Or at least consider reasons why you shouldn’t, and then critically assess those reasons to see if they still stand up.
5. Transparency helps contractors
Finally, you need to consider the work of contractors. “The only way these outsiders can get up to speed quickly and be as effective as possible is through sharing of information and complete transparency about the strengths and weaknesses, the issues and concerns, of the assignment,” Nayar writes. “The more transparent the process, the more trust that the outsiders felt in the organisation, the more we could reduce the amount of learning time, which would give us an advantage over our competitors.”
If you share project information with contractors, it helps them feel more comfortable in their role. It will also help other team members, who have to deal with these contractors, feel as if the contractors are offering a valuable service and are actually making a contribution. If the contractors operate without full visibility, other team members may well feel as if they cannot trust them to make the right decisions because they do not have all the relevant information.
How transparent are you with your project budget? Do you share this information with stakeholders as willingly as you share other project information? If not, why not?
This month, the discussion topic here at Gantthead is stakeholders. Project stakeholders need documents – but how do you know how much documentation is enough? Unfortunately, the answer is always, “It depends.”
The amount of documentation stakeholders need to feel comfortable depends on:
According to Tom Kendrick in his book, 101 Project Management Problems and How to Solve Them, there are three types of project management document:
Definition documents: these define the project so include things like the project charter, requirements catalogues and organisation charts. Stakeholder management/engagement grids and analyses also fit in here. Definition documents might sound static, but they actually need updating regularly as things will always change.
Planning documents: these help the project team plan the work. They include the plan (of course), risk register, the project schedule, and any other project-specific sub-plans like a communications plan.
Status documents: these are the documents that stakeholders are generally most interested in. While they should be interested in the requirements and the risk log, you’ll find that the majority of stakeholders only really want to know how things are going and what they have to do next. Status documents include the things you would expect like regular reports, the issues log and follow up actions, the change log and other regular, non-standard documents that discuss status like meeting minutes.
Where does your project budget fit in all of this? Well, it’s partly a definition document: as part of the project initiation activity you would have defined the budget in the project business case or initiation document. But it’s also a status document: the real-time changes in the budget and tracking how much you are spending is very much related to project status.
You may find that it is easier to have two versions of the project budget: one definitive, signed off, formal version of the budget that never changes and acts as a reference point (your project budget baseline) and another as a living document that you update for quarterly forecasts and use to record actual spend. Personally I spend much more time on my living document than I do going back to the original, but I know that at the end of the project I will be expected to justify any changes to budget in the post-implementation review, so it’s important to still have those figures unchanged, with details about the project assumptions that helped shape them as no doubt by the end of the project I will have forgotten why the budget was set up that way.
Those two documents are ‘enough’ for my project budget. I can pull extracts or summary figures for my status reports, and that satisfies my stakeholders. How do you manage your project documentation, and do you find yourself doing just enough, or producing documents that no one ever looks at again?
Last week I shared with you some questions and answers from my recent webinar on managing money on projects. I wasn’t able to answer all the questions after the presentation, and those questions I didn’t get a chance to answer in person I am answering here.
Might training be considered a deliverable cost associated with quality assurance? What about testing resources?
You can see the whole presentation online here, via a recording of the webinar. I’ll have some more Q&A for you soon!