Your monthly dose of insightful Project Management articles

Your monthly dose of Project Management articles.

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.


Exclusive 💬

Asad Naveed

About author

Senior Engineer

Over 20 years of experience in various areas of Telecommunications, Electronics, IT and Project Management in USA, Middle East, Canada and Pakistan. Special expertise in the areas of Optical Fiber Networking, SDH/SONET, DWDM, Carrier Ethernet, Microwave, Wimax, IP Technologies, Internet Security, DDOS, System & Network Administration, Alternate Energy, etc. Adept in System Engineering & Planning, Testing & Commissioning, Training & Teaching, Technical Support, Project Management, Troubleshooting, Documentation, Standards, Market Research, Product Comparisons, Technology Management, Project Management, etc. An International Trainer.

Contributed in a number of Fortune 500 and other Companies (Lucent Technologies, Alcatel, IBM, Celestica, HBC, KFUPM, PTCL, PMI and Telefocal) and widely traveled in Middle East, Europe, Asia, Africa, Oceania and North America.

35 Countries Visited/Lived In (Mostly for Work/Business):
- Asia: China (including Mainland, Hong Kong and Macau), Indonesia, Malaysia, Pakistan,
- Singapore, Sri Lanka, Thailand, Turkey,
- Middle East: Kuwait, Oman, Qatar, Saudi Arabia, UAE
- Europe: Belgium, Bulgaria, France, Greece, Netherlands, Switzerland, UK
- North America: Canada, USA [CO, CT, DE, IL, MA, MD, ME, NH, NY, PA, RI]
- Oceania: Australia, Fiji Islands, New Zealand, Solomon Islands
- Africa: Algeria, Congo DRC, Egypt, Ethiopia, Ghana, Nigeria, South Africa, Sudan, Tanzania

Holding Master’s and Bachelor’s Degrees in Electrical Engineering from foreign and accredited Universities. Honored with MEF-CECP, PMI-PMP and PMI-RMP Certifications, in addition to advanced certifications from Cisco, Sun and Lucent Technologies. Have strong qualities and skills in leadership, teamwork, analysis, negotiation and communication. Provided trainings to a number of different clients in Africa, Middle East and Asia. Currently engaged in multiple roles: Freelance Trainer, Visiting Faculty, and MEF Certification Committee.

View all articles