Software Development Stakeholders

The PMBOK® defines stakeholders as any persons or organizations impacted by the project. They all have interests, involvement & influence on the project’s success. Most stakeholders are common to all types of projects, but this list is geared towards Software Development, & is being posted in an attempt to provide a resource to Project Managers of Software Development projects. If you have had projects with stakeholders not mentioned here, please comment on it & I’ll modify the article to include them & give credit to any contributors.

Let’s look first at the most obvious stakeholder, the customer. By customer I mean the entity that has commissioned the project & will be paying for it. Their interest is concerned with the success of the project in meeting their goals for functionality, cost & schedule. They should receive status reports & delivery of the product or service based on their defined needs as stated in the Project Charter, Statement of Work, Contract, RFP, or Specification. As project managers we owe them the product or service, up to date status reports & delivery of value as soon as possible. In my experience, prototypes & continual feedback from the customer is the best way to ensure success, in so far as they share in the ownership of the development of their product or service. The Customer may be represented by a CEO, CIO, CFO, President, Vice-President or any other upper or middle management representative. What is common to any customer is that they want or expect a successful project. They are at least as interested as you are in obtaining it. In order to satisfy the customer, you will possibly need to satisfy other groups of people, users and operators in particular, & the consumer of the final product or service.

Vendors represent another class of stakeholders. In the case of external customers, you are a vendor to them. Treat vendors professionally, just as you would like to be treated, & you can’t go far wrong. A fellow Project Manager, Chris Alberts, reminded me of this in his response to my request for contributions to this list. He wrote “third party software, hardware, interfaces, surround code vendors...any third party services vendors also....I'd also deeply understand your environmental factors when looking at stakeholders”. PMP Jeffrey Spardy, another contributor, wrote “Along the same lines of what Chris added, vendors of competing solutions and vendors of complimentary solutions”. Competition may certainly be interested or impacted by the success or failure of a project, & I’d certainly look at them for ideas & risks & opportunities. Complimentary solutions, services, applications & products certainly belong in the list. When I did a project for the World Trade Center, even though it was a Software Application Project, it included Sun Microsystems, AutoCAD, interaction with MVS & an external database. Hardware maintenance was provided by a local NY service company. Most vendors’ interests & commitments are directly related to their potential income, either from licensing, support, rental, publicity or purchases. Their commitment to the project’s success is directly proportional to their income.

As Chris also commented, your internal organization will contain many stakeholders, regardless of whether this project is internal or external. These may include functional managers, PMO’s, sponsors, CEOs, CIOs, CFOs, Presidents, vice-presidents, division mangers & other officers. They also include your project team. Of particular interest might also be the environmental & organizational structure of your customer, since this will give clues to how the product or service will be used by or impact them. Another class of stakeholders might be represented by Government representatives, environmental interests, Professional organizations or societies, or other special interest groups.

With all this in mind, here’s an attempt at a list of possible stakeholders. For Interests, they are either interested in the project’s success or failure, or the project’s impact on their own work or interests. Influence is high if their opinions & feelings about the product or service will dictate the way the end product is designed or used, Medium if their opinions must be considered but don’t necessarily dictate the outcome, & Low if their opinions do not necessarily affect the project. For Impact, high means they can either stop or reject the project, Medium means they can affect schedule, cost or scope. Low means they have little impact on any of the constraints.