Need To Know or Need Not To Know?

I met someone yesterday who talked about an MNC which had issues with software projects not getting delivered on time. He suggested to them CCPM which is TOC methodology for project management (TOC stands for Theory Of Constraints).

CCPM is a great tool and hopefully things are fine now, but many times when projects get into trouble the issues are not about the tools but about people.

Software projects generally have one major advantage over projects involving physical goods: they are not dependent on vendors who delay supply of sub-assemblies (I say 'generally' because it is not always the case). Still, it is quite common for software projects to go off-track.

There are many reasons for this, but the one I want to talk about is something that affects the day to day output of the team - information sharing with the team members.

Many project managers believe in the 'need to know' basis: each team members will be told just what he needs to know to do his share of the work. From the project charter onwards, much of the project related info does not get shared with them. The project manager is the custodian of all information and is to be approached if any is needed; each request will be processed on merit and the required amount is doled out.

This may have some benefits, though I can not think of one. But it has many disadvantages.

    For one, it saps the initiative from team members and initiative is what makes a great project. If everyone is just doing what he has to do in next two weeks and knows nothing about what is beyond two weeks or what the others are doing, the team is not prepared for problems - and there is no project that does not have problems.

    It takes away the team spirit. People do not feel that they are in it together and will sink or swim as a team. The feel they are working for the project manager and that is it.

    Another great problem with this approach is how to determine what is needed to know. The team members often end up not knowing what is expected of them. If you have ever seen a project beset with goof ups and recriminations, you know what I am talking about.

As someone who was involved in turning around projects, I believe that the way to approach info sharing is not 'need to know' but 'need not to know'.

The way this works is: there is some info that the team members need not know (rather should not know). This could be like a team member having issues and being disciplined, client-management issues that do not concern the team, personal issues that project manager is privy to and so on. Such information will not be shared with the team members. All other info is open to them. In fact, all project info at the beginning, and updates as project goes on will be proactively fed to them through info sessions.

With this approach, there is clarity on what is expected from each one and a sense of belonging. The team members actively come out with suggestions on resolving issues in their area and may offer to help in other areas. They look forward to making the project a success and the kick that comes with that. Afterwards, they may even look back with nostalgia at the time spent on this project.

So if you have a project that is going nowhere, get the team together and find out how much they know about what the project is all about. That might point you to what needs to be done.