Stakeholder Management – Think 'Stakeholder Support' Instead

How many times have you heard the term ‘stakeholder management'? If you have been a project manager for any length of time, you probably have heard this repeatedly.

We need to think differently. Instead of thinking about how you manage the stakeholders, think about how you can work collaboratively to deliver your project or programme. Invest time and effort to build a great working relationship with the stakeholders; this will pay handsome dividends. Let’s look at some actions to help with this.

Benefits management and critical success factors

Agree on the critical success factors at the beginning of the project. This doesn’t need to be a long list. In fact, having five or ten critical success factors keeps the team and stakeholders focused on delivering the most important elements.

Ensure you can measure critical success factors to confirm they have been delivered. It's gratifying to review these after delivery and have stakeholders agree that all priority items were delivered.

Deliverables

Regardless of methodology, agreeing on and tracking deliverables is key to managing a successful project. Whether it is the deliverable from a sprint in Agile or a milestone in a Waterfall project plan, stakeholders will require updates on progress. Understanding, tracking and managing dependencies between deliverables is essential.

Be completely transparent with stakeholders. Don’t paint a rosy picture; ensure all reports and updates are accurate.

Stakeholder communication

Stakeholder communication is critical regardless of the methodology. A few thoughts from different projects:

On Agile projects, it’s easy to focus on the business stakeholders you are working with and assume they are updating the wider stakeholder community. For small projects this may not be an issue, but it could become a serious one on a large or business-critical programme. To add more detail to this, let’s look at two projects.

• The first one is a development project for a single department. The application is going to be used by this team only, and their manager is working on the project. Furthermore, the application will be deployed to existing infrastructure. In this scenario, stakeholder management should be covered.

• The second project is a major transformation involving multiple business and IT departments. PRINCE2 Agile is being used to manage this activity. Assume that people in the business and IT departments are part of the project team. You will communicate with them in the daily standups, but please keep in mind the requirement to update senior stakeholders on a regular basis.

Include good and bad news in the updates. Be completely transparent about the issues and challenges the project is facing. Stakeholders appreciate transparency and hate surprises. Always include the steps you are taking to resolve the issues in the communication.

Waterfall programme boards

The programme board consists of senior stakeholders with overall responsibility for the project's delivery. The purpose of the programme board is to support the project and guarantee proper governance. If the project team is unable to resolve a problem, they should escalate it to the programme board.

Agile project governance 

The governance procedures on Agile projects take a different approach compared to Waterfall projects. 

The main differences are the following:

• The authority to make decisions is delegated to the Agile teams. The main benefits of the Agile governance model are that it enhances an organisation’s overall Agile processes, and it increases the efficiency of making decisions when there is a requirement to escalate an issue.
• Collaborative decision-making is encouraged.
• Everyone responsible for delivery is involved in project governance. The governance process includes the use of planning meetings, standups, and retrospectives.
• Delivery managers, service owners, support team managers, technical architects, security managers, change managers, data architects and chief information officers may also support the delivery team. It may be appropriate for these roles to be involved in project governance.

The Agile governance model is based on the core principles as outlined in the Agile Manifesto. As a result, the governance process supports, but does not manage, the teams. The role of the stakeholders is to support the team.

In addition, regardless of methodology, you will need an efficient and effective way to convey risks to the stakeholders. Ensure that the project board understands all the risks you are managing.

Cutover risk management

It is imperative that you work with stakeholders to manage the cutover risk. Stakeholder engagement and support is key to effective cutover risk management.

A formal approach to cutover risk management will benefit the project and facilitate the Go/No Go decisions.

People will usually have different opinions of the level of risk associated with the cutover to the new system. This is understandable because they will be looking at the cutover from their involvement in the project and the perceived impact on their areas of the business. 

An overview of the risk, which everyone can agree on, is required. The Pathway IT Consultants Go-Live Risk Assessment spreadsheet is one way to achieve this. This approach has worked well on projects because it:

• Is based on 'Yes' or 'No' answers.
• Takes minutes to complete.
• It provides an objective assessment of the risks.

The spreadsheet can be used throughout the complete project lifecycle. At the beginning, the risk score is expected to be high. As the project progresses, it is expected to reduce. (If it doesn't, there is a serious problem.)

There will be some items that have an inherent level of risk that can’t be mitigated. For example, the first question in the spreadsheet on the following page relates to an application upgrade. If a third party has an upgrade scheduled that you must implement within thirty days of go-live, there will be a risk associated with this that can’t be avoided. Of course, a team will complete activities, such as automated regression testing, to mitigate this risk. However, an upgrade this close to going live will still carry an inherent level of risk.

It is an advantageous practice to review the risk items that can’t be mitigated at the start of the project to determine the target risk score. On some projects you will be able to mitigate the risks to a low or medium level, but on others the score will remain high despite the project team doing everything possible to manage the risks.

It is very useful to understand the expected level of cutover risk in the early stages of the project. Such knowledge focuses the team on risk mitigation, and the stakeholders will appreciate an understanding of the risks months, instead of days, before the cutover. The process also instils confidence in the stakeholders because of the level of control this demonstrates.

Timings of the Go/No Go meetings with the stakeholders

This will depend on many of the factors listed above, but in general terms:

• One department is affected by minor changes to the current infrastructure.
• First meeting two months before the target go-live. 
• Medium implementation with multiple departments involved.
• First meeting three months before target go-live.
• Complex implementation affecting most or all departments
• First meeting four to six months before target go-live. 

A good cadence is monthly meetings, following on from the first one for all the examples above.

In addition, you may want to schedule a final Go/No Go meeting a few working hours before the start of the cutover. This meeting is brief and serves solely to confirm that there are no issues that would prevent the cutover. It includes key stakeholders and representatives from the project team and the IT support team. At this point the go decision has been made. This is simply a final check to ensure that no changes have occurred in the business, IT, or external factors that would prevent the initiation of the cutover for go-live.

Examples of factors that could halt the cutover and go-live process at this point include severe weather preventing the team from going onsite (if this is necessary for some or all activities in the cutover runbook), a P1 technical incident, or a major business issue affecting BAU operations.

Some things to consider when scheduling Go/No Go meetings:

• Please distribute the slide pack prior to the meeting and mention that you would be happy to address any questions beforehand.
• Make sure you have all the required stakeholders in the meeting, including a representative from the support function. (Post go-live support.)
• Please allocate sufficient time to thoroughly address the points and discuss the Go/No Go decision. If you finish early, it will be a bonus. However, running out of time and needing to schedule another meeting with the senior stakeholders is not ideal.
• Don’t worry about robust challenges. This shows that the senior stakeholders are actively participating and providing the meeting with the appropriate level of attention.
• Peer review the slides and consider completing a run-through of the meeting with the project team and a few stakeholders. (Usually ones you are working closely with.)
• Make sure there are no surprises due to contradictory information by reviewing the programme board reports.
• Go/No Go meetings are critical risk management activities. Please ensure complete transparency and accuracy of all information in the slides. This is not the time to be optimistic, and don’t hesitate to show items as red. The stakeholders will expect you to have a plan to move to green, but I can’t stress enough that it is fine to show activities as amber and red if that is their correct status. Stakeholders become very nervous, and project managers lose credibility if everything is green in the first meeting and then red and amber in the next one.
• According to the size of the project, the project manager may also be the implementation/cutover manager, or there may be a dedicated person for this role. If you are fortunate and have the assistance of an implementation/cutover manager, this is beneficial because they specialise in this phase of the project. 

Stakeholder input to the cutover runbook

The cutover runbook is a key document, and it will be reviewed by the stakeholders. It should be prepared as early in the project lifecycle as possible and definitely before the start of the dress rehearsals. It is important to consult with all stakeholders to ensure that everyone understands roles, responsibilities, steps, communication, approvals over the cutover period, final approval to go live and escalation procedures in case there are issues during the cutover.

Consider the following in your planning and preparation of the runbook:

• Stakeholder engagement in the cutover is critical. Final business sign-off is a prerequisite for go-live.
• Agree and include the business assurance scenarios in the cutover runbook. They are required for business go-live approval. 
• Remember you are working in a live environment during the cutover and include appropriate risk management steps in the runbook. 
• If any critical business scenarios rely on a third party, include them in the planning and support activities.
• Review the steps in the backout plan in case issues are encountered during cutover. 
• Please demonstrate this during the cutover dress rehearsal.
• Security and data actions are critical; check to make sure they are included.
• Complete a thorough analysis to assess whether reverting to the legacy system after cutover is feasible, or if the only alternative is to proceed with fix forward. Please ensure this information is incorporated into the slides or document shared with stakeholders during the Go/No Go meetings leading up to cutover.

Summary

Work collaboratively with the stakeholders throughout the project to deliver the project. They are in a unique position to support your efforts as a project manager.