I lead workshops on project management – scope control, scheduling, budgeting, risk assessment, team management. I deliver these sessions mostly to research trainees – the scientists and investigators of the future – and other research staff, as I believe that projects are more successful when everyone applies good management in their work.
At a recent workshop called “Getting Started in Project Management”, I was talking about the importance of having the project scope in a document so that everyone on the project could refer to it. I was asked, “who should have access to that?” My answer – everyone. The lab staff or computer programmers or field technicians will be the first ones to see that an approach is working or not working – why wouldn’t you want them to have as much information as possible about the whole project, so they can contribute to it?
This question comes up in almost every workshop, which tells me that many projects and work environments are not as open as they might be, and so are making it harder for the projects and staff to succeed. The project proposal (and charter, if you have one), the budget, the schedule – all of these should be available and accessible by project team members. They don’t have to read them – not everyone wants that type or level of engagement – but if they want to, then they should. Usually when I turn the question around to, “why wouldn’t you”, there is little response.
Of course there are pieces of information that are not for everyone – only certain people on a project need to know specific salary levels, for example. And project team members need training and guidance as to what information is confidential to the project or institution; confidential patient information, results that represent intellectual property, and contract terms with industry partners are examples of things that must be treated carefully, so as not to compromise the project outcomes and institution reputation.
In my own work as a leader and project manager, I strive for this openness everyday. I welcome and encourage questions and information sharing at all levels and throughout all projects. It’s not always possible – or advisable even – to give copies of all project documents to everyone; there does have to be control of these, as document proliferation and loss of version control is a sure fire way to create confusion rather than clarity. But when there is an opportunity to better enable project staff to contribute better by telling them the why in addition to the what, then I will try to take that. I’m also always open to talking with anyone on the project about what’s happening, and work hard to be as open and accessible to people as I can; this seems to work as I’m often engaged in discussion with people throughout the teams about understanding the hows and whys of various projects. Engaging staff in this way takes time and energy, and the engagement must be genuine or it will fail, but the efforts are well worth it to contribute to a successful project and team.
Perhaps leaders don’t see the value in spending their time and energy in this way, but I think the consequence is that they end up spending it elsewhere on less positive things, such as conflict resolution, risk management, and staff recruitment and retention. Personally, I’d rather prevent a mess in the first place than spend time cleaning it up.
Information management is part of controlling and monitoring in a project. But controlling doesn’t have to mean limiting or restricting, and so allowing all project staff to access and be knowledgable about project information and how the project is managed can enhance a project’s likelihood of success. As Hugh McLeod says: “All companies begin and end with the collective knowledge of their people. It’s up to management to figure out a way to put that knowledge to best use.”
For more from Hugh McLeod, visit his fantastic website at GapingVoid.com. See more from me about Hugh McLeod at my earlier blog post.