Engaging the Hidden Stakeholder in Product Development

How often have you been well down the development path only to suddenly be derailed by a new requirement? How often did that requirement come from someone you didn’t even know was a stakeholder?

Changing requirements, either due to scope creep or incomplete project definitions, is one of the leading causes of late and over budget programs. One of the most challenging tasks is gathering and synthesizing the project requirements. That task is made significantly more difficult when the relevant stakeholders aren’t included in the beginning.

Although there are other facets to this problem, this blog will address two issues that affect almost every program: the first is identifying all the stakeholder and the second is getting them to be engaged with your development project.

Identifying All Program Stakeholders

While identifying all of the stakeholders is probably the easier of the two, there are almost always more stakeholders for a program than it would initially appear.

There is the external customer who we might have the opportunity to talk to but is more likely represented by sales and marketing. There are the supporting groups, which include manufacturing, service, applications, and documentation. Sometimes finance and commodities may even be involved. Finally, you can always count on the fact that executive management will have a stake in the program.

It may be useful to answer the following questions to help uncover additional stakeholders:

• Who else is interested in the outcome of this project and is not already on the project team?
• Who else will be impacted by this project, both in the factory and in the field?

Walking through the internal processes of development and product launch is an effective way to discover who all the stakeholders are. For example, when will financial approval of the project be required? When will Purchasing and Supply Line Management become involved? Walking through the project approval steps can bring these customers to light. Other engineering departments may be overlooked until you discuss how the program interfaces will be handled and if there are other potential applications for the design. Testing and applications engineering are other stakeholders that may appear when you walk through what happens as the product is introduced.

Sometimes we deliberately avoid certain stakeholders for fear they may have different expectations of the program. Although it involves a little extra work, it’s better to discuss everyone’s expectations up front as it is almost always more difficult to negotiate them later because surprises late in the program may cost far more time and money.

Getting Program Stakeholders Engaged with Your Project

Typically, the project manager’s job is to identify the specific person responsible in each functional group. This is often easier said than done, which leads to the second part of the problem. Getting stakeholders engaged can be difficult, especially in the multi-tasking, multi-project environment of most companies. It’s a mistake to assume that once a person is assigned to your project, they will begin working on it immediately. It’s also a mistake to assume that they know the type of support your project needs. The instances when people are dedicated to just one project at a time are few and far between. Supporting your program is probably just one more added responsibility for many stakeholders.

The first step in gaining their attention should be educating them on the value of getting an early start on the project. Provide tangible examples of how early planning will save them significant time and energy later on and how it will result in a much better product. A common example is the software interface: if protocol requirements are clearly stated up front, compatible software and hardware can be incorporated, avoiding a costly rewrite of the software down the road.

Sometimes a lack of stakeholder engagement isn’t a lack of desire, but simply a lack of time or personnel. It’s tempting for the development team to press on and ignore requirements when there is no representation. The project may be significantly delayed as missing elements are revealed piecemeal and then required to be implemented.

Successful project managers can fill in these gaps by drawing on their own experience. By developing good working relationships with these groups and taking the time to understand their needs, these project managers can bridge the gap until a qualified representative is available. You can gain a lot of latitude from the supporting groups if they feel you understand their issues and that you have made a sincere effort to accommodate their needs. A good project manager can also leverage stakeholder time by identifying the parts of the program that specifically impact them. Distilling the issues allows critical questions to be asked in such a way that the customer can answer them without a great deal of effort.

How Owens Design Can Help

Finding all the customers and gaining their active participation is a key step to achieving overall customer satisfaction. Taking the time to seek out the hidden customers up front will minimize surprises for everyone. Seeking creative ways to include them in the process with relevant questions and process reviews while leveraging their time are effective ways to gain their active participation.

Owens Design can help you find and engage all stakeholders to prevent surprises and satisfy stakeholder requirements along with design, engineering and manufacturing support to ensure a successful project. Speak with one of our automation experts today to learn more.

Contact us to learn more about custom automation solutions

AIR Silicon Valley

AIR Silicon Valley, formerly Owens Design.

View profile