Requirements, Stakeholders and Stakeholder Management
Our project must balance the input from a myriad of people that are associated and contribute to the project, along with those funding the project to be successful. To be able to do this, we will need to understand our stakeholders and their perspective. Some of our the stakeholders will add requirements, support existing requirements or even contend some of the requirements. Their perspective can be thought of in a variety of ways which we list below. We will need to balance the inputs we get from the myriad of project stakeholders against the constraints of the project (time and money) and the success criterion of the project
Experience suggests considerable time can be spent sorting out inputs or requirements from sponsors and stakeholders. I have personally been involved in projects where the clock ticked while the project manager and stakeholders and sponsors debated a certain course of action – effectively idling the rest of the team. This comes at great cost to the project schedule, and I was glad I was not the project manager but sad to say I was part of systems engineering for the project. The identification of the key participants and areas of responsibility as well as a clear escalation plan necessitated a global conversation to determine the appropriate course of action would drone on and on. The larger and more distributed the organization, the more important it is to identify those key participants, and more importantly, those things that may distract our team from the mission of completing the project. Of course, some items should cause a project to slow down, and may necessitate significant and prudent discussion on the course of action with regard to the specific requirements. However, these occurrences should be the rare exception.
- Internal / External
- Supplier / Customer
- Direct / Indirect
- Real / False
- Continuous / Intermittent
- Severe / Cursory
- Correlated / Inverse
This contrasting perspective or view of the potential stakeholders can help us consider the range of possibilities of stakeholder involvement and the requirements or constraints they may represent. For example, the customer stakeholder’s input is likely more valid and has more weight to it than a false stakeholder. The project manager and team should actively determine those impacted by the project and not just the sponsor. The ultimate goal is to understand determine the perspectives that really matter for success and find ways to manage the often conflicting inputs. To understand we can use tools such as:
- Power / Interest Grid
- Stakeholder Analysis Matrix
I have seen somebody post a lengthy discussion on the politics of project stakeholder management on LinkedIn. It was received with a certain measure of ridicule. However, projects are executed by people. People are not fungible, and at times are not perfectly predictable. They come with biases, and experiences that can greatly help aid the project or create a great chasm between the project objective and what is actually achieved. To that end, understanding, balancing and monitoring these inputs are required, along with processes in place (such as a decision escalation process) by which all will be governed are necessary.