Chapter2-3:Project Stakeholders

Project Stakeholders

The refinement of high-level requirements and the project selection process is where you will first interact with a very important group of people: stakeholders. You have probably seen or heard references to project stakeholders. But what exactly is a stakeholder and why is it important to identify all your key stakeholders?

A stakeholder is a person who is either actively involved in the project or is impacted by the project. Stakeholders have something to gain or lose, and you need to meet their expectations. Stakeholders may be interested and involved with the project at different phases.

Some stakeholders may not support your project. A project that creates a major impact on operational procedures may be viewed as a threat. Change can be a frightening proposition. Projects that result in a more efficient business operation may cause a staff reduction. Fear of job loss may cause certain people or organizations to work against a project.

Dealing with your stakeholders is where you will put to use many of the general management skills we discussed in Chapter 1. Individual stakeholders may have very different priorities regarding your project, and you will do a great deal of negotiating with your stakeholder group. Building consensus among a group with diverse viewpoints starts with up-front negotiation during Project Initiation and continues with ongoing communication throughout the life of the project. In Chapter 6 we will discuss Communications Planning in detail, including how you define and implement a communications plan geared to the needs of individual stakeholders.

Set up individual meetings or interviews early on in the project to get to know your stakeholders and understand their perspectives and concerns about the project. These people will not go away, and if you ignore some of your stakeholders, the issues they raise will become more difficult to resolve.

Project Sponsor

The project sponsor is a special type of stakeholder. Although projects have multiple stakeholders, whom we will discuss shortly, there is (or should be) only one project sponsor.

The sponsor is the person who champions the project throughout the organization. The sponsor acts as an advisor to the project manager. The project manager keeps the project sponsor informed of current project status, including conflicts or potential risks. The project sponsor typically has the following accountabilities:

• Provide or obtain financial resources.

• Analyze key stakeholders.

• Negotiate support from key stakeholders.

• Monitor delivery of major milestones.

• Run interference and remove roadblocks.

• Provide political coaching to the project manager.

  Note

  From time to time you might hear a reference to a person called the project champion. The project champion is generally a technical person aligned with the project for the purpose of supporting the project. She is not necessarily one who has a lot of power, but is one who understands the goals of the project and can help you keep the project moving forward.

Other Project Stakeholders

A complete list of stakeholders varies by project and by organization. The larger and more complex your project is, the more stakeholders you will have. Sometimes you will have far more “stakeholders” than you want or need, especially on high-profile projects. I recommend that you define who you think the other stakeholders are on the project and review the list with your project sponsor. He or she is often in a better position to identify what we refer to as “political” stakeholders—influential people in the organization who have expressed a desire to be involved in this project, without a direct or obvious connection. You do not want to ignore these people just because their role is not obvious, and your sponsor can assist you in identifying the needs of these stakeholders.

Some stakeholders are more obvious and much easier to identify. In addition to the project sponsor, the following are generic stakeholders you should find on most projects:

Project manager  We have already talked about the project manager in detail. This is the person responsible for managing the work associated with the project.

Project team members  These are the experts who will be performing the work associated with the project. Depending on your organizational structure, these people may report directly to the project manager, matrix report to the project manager, or simply be provided by another department. Project team members may be assigned to the project either full-time or part-time. Most projects have a combination of dedicated and part-time resources. If you have part-time resources, you need to understand the other obligations of these team members to make sure they are not being over allocated.

Your project team may include only people from other IT groups, or it may include other departments such procurement, legal, public relations, marketing, sales, and customer service.

Functional managers  If your resources are supplied by another organization, the functional managers who assign those resources are critical stakeholders. Normally multiple projects compete for the same resource pool. You need to establish a good relationship with your functional managers. Documented agreements on the amount of time a resource will be available to the project as well as the deliverables the resource is accountable for will prevent future misunderstandings. You should obtain up-front agreement as to your input in such areas as appraisal, salary increase, and bonus opportunity.

The functional manager is the decision maker in these areas. If you approach functional managers with these questions up front, there will be much greater clarity as to your role and your authority.

Customer/Client  The customer is the recipient of the product or service created by the project. In some organizations this stakeholder may also be referred to as the client. A customer is often a group or an organization rather than a single person. A customer can be internal to the company, as would be the case if you were on a project to install a server system for the sales organization. An example of external customers is the people who purchase a new feature.

End user  The term end user denotes the person who directly uses the product produced by the project. This term is often seen in IT projects to distinguish between the organization purchasing the output of the project and the group who will use it on a daily basis. As an example, the sales department may be viewed as the customer for an online order entry system, while the frontline sales consultants are the end users of this system.

End users may participate at some level in requirements review or functional testing of the product.

As you can see from even this generic list, your stakeholders represent a wide range of functional areas and very diverse wants and needs relative to your project. To keep track of everyone, you may want to develop a stakeholder matrix.

Who Are Your IT Project Stakeholders?

Typically your IT stakeholders will come from the corporate business unit(s) requesting the project. Because IT touches virtually every facet of an organization’s business, it’s very likely that as time goes on you’ll encounter a variety of projects from all or a combination of the business units that your particular IT shop supports. You’re likely to encounter three classes of IT projects that will affect specific groups of stakeholders: single business unit projects, multiple business unit projects, or enterprise projects. Let’s talk about each of these in more detail.

Single Business Unit Project

In a single business unit project, you might be approached by a representative from, say, marketing or sales, for example, to help design and build a system that meets a specific business requirement.

Often in such situations you’re presented with a system that the business unit is currently using but is not satisfied with. In a lot of cases, business unit stakeholders have already done some research into what they want and have some recommendations to offer for COTS applications that they think will meet their needs. As a project manager you should scrutinize the software very carefully because it may not meet the scalability requirements that larger shops have. Additionally, if the software being put forward is from another firm that wrote a custom application but is willing to “loan their code” you need to be doubly careful to make sure that the application being considered is solid, reliable, and, most important, supportable by your IT shop.

In some cases, the business unit has no idea about any other software applications that are available to meet a business objective or solve a business problem and they’re coming to you to formulate a project that fulfills the goal. You’re afforded much more leeway in a situation such as this. Generally speaking, COTS applications are so plentiful today that you will probably be successful finding a fairly close match to what the business unit is asking for. However, some instances may require that a new software application be written to custom specifications. It is up to you as the project manager wearing a systems analysis hat (or vice versa) to make the best educated decision about the proper approach to the solution.

Multiple Business Unit Project

Sometimes two or more business units can make use of a system in order to meet business objectives or solve a business problem. Document imaging and management systems (DMS) are an example of this. In a multiple business unit project, you might be approached by two or more business units that have determined that they collectively have enough capital funding to “go in together” on a DMS that they can all use.

Now your task has gotten more difficult because you have a variety of stakeholders involved, all with different agendas, but similar interests. Gaining consensus in such stakeholder environments will be the most important item of the day.

Additionally, you’ll be forced to understand each business unit’s logical flows in order to make collective sense out of the system that you design and build. One business unit, for example, may not require quality control procedures for incoming documents, for example, because they’re already quality checked by the sender due to some regulation or another. But another participating business unit does have a quality control step that they need to continue to maintain. Solving for such stakeholder irregularities makes for interesting project management issues.

Enterprise Project

Another interesting project is one that impacts the entire enterprise. What we mean by the word enterprise is the complete array of business units—everyone in the company or division is affected.

You may not be aware of it, but you’ve probably been a part of or at least interacted in some way with an enterprise project. Two distinct examples come to mind: your organization’s email system and its corporate intranet. All persons interact with each of these enterprise systems, and yet at most probably one group of IT people is involved with each respective system’s maintenance.

Real World Scenario—The Shared DMS

Marvin works as an IT specialist for a business unit in a company. His business unit managers have voiced a need for a DMS in order to scan in old documents and archive them in some DMS software. Any new documents will be electronically submitted and automatically populated into the DMS software.

Another business unit with similar needs has gotten wind of the project and approached Marvin’s managers. Together the managers of both business units have agreed to partner to procure and implement the new system. The other business unit does not have an IT department, so they’ll be relying on Marvin to assist with their implementation. They will be assisting by providing some funding for the project.

Marvin is not the owner of the datacenter, where the new DMS servers will be housed. This function is handled by the central IT shop (called “Ops”) responsible for enterprise operations. He will manage the software on the servers, but Ops will be responsible for maintaining the server hardware and the database on the system.

In this case Marvin has a very complex stakeholder environment. Ops and the other business unit are both stakeholders in the efforts that Marvin’s business unit is making. Success or failure can be had at the hand of any of these stakeholders. If, for example, the second business unit drops their funding, then the project is in jeopardy. If Ops cannot or will not manage the server, the primary business unit will have to find some other workaround, potentially resulting in increased project costs or duration or both. Ops must rely on Marvin’s training in the new DMS software in order to make sure that users can reliably utilize the system.

Enterprise projects bring interesting stakeholder issues. Who are your stakeholders in enterprise systems? Generally, everyone will use the system. So you have to look at representatives from each group as your key stakeholders, or conversely, at certain select groups as the primary stakeholder for the system. For example, when considering a new email system, your corporate records manager; that is, the person or group responsible for setting down document retention policies, will be a very important stakeholder in any decisions you make about the retention of email items. In a new corporate intranet project, all users will be stakeholders, but most likely the content providers for each business unit will be the key stakeholder for the project.

IT Project Team Members

The IT project team has several stakeholders in various positions. The IT project team is different than a team you’re assembling for a construction project. Construction workers work within their own areas of expertise (a plumber doesn’t necessarily care, or have to care, what the electrician is doing, for example). But in an IT team, you have individuals who have specialized in their respective areas of IT and who may well have a clue, perhaps a substantial one, about the other team member’s functions. A software developer has to be fairly database savvy, for example, because he or she will be working extensively with writing data taken from user input screens to a database somewhere. Database administrators (DBAs) must be extremely knowledgeable about the things software developers do, plus they need to understand how servers work and also how users connect to databases across the network wire. Server administrators must understand that their servers are there to support business functions—that the underlying network operating system (NOS) isn’t the sum total of what the server’s about. And woven through it all are systems analysts, business analysts, business subject matter experts, and others who are participating together to bring in the project’s deliverables.

Following is a list of the kinds of people you might expect to join you on any given IT project team, depending on the deliverables you’re trying to produce:

Software developers  Software developers are often called on to work on IT projects. This category of team member may also include folks who specialize in writing programs that run on application servers such as JBOSS, Microsoft BizTalk, or BEA WebLogic; user-interface developers; firmware coders who write software that works inside hardware devices; database stored procedure developers; and Internet/intranet developers and specialized module developers (for things such as printer and communications modules).

Server administrators  These team members are responsible for bringing up the servers (whether Intel-, mid- or mainframe-based) that will house your project.

Database administrators (DBAs)  DBAs are responsible for creating the database schema (structure) and associated requirements, plus planning out the backup and recovery methodologies for the data. DBA work includes the concept of reducing the table structures to their lowest operable form, a process called normalization.

Internetworking specialists  Internetworking specialists are the folks who handle the routers, switches, LAN cabling, and WAN connections.

Telephony specialists  The people who manage the company’s telephone equipment and operations are telephony specialists. It’s amazing how many systems today interoperate with telephony. Think of a telephone-based menu system, called Interactive Voice Response (IVR), realizing that a software developer had to write that code that intercepts the incoming call, provides a menuing system for the user to pick from, then routes the call back out to the appropriate party. The IVR software runs on a server but is connected to the telephony backbone.

Systems analysts  Systems analysts (SAs) are people trained and skilled in IT subjects, but who operate at the functional level of taking the system requirements and boiling them down to a system design specification that the system developers can use to build the project. SAs today use very cool software such as the offerings from Rational that help them quickly and accurately model the system from business flows.

Business analysts  Often one and the same as the system analyst, business analysts (BAs) are able to work at the high level of the business unit in order to understand their needs but are also able to interface with the IT folks to help them understand what it is the business unit really wants. BAs can be IT-savvy folks who come from the business unit, or business-savvy people who are in the IT shop.

System architects  System architects have a very technical level of knowledge about systems and are able to draft out the “blueprint” of the proposed system. Sometimes the system analyst can be the architect; other times, a developer or perhaps even the project manager is in charge of architecture. However, in larger systems, it is not unusual for project managers to use the assistance of an actual system architect.

Budget analyst  Especially in very large projects, a budget analyst is required to keep track of the project’s budget and associated expenses.

Security analyst  The security analyst is a new, yet indispensable character on most systems project teams. The security analyst is the person who makes sure that all security aspects are ironed out. Security is a unique specialty and really requires, especially in mid- to large-sized projects, someone who has a firm background and understanding of the subject.

Technical writers  In larger projects a technical writer is put in charge of writing all of the documentation (with the exception of the comments directly entered into the code) for the project. This includes training documents as well as user manuals, help-desk “cheat sheets” and other documentation.

All of these people must be able to understand technical jargon and acronyms, and be able to fully function and get along with one another. It’s important that these people feel a sense of freedom to be able to question something that’s being done and to work closely with one another in making sure that the right decisions are being made going forward. There is little room for superstars or “Lone Rangers” (those who prefer to work alone and not associated with project teams) in efforts such as these. The project team must consist of a group of people who understand the project’s goals and who come together with a cohesive purpose. Otherwise chaos will occur.

Additionally, people on project teams must be great self-starters, able to work on their tasks with little guidance apart from the system design specification. System project teams are usually not a good place for a beginner to start out because you need folks who have some basis of experience for what they’re being asked to create.

As the project manager of a technical project team you must realize that you’ll be working with a wide variety of personality types and you’ll have to somehow manage the psychology of process accordingly. While you need to have a firm grasp on all of the technological ramifications of the deliverables being created, you must also understand team dynamics and how humans interact with one another in high-stress settings. You should be prepared to handle grievances, to mediate arguments, to gather around a whiteboard and draw out a logical function so all stakeholders understand it, to communicate in one person’s lingo what the other person is trying to say, and so forth. Clear, concise and adequate communications are essential in IT project management.

Real World Scenario—Matching the Project Charter to the Project Team

By writing a good quality project description, you’ll probably have a fairly clear idea of exactly the kinds of people you’ll need on your team before you even start assembling the team. Take, for example, the project description in the sidebar, “IT Project Descriptions”:

“IT will create a set of computer programs and databases that will allow the vehicle service department to track all warranty work performed on any given vehicle. The system will be intranet-based and accessible via browser from any computer in the environment. The database will contain fields to house all relevant pieces of information for warranty work performed by the department. Reports will be generated that can be electronically shipped to the vehicle manufacturer for reimbursement. Drop-downs using lookup tables will be provided on the user interface wherever possible to minimize data entry time and incorrect data entry. Consistency checking will be performed on key fields that require double-checking of the data (such as VIN).”

Clearly you can tell from this short description that you’re probably going to need at least one web programmer. You don’t know yet whether you’ll opt for Java, C#, or some other Internet programming language—that’s not important just yet. You also know that you’re going to need at least one DBA because there are databases to be created. You’ll doubtless need the assistance of a server administrator to assist you in placing the databases and software that you’ll develop. You’ll also need a good BA to help you understand the business processes and translate them into the computer programs.

As you drill into the project a little more, you’ll discover how many of each you need, but for now you’ve at least identified the relevant technology people.

Stakeholder Matrix

If you have a large project with multiple stakeholders, it may be appropriate to create a stakeholder matrix to help you keep track of everyone. A stakeholder matrix should include a list of the stakeholders with the following information on each one:

• Role on the project

• Needs from the project

• Involvement on the project

• Level of influence over the project

This matrix can be a useful tool to review during project execution, as conflicts arise. It can help the project manager understand and deal with various behaviors. It is of particular value if your project has some of the political stakeholders I mentioned earlier.

Since project stakeholders can move on and off the project at different times, it is very important that the project manager reviews the project charter and the project plan as stakeholders become involved in the project.