Why do stakeholders sometimes resist in sharing information? (By Asad Naveed)

Collecting information and defining scope are among the initial planning tasks in most of the projects, and they require feedback from the stakeholders. However, in many cases, the stakeholders are either unable to provide the required information, or they are resistant in doing so. As the remaining planning steps like Schedule, Cost, Quality, Resource, Communication, Risk, Procurement, and Stakeholder Management depend on the accuracy of Scope Management, they all will suffer, and so will Execution of the project as it is based on phony planning. There can be multiple reasons for this anomaly and some of them are mentioned below:

a.Lack of Knowledge

Be definition, a project has a unique outcome (result, product, report, etc). Hence knowledge about it is quite vague if not totally absent. Even in similar projects (like deploying 100 sites, when some sites were deployed earlier in another project), the stakeholders might have been transferred to other positions. As the current stakeholders may not have the required information, they will be unable to provide it.

b. Unwilling to take responsibility

Some stakeholders may resist to share the information, even if they have it, just because they don’t want to take its ownership. At the end of the project, if the outcome does not fulfil the long-term requirements, some blame may come to those stakeholders who provided initial information. In an ideal environment, the stakeholders should still provide the required information but in reality, they may think pessimistically and withhold the required information.

c. Desire to keep the requirements open-ended

In many cases, some stakeholders will like to have the option to go towards left or right. Means, that they want to keep the requirements open to interpretation so that whenever they want, they may add/change any requirement during implementation. It will have serious consequences for the project, as there will not be any end to the Change Requests, hence resulting in unnecessary delays and cost increases.

d. Inability to express

In some cases, the stakeholders do provide the required information but as it is subjective and as per their own thinking, they may be unable to express it properly in writing. So apparently, they are sharing the information, but in reality, it is wrong information and not what they actually desire/want. In such cases, it is the responsibility of the Project Manager to assess the actual requirements. Well known techniques like “Job Shadowing” and “Participant Observer” may be used in those cases.

e. Bad intent

In some cases, the stakeholders who are responsible to share the information, may, internally, resist the project (negative stakeholders). In such cases, they will not want to have a successful project and their effort will be to delay the project as much as possible, or have such an outcome out of it which will have least resistant to their ulterior motives.

Anyone who has tried to pull together a requirements specification knows how difficult the task is. When it comes to requirements elicitation having a highly skilled business analyst bridges this gap between the Project Manager and the Customer will ensure that the right requirements are captured and the system that the business actually wants is built. The following dilbert cartoon clearly represents this fact.