We are currently starting a research project on best practices to engage stakeholders on enterprise projects. We are just getting started with our research, but we have found that many organizations struggle in this area. Agile teams seem to do better than waterfall teams when they have a good product owner. However, they also struggle for a variety of reasons:

• Often a product owner cannot speak for all stakeholders; the product owner represents one view and is often biased towards their own view.
• The product owner is not a true user of the software and often does not understand how users perform their work.
• The product owner is not located with the team and communication does not go as well as planned.
• The product owner has many other responsibilities and does not have the time to devote to the project.
• Some organizations have used multiple people to play the role of the product owner resulting in confusion for the team.

Below is a list of 8 best practices that we have found so far in our research project for stakeholder engagement.

1. Treat Stakeholder as Partners

All parties involved on the project will achieve a better result if they work together and cooperate as partners. Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers – a partnership. Too often, the relationship between development and customers becomes adversarial. Managers who override user-supplied requirements to suit their own agenda can also generate friction. No one benefits in these situations.

A collaborative effort can work only when all parties involved know what they need to be successful and when they understand and respect what their collaborators need to be successful. As project pressures rise, it’s easy to forget that all stakeholders share a common objective: to build a successful software product that provides adequate business value and rewards to all stakeholders.

2. Requirement Stakeholders have Responsibilities too!!!  

Many teams believe that requirement stakeholders just participate in an interview or focus group and then have no other responsibilities on the project. It is no wonder that so many projects fail when this approach is taken so often. Stakeholders need to participate as a partner on the project.  This involves many other things, such as gathering background information for the project, documenting business rules, preparing a project glossary, etc.

3. Maintain an Ongoing Dialog between Users and Developers

People are much better at describing what they think they want and then able to describe what they like and don’t like when an option is presented to them.  In other words, it is best to work with stakeholders to identify what they think they want, produce something that reflects that understanding, get feedback from the stakeholders, and then update the solution to reflect our improved understanding.  The implication is developers need to work in a more evolutionary and collaborative manner with stakeholders to develop solutions that reflect the stakeholders actual needs. To accomplish this, developers must work closely and regularly with stakeholders. This is the goal of agile; however, stakeholder and developer collaboration continues to be one of the greatest challenges for development projects.

4. Keep Stakeholders Involved in the Entire Project Lifecycle

Often, stakeholders are interviewed or participate in a focus group and have no other contact with the project until the software is ready to be deployed. Stakeholders should be involved through the entire project lifecycle. They should participate in activities such as:

• Reviewing design documents
• Participating in software and prototype demonstrations
• Participating in retrospectives and capturing lessons learned
• Providing additional information for unclear requirements
• Building test scenarios and test cases for user acceptance testing
• Performing user acceptance tests
• Approving changes to requirement specifications
• Defining transition requirements
• Preparing the organization for change

5. Ensure all Stakeholders are Identified

Too frequently, project teams do not spend time trying to identify the right stakeholders. The most recent PMBOK(R) Guide finally recognizes the importance of identifying stakeholders by making it a new process. Take a tip from this important change and help your project succeed by properly identifying the stakeholders – those who are affected in any way by, or could influence your project in any way.

6. Make Project Information Transparent to Stakeholders

Today, for most organizations, the development cycle is a black hole. Requirements are developed, and then requirement stakeholders are in the dark until the system is ready for deployment. Usually, stakeholders are not even given a copy of the business case, the project vision, or the project objectives. How can they provide meaningful input without this information? After the requirements phase is completed, the information void gets even worse. Except for possibly being able to view the project plan and maybe receiving occasional status reports which are often presented only to the project owner, the stakeholder has no idea where the project is really at. Are we 50% complete? 75%? There is really no way to gauge it if the client is left out of the development loop. So, the first benefit to project transparency is being able to accurately understand where you are in the development cycle. But transparency brings other more striking benefits. If you can see what tasks the team is working on, review the latest internal project plan, download the source code, read the latest technical documents, etc., don’t you think the team is more likely to be on their toes? If development knew the client was watching, they would try extra hard to get things right the first time and avoid costly refactoring. Transparency improves productivity and accountability.

7. Use Collaborative Technology

A recent survey of requirements management tools found that 91% of participants used word processing programs to define requirements.  But large word processing documents are not easily reviewed, shared, or amended across the cross-functional teams of business and technology users involved in a project roll-out. Reviews of large text-based documents often results in missing requirements or defects not detected. In addition, using documents, feedback from stakeholders rarely occurs until the individuals are affected, which can be as late as during testing or development.

Instead, requirements development should be incremental, iterative, and collaborative.  Stakeholders should be able to review requirements as they are developed and make comments when they feel that the requirements do not address their needs. Organizations should use a collaborative tool, such as the Enfocus Requirement Suite™ to define requirements and not a word processing tool that was never designed to develop or manage requirements.

8. Monitor Stakeholder Engagement

Project managers and business analysts should monitor stakeholder engagement and take corrective action when needed to ensure stakeholder stay engaged.  This may involve sending a simple email or telephoning the stakeholder to ask why his or her participation has dropped off.  RequirementPro tracks activity by stakeholder, so that project managers and business analysts can see when was the last time the stakeholder contributed and view the extent of their involvement.