Skip to content

Stakeholder Involvement for Getting Projects Back on Track

Stakeholder involvement is critical to the success of every project that I have worked in my organization.

Also project success depends on involving right stakeholder in the right away during the course of project execution.

I was asked to deliver a project for a corporate travel company in a fixed price contract. This project was part of their big business transformation and to be rolled out across their 40 branches. From here onwards, corporate travel company was referred as Client.

The project was to replace their manual end to end business processes with a technology platform (website) and to be rolled out across 40 branches with different business rules in each branch.

Just to give a complexity of the project, the new technology platform was to integrate with their internal systems and various 3rd party systems followed by 3rd party vendor certification for each integration and complete system audit by one of the big 4 audit forms.

When I joined the project, scope was signed off and the delivery schedule were agreed upon and the entire project was to deliver in June.

I have the following project documents at the time of handover of the project in December:

  1. Product requirements
  2. Project scope
  3. Project Technical documents
  4. Project schedule and cost
  5. High level stakeholder information

We had deliverables in every month as the project was to deliver in increments. The initial small deliverables happened on time due to small scope. In February, we started the complex business process and was to deliver in April. We couldn’t deliver even after June as continually changes were coming from Client and 3rd party vendors. As this was a fixed price contract, cost overrun started with schedule slippages.

The entire team was under tremendous pressure to meet the deadline in July as the Client had arranged a big campaign to announce their website which had to be postponed several times.

The entire team did a brainstorm session to understand where the changes are coming even after the scope is signed.  It was observed that changes were coming from the following sources:

  1. API integration
  2. Good to have features are getting added without being in the plan
  3. Not all the stakeholders were identified
  4. The main users of the new system haven’t changed their behaviors and habits sufficiently to use the new system and continually to compare with the already running system and hence apprehensive to use the new system

The following changes were brought in to bring back the project and the platform was rolled out to one branch in August:

  • Initial stakeholders were list of people with higher positional authority i.e. from top. But the changes were coming from people who were to use the system.
  • Identified the key users who were to change or influence the system most i.e. started identifying the users from the bottom to through to the project sponsor.
  • Built the stakeholder map with the identified key stakeholders and worked up the RACI matrix and communication plan
  • Maintained this a living document as project progress, there could be changes in project direction or stakeholders, or change in power of the stakeholder
  • Formed small cluster of groups that includes project members and stakeholders who were made responsible for API integration and accountable for api integration audit sign off
  • Made mandatory to raise any project requirements in project tracking tool and all the changes were discussed with the project sponsor and relevant stakeholders and picked up only the defects relevant to agreed scope
  • Project team were to pick up only the prioritized issues from the project tracking system for implementation and avoided good to have features, requirements for future etc.
  • Proactively requested for the details about the various audits and project teams conducted the pre audits and fixed any issues that were arise in pre audit
  • Product demos were conducted with the branch users
  • And finally, started saying big “No” to the Client. Wasn’t this about making the customer happy? Well, over the years I’ve learned that there are some things out there that go far beyond the technical capabilities of technology. Also, remember that you have deadlines to keep up.