When I first started working at CDL, I was not used to the academic organizational culture. I was coming from a very different environment, that of the Federal Reserve Bank of San Francisco, which has a quasi-governmental, quasi-corporate culture.
One of the first things I remember noticing was that project governance was distinctly different at CDL from what I had known. For example, I had always identified the project sponsor as the single individual who owned the budget for and made final decisions about the project. On an exceptional basis, the sponsor could be a sponsoring group rather than an individual.
At CDL and for the UC Libraries, I’ve learned that often the two functions–who pays for the project and who makes decisions about the project–may be entirely independent of one another. In a very real sense, there may be no single (or group) project sponsor. Within this kind of context, I believe it is especially important to think carefully about the project stakeholders.
And, typically, our projects have many stakeholders! As the project manager, our special challenge is juggling the complexity of relationships, while running the actual project.
I’ve put together a short slide deck with one technique for how to do this. The basic idea is this: make a distinction between those stakeholders from whom you would accept a (scope) change request and everyone else. The first group is the select core of primary stakeholders, and these are the people you have to treat in a special way. (I detail this in the slides.)
If the core is still rather large–more apple than core–then I recommend that spending some time up front planning a rational decision-making path for change requests. This may involve negotiating some level of organization for the stakeholder groups. In other words, if you will accept change requests from several groups and individuals, consider making an arrangement with the groups to use a single, empowered, representative for their project-related decision-making.
Any thinking you can do at the beginning of the project about how to handle change requests will be time well spent. I have never started a project that I have completed without having received a single request for change to the original scope. Have you?