The Art of Identifying and Involving Project Stakeholders

In one of my first medium scale projects I recall that my manager asked me what human resources I needed for the project and when. Quite naturally, my immediate answer was only the technical team members. Obviously, I couldn’t be more wrong. Fortunately I could rely on my teammates to back me up and correct me but that’s already another post. Since then, I have gradually learned that the identification of project stakeholders in a multidisciplinary process is no less than an art. It is not just the identification but also the timing of when to get them involved in the project. This post is obviously written from a System Engineering point of view.

Problem Statement

There are many stakeholders in a product development process. When there are a lot of people involved in something, no matter what, each person tries to swing things his way and often the different parties involved all pull in different directions. Moreover, having a dominant stakeholder present too early in the game may shift the whole development process sideways. On the other hand, the impact of missing out on a major stakeholder whose pull eventually changes the basic product and system requirements could be disastrous. For example, I recall a case I had where there was a huge discussion at the very beginning of a project about the exact phrasing and testability of a set of system requirements only to discover that all were changed a few months later.
So our problem statement of stakeholder identification is realizing who our project stakeholders are while having them involved exactly when needed and not creating unnecessary deadlocks and overheads in the development process.

Project Stakeholders in a Complex Project

A summary table (see below) for all potential project stakeholders, in which kind of projects you will need them and when is the earliest they should be involved and to what extent:

Project Manager (PM)

At the outset not every project has a project manager. The project manager, no matter whether this function exists or it is taken on by the lead engineer, is obviously involved from the conception of the project until its conclusion. Exactly as with the System Engineer (SE) the PM is a “mega-stakeholder” which means that the PM is in a position to assign tasks to other project stakeholders. However, this does not mean that the PM has to be present at each and every meeting. The involvement of the PM and his drill-down into the day-to-day of the project is entirely subjective. A good SE – PM relationship is when they meet several times a week, they are both aware, in general terms, of what the other one is working on but are unaware of the details of the other’s daily tasks.

Product

Very much like the project management, the product must be involved in the project from the very beginning, including infrastructure projects where in a lot of the cases we tend to keep them away from the project’s day-to-day. Product team must be there every time we have a technical tradeoff that impacts the implementation in a way that the end client feels it. But we have to be careful though. There are a lot of technical tackles, especially at the beginning of the development process, where we are tempted to consult every tradeoff with the Product team. I don’t have anything against consulting, but eventually if there is no impact on product requirements compliance the decision is fully technical and we have to make sure that the right decision is/was made. Keep Product in the development loop in such a way that there is no blockage in the development process flow.

Marketing

There is a bottom line for the products we develop and manufacture. The company has to be able, eventually, to sell them to our clients. It means therefore that every new feature and product implementation has to go through marketing, even if just for their information only. I had a case where a Marketing rep came to us in one of the R&D sessions and asked for a new feature only to find out that it already existed and had been implemented two SW versions beforehand. Bear in mind that in some fields the Product and the Marketing are under the same department and in the medical industry sometimes the marketing and the Clinical Affairs (that appear also under professional experts) are mixed together. Marketing is the end client representative so this team is free to expose information to the clients and consult with them to get their inputs.

Professional Experts

Professional experts are the functions inside or outside the organization that represent the client. If it is a medical device development the experts would be the Clinical Affairs team or physicians from the relevant field and if on the other hand it is a high-end motors inspection tools development the experts would be top-level mechanics. In most cases you would want their advice very early in the feasibility process and somewhere in mid-development to verify that you are on the right track. Other than that, it is entirely up to marketing and company internal experts as to how much they would like to involve the potential clients throughout the development process as part of the marketing strategy. I wouldn’t involve the professional experts in each and every feature being developed since the overhead could be enormous. Having said that, I would give them a taste every time some big feature is developed and take the opportunity to see all the little features that were added in between.

Finance

The project has to be budgeted and we must comply with this budget. The finance is an integral part of each and every project. However, we do not have to keep the finance on our speed dial all the time. Projects with properly planned milestones would involve the finance towards the milestone to understand how we are backwards and forwards. I would also include finance in risk reviews where we present the top budget risks of the project.

Supply Chain

Supply Chain is the team that is responsible for the purchase flow of material mainly during manufacturing. They are also the ones who are responsible for the final product’s Bill of Material (BOM) price. Supply Chain’s presence is particularly important in projects that introduce new HW that was not part of the company’s portfolio prior to that specific product. All HW related sustain development and end-of-life material must include the Supply Chain team. You would want to involve this team between the middle of concept reviews up until the end of integration in an R&D project and obviously all through product sustaining projects.

Purchasing

Purchasing, when it is not under the same roof as Supply Chain, are the ones who are responsible to get us the required material for our development and afterwards manufacturing processes. You would want them in any HW related project and we have to have them by our side at all times. They have to be aware of our needs, so the material will be there when we need it.

Testing

There is no project that does not require testing (or V&V, QA or any other acronym of your choice). There are multiple junctions in the development process where the testing team must be involved: product requirements and initial system requirements (as reviewers only) and finalization of system requirements are the most crucial. Remember that you have to allow sufficient time for the testing team to come up with their own jigs and features which in their own right may need substantial development processes.
BTW, there are SW teams that do the development and the testing inherently and deliver out an already checked SW version. This is usually employed in SW only companies.

Regulatory Affairs

Regulatory Affairs team deal with everything that has to do with having the final product approved for use in the client’s country, which may include standard compliance and certification, industry regulations and so on. This team has such a heavy weight in the medical industry when it comes to submission to the different medical regulatory organizations like the FDA or EU-MDR so that a project may even have a regulatory strategy in its own right. In other industries you may find this function under the same function as Legal (see below). You would want them in your meetings when you detail with what the product is and how it is achieved. It would be a shame to discover that a perfectly working product cannot reach the client in a certain country because a certain laser we used in the product is illegal in that country. In addition, regulatory compliance forces us in to test and certificate the product by an external party, which has to be taken into account (usually at the end of integration or beginning of manufacturing).

Legal

Legal deal with all the “lawyerly” stuff: contracts, confidentiality, patent infringement etc. You would want them involved early in the project to verify that no legal matters prevent you from continuing your project. Other than that, we have a lot of contracts with different vendors that need to be approved legally, so as not to be exposed to unwanted issues.
Bear in mind though that Legal is divided roughly into two: “enablers” and “disablers”. The enablers will let you work uninterrupted and will find a legal way to have everything done and most importantly, will stop you only when something bad is about to happen. The disablers will first stop you and only then will allow you to continue working. Know your team. If dealing with a disabler make sure to take it into account when estimating the timeline of the project.

Manufacturing

Manufacturing representative is required in HW related projects and sustain projects. In sustain projects they are one of the main stakeholders as the product is in their absolute realm already. In R&D projects you would want the manufacturing reps to review your outputs somewhere around the end of the design process but you would want their inputs for the system requirements right in the start! It is very important to have prior product versions’ mistakes corrected in our current product. Not all will be fixed as it is a part of the Project Management to decide the contents of the project but at least we would know what has to be fixed.

Support & Service

I am going to be very careful here. In my opinion Support must be a part of the project from the very beginning to the very end. Why careful you may ask? You have to verify that the meetings do not become Service strategy meetings that will take over the project and create constant hold-ups on the one hand and on the other hand you do not want to waste the Service reps’ time. Again, know your team. If constant hold-ups are expected have the Support & Service team involved only from the beginning of integration where the different support procedures and playbooks are being conceived.

Management

By Management I refer to the department\company management (top-brass ). Primarily, it is up to the PM to keep the management happy. But eventually, we as technical leads, also have the responsibility to keep the top-brass happy. Periodical meetings usually do the trick. When a major issue pops up it is also important to give an update to the management who always prefer to hear the bitter truth rather than non-existing sunshine and rainbows. Also be on the right side of politics, give them success stories so that your name will pop up with the next promotion opportunity. In my experience the best way to do this is over lunch in an unofficial atmosphere.

HR

I thought very carefully whether to have Human Resources as a project stakeholder or not. On the one hand HR do not have actual shares in the project or the product itself and on the other hand, good team HR knows everything (I mean everything!) that is going on in the company. You may get a lot of assistance from them, solving the team problems. I would keep HR’s involvement more or less top level so they will know where the inter-personal issues are.

Technical Team

The technical team has to be involved according to the technical content of the project. If the technical representative is involved, no question about it, he\she must be involved from the initial system requirements stage and onward.

• SW – all project that are not sole HW versioning and updates.
• Algo – all flow related and processing projects. GUI features for example are not included.
• Physics & Optics – all HW related project, and all vision\signal processing projects.
• Mechanics – all HW related projects. Bear in mind that even if we just change laser vendor or a power supply vendor with a model that has “the same mechanical dimensions” you would want mechanics rep inside the project.
• Electronics – all HW related projects that are not sole mechanics replacements.
• Control – all motor and control related projects. Mechanics replacement of a moving part is also included.
• Research & Innovation – The team in Research & Innovation touches on so many aspects of the system in their day-to-day work and as such, they have vast knowledge of how things work. I would keep them involved at least until the final design stages in all the multi-participant meetings even if they do not say a word.
• System – System??? Why is this here? Well, as mentioned before, sometimes the project is run by a technical lead that comes from a different discipline. You would want the System Engineering present when the project has its effect on two or more technical disciplines. For example, a camera choice project for an optical system must be led by a System Engineer as his task touches on so many disciplines: SW, Optics, Mechanics, Control, Electronics and maybe others. In addition, in many systems of systems architectures each sub-system is managed by a different System Engineer so you would want to get the other SE’s involvement in your project for the interface between your two sub-systems.

There are more specific stakeholders that may be added to the list (like Quality, Storage, Packaging etc.) depending on your industry. If you look carefully at the list above you can find the closest related discipline and apply the guidelines to it.

Ego is Also a Stakeholder

The next paragraph is neither engineering nor management process related however it may give you a tip that will change the way you manage your invitee lists for the upcoming project meetings. Always remember that all of us bring our egos and dominance inside the room with us to the meetings and that regardless of our role in the project. If a certain stakeholder constantly takes the meetings sideways because of his\her own reasons, try to see if there is a way to bypass his presence in this project’s phase until his\her inputs are an absolute must. We are all human – some teams work better together and some don’t. Since we must play the hand with the cards we were dealt, be smart and keep the disturbances away from your project. If you do it responsibly, no one will hold it against you.

That’s it for this post. I have given a few guidelines as to who to call and at what stage of the project development process for the different potential project stakeholders. Though I had to make a few medical exceptions, I’ve tried, without going into details into a specific industry, to make this post as general as possible. I hope you will find it useful.