Identifying and Working with Stakeholders – Section 1
Identifying and Working with Stakeholders – Section 1
A stakeholder is a generic term for a person or a or a group of people who have an interest in an initiative and will be affected by it (directly or indirectly) or influence it. In other words, your stakeholders may not necessarily be a part of your project team, so you may have to think outside the box when identifying them.
Consider a project to create a new application to support order fulfilment. The order fulfilment, warehouse and distribution departments are stakeholders, but how about the internal technical support desk? They aren’t part of the project team, but they’ll be impacted by the initiative because they’ll field technical support questions when the system rolls out. This role makes the people in this group stakeholders.
Reviewing a Who’s Who of Potential Project Participants.
Many roles are required to complete a project successfully: management roles (for providing the information) and other roles (for creating and delivering the right solution). Note: Even though we use common job titles to categorise the different roles, don’t get hung up on the titles. It’s more important that you recognise what roles are needed for what purpose. The titles used in your company may be different.
Starting at the top with management
The people on the management side hold titles such as an executive sponsor, account manager, product manager and project manager. These people manage the project and business areas and are generally the highest-ranking member of the project.
Executive sponsor
The executive sponsor is the raison d’etre of the project or initiative – the person who initiates the project has a vision of what the end-product should be and comes up with the project to accomplish it. The project may be integrating a commercial off-the-shelf (COTS) tool or improving the efficiency of a claims process. The executive sponsor also provides the funding for the project (after all, he’s the one who wants it done).
An executive sponsor:
- approves project scope and signs-off requirements
- is most interested in high-level information and how it relates to the funding of the project
- generally, isn’t concerned with the detailed, day-to-day operations and minutiae of the project
If a stalemate regarding the project’s direction ever occurs, the buck does stop at the executive sponsor. Why? Simple: He’s the one paying for the project.
Account manager/product manager
The account (or product) manager may hold a higher-level manager title, but this person defines the overall requirements and marketing approach for the product. Account/product managers are representatives of the external customer; they are the intermediaries between the external customer and the business, finding out what the customer wants and creating product requirements based on that information.
The account or product manager:
- makes decisions regarding project direction
- reviews project requirements and may also review the overall project
- generally, has decision-making authority
- is more involved with the project than the executive sponsor
Note: Don’t get caught up in the exact title of the person performing this role. Someone with the title of the project manager or some other title may play this role.
Project manager
The project manager (PM) is responsible for managing the project, including the project plan. The project scope and deliverables, and the work breakdown structure (WBS). The WBS is the detailed task list outlining who is responsible for each task, the amount of time to complete, and the dependencies each task has on another. During project execution, the PM ensures the project scope continues to align with the project objectives, and he raises any concerns with the adjusted project plan, including any missed dates or expired deadlines.
As the project moves forward and new opportunities or product features are discussed, the PM ensures that the changes in scope are relevant to the scope and align with the project goal. The PM will probably look to you for help with understanding the impact that a scope change has on the project; he then reports those scope changes in terms of the project impact on the executive sponsor.
A project manager:
- identifies and staffs the appropriate project team members
- creates the project plan for the overall project and seeks input on the requirement plan from the business analyst
- reports on the status of the entire project
- manages the project risk plan and executes risk response if a risk is realised
- addresses and overcomes project barriers affecting the completion of the project
- Looks to the BA for updates on the progress of the requirements phase
- Manages the project change control process, working with the BA to address project impact during change control
Sometimes, you may find yourself playing the dual-role of BA/PM, which can be a challenge because of the natural conflict between the roles. The BA function focuses on analysing items of the project; the PM function focuses on meeting the project dates, If you tend to like one role more than the other, be careful not to concentrate on one at the expense of the other.
Seeking subject matter experts
Subject matter experts (SMEs) are – surprise! – experts in a particular business or solution are you are working in for your project. These are the people you interview to craft your business requirements. You work with two kinds of subject matter experts: domain experts and implementation experts.
Domain subject matter experts
Domain SMEs are the people who provide project objectives, potential problems and risks from the business perspective. They are business people, and their job is to understand the business.
To get the right domain SME for your project, make sure you understand the subject matter expertise and who can best explain it. For instance, if you’re looking for information about a Warehouse Management System (WMS) you probably want to talk to the Head of Operations, but if you’re interested in the maintenance of that system, you want to talk to a Warehouse Manager who is actually involved in the day-to-day job. In any domain, make sure you’re asking the person who performs the job. Other people may have an idea about how it’s done, but the best person to ask is the person who performs the process.
Domain SMEs also set the priority of the project objectives and the requirements based on what they need to accomplish from the business perspective. You may help them prioritise by giving them guidance on impacts and analysis, but ultimately, they own the business area and the prioritisation. Understand that addressing the most critical business requirements (business needs) is the value attached to the prioritisation on the requirements, so it is very important to understand the difference between the business requirement and a solution.
A domain SME:
- provides information about the business and specific business terms
- provides detailed requirements related to business processes and data
- offers suggestions as to potential solutions to the business problem or opportunity related to the project
- assists in defining project scope
- works with BA on user interfaces, business processes, data and business rule definition
- reviews detailed requirements documents, user interfaces, business process diagrams and other deliverables to validate that the project and solution is right for the business
Because domain subject matter experts typically work within the problem area for a long time, they often figure out workarounds and solutions to their problems and want you to use them as the project solution. Don’t take their word for it, though; forge ahead with your processes. You may find that the SMEs’ solutions are viable in the end, but you must give them a fair analysis.
Implementation subject matter experts
The implementation SME is the one who provides technical expertise on how to develop a solution to solve the business’s problem. In a software environment, you are talking about someone like the developer, lead developer or software architect. In a warehousing business area, it may be a logistics expert or warehousing engineer.
Implementation SMEs provide possible solutions to solve the business problem and can respond and provide guidance about other possible solutions. For example, if a solution or screen design may not be possible with the current limitation of tools, the implementation SME will work to guide the solution team down a path to create a feasible solution. Generally, the majority of the resources come into the project at the phase when you are creating some sort of project solution.
An implementation SME:
- guides the project team on possible solutions to the business problem
- works with the BA to create user interfaces and makes sure the interface supports the real work of the business
- ensures that the suggested solutions are feasible from an implementation perspective and provides guidance on the impact of alternate approaches
Adding project support personnel
Project support personnel are those who support the project in various ways as it moves along. They are usually not assigned as 100 per cent full-time resources on any one project; rather, they function as specialists supporting multiple projects within an organisation. They allocate their time based on the project priority within the organisation. Think of these people as advisors or consultants.
For instance, unless you’re building an application to support the legal department, you probably don’t need to understand the legal department business processes. But a few members of that department may be stakeholders within your project. They may give you guidelines about how long to store customer data or what types of customer data you’re allowed to store. You may have to run a solution the group comes up with by legal to get it approved. Of course, legal isn’t the only department that falls into this category. If you’re redesigning user interfaces for external customers, you may need a usability engineer or information architect.
Project support personnel:
- maybe involved in providing the group with constraints for the solution based on what the team is designing
- are assigned to your project and act in a consulting capacity
- are experts in the subject matter they’re working within and are brought into your project as a project support person (PSP)
- guide the project team within their particular advisory subject matter area
Organisation change management professional
The organisation change management professional facilitates acceptance of solutions, creates the change management plans and advocates the need for the change. Usually, you find organisation change management professionals assigned to big, highly strategic, company-wide projects such as switching 4,500 account executives to a new sales system.
As a BA, do you find yourself do those things? You probably answered yes, and you’re right: on many projects, this role usually falls to the BA rather than to a separate resource.
Regulators
Regulators are the people and organizations creating guidelines and possible constraints on your project and solution. Think of them as the legal department within your organisation; they specify what you can and can’t do with your project. You may be implementing a solution to ensure that your organisation adheres to industry or government regulations. Additionally, they may guide how you have to produce some of your deliverables. In the case of pharmaceutical manufacturing in the UK, for example, certain documentation must conform to the MHRA standards to be accepted by the customer. The regulators also impose audit standards around the project.
Technical writer
The technical writer writes the software manuals, online help and web page help text, and user training manuals. The tech writer understands how the solution functions and the audience who will be reading the produced tech manuals. Technical writers are mainly concerned with requirements such as the workflows (or process maps/diagrams) and the external agents or actors (the people who will be using the system). Although they deal with technical “stuff”, they support the project only when necessary.
Turning to technical personnel
The technical personnel are those resources (the corporate way of saying people) on a project who help address how technology supports and fulfils the business requirements, If the solution for your project is a technical one, they build the solution. The earlier they are involved in the project, the better. They can guide if the suggested solution isn’t technologically feasible.
Some of the duties technical personnel perform include designing the solution and system security, system architecture and network architecture. They also create interfaces with other computer systems and databases.
Technical personnel also assist the testing effort by unit testing the programs and modules they write as part of the proposed project solution. They make sure the modules work well independently before integration testing. They may also help with integration testing.
Technical personnel:
- are interested in how the software needs to support the business need.
- need to understand the business and solution requirements so they can code a solution that matches what the business needs.
- interact with the BA to fully understand the needs of the business
- work best with others who have some technical knowledge. You don’t have to be able to speak in a computer programming language, but you need to know the basics that are relevant to your project
Make sure that technical personnel’s efforts support the original business requirements and functional design. You don’t want the technical personnel to develop a solution that does not address the business need. A programmer who states, “I know what the business needs better than the business does”, isn’t the kind of programmer you want on the project. He’ll program what he thinks the business wants even though the business states something completely different. The best way to overcome this issue is to bring the programmers in during the design phase or earlier. Then they can offer suggestions and make the user interface work within the boundaries of the system. When they are involved early, they have a stake in the solution (because they helped design it) and will be hesitant to change it unnecessarily during the implementation.
Usability or UX engineer
Usability or User Experience (UX) engineers primarily design user interfaces. People in this position have experience with how humans interact with machines and they bring insight to the field on a man-machine interface. If you’re working on a customer-facing application (an application used by public consumers versus internally or on the backend), you’re probably more likely to have one of these people on your project. Think of Apple. Many people think Apple’s products are easier to use than a competitor’s product and that’s because Apple had people that understand how users interface with a product and address tat need to make it easier.
Usability or UX engineers also assess usability for user interfaces they didn’t necessarily design and may assist with testing for defects that may inhibit usability of the solution.
Quality assurance & Testing personnel
Quality assurance (QA) & Testing personnel are responsible for assuring the team delivers a quality product. On a project, their first initiative is to review the project requirements and write test plans. These people are a very big help for the BA, so you want to befriend them early on the project. They look at every requirement to make sure they can test it and verify it. If they can’t verify it, then the requirement is not clear enough. This will mean the technical team won’t have clarity on how the solution should address that requirement. By looking at your requirements early on, they can filter out ambiguous statements such as “ The software should be easy to use”.
QA & Testing folks are also responsible for setting up the test environments, writing test cases, executing and overseeing testing activities, and reporting on following up defects.
Database administrator
The database administrator (DBA), sometimes called data administrator, looks at data from an enterprise-wide perspective. The project you work on will most likely use data. Instead of creating a brand-new database, the DBA looks to see where data already exists within the organisation and whether it can be reused for the project. He also provides data-naming standards and conventions.
As a BA, you may consult with a DBA on logical data modelling techniques. Your job isn’t to design a database, but you should work on the logical relationships from a business perspective. The DBA can help with that from his data knowledgebase. A DBA generally wants to help because he’s ultimately responsible for designing the physical database.
