roller_coaster_photoAfter you’ve been on a few projects there’s a common pattern that emerges in terms of the phases your relationships with your business stakeholders go through. At the beginning everybody’s happy and excited about the possibilities. You discuss the many options, and the many benefits the project could provide. Then once the delivery teams start analysing requirements and designing solutions, relationships between the project team and business stakeholders become strained as you can no longer accommodate the wishes of the stakeholders. Eventually once things start to get delivered, the relationship is somewhat rekindled. In this post we’ll explore this cycle and how you can reduce the dips in the relationship and increase the speed of recovery.

The project to stakeholder relationship cycle

1. The relationship climbs high – It starts with excitement at the possibilities. Identifying pain points in the business, site visits in the field, brainstorming ideas; these activities all build excitement in your business stakeholders.

 2. The relationship dips – The feasibility lens is applied by delivery teams. While modern technology can achieve amazing things, some of your team’s requirements may have overestimated the capabilities of modern technology. Delivery teams will not commit when there are unrealistic requirements / schedule / or budget constraints. When you go back to the business stakeholders with the news that you can’t deliver to their expectations, the project to stakeholder relationship takes a dip.

3. Relationship recovers and climbs up again – New requirements are identified and change requests raised. The eager anticipation of the capabilities that will be delivered by the changes creates more positive energy between the project team and business stakeholders.

4. Relationship dips again – Viability (ROI) lens applied to the change requests. Once the changes are assessed by the delivery teams, the implications on cost and schedule become real. Any impact on cost or schedule usually requires approval from quite high up in the organisation and any changes that aren’t key to the solution functioning as a whole, will likely be knocked back. When you go back to the business stakeholders with this news, the relationship takes a dip and could become very strained.

5. Relationship gets back to level – The business stakeholders realise you are trying to help them by guiding them to identify the must haves and the MVP. Your team also becomes more pragmatic after having to deliver bad news. At this stage and the business stakeholders see the massive effort the project team continues to go through to try to get the best outcome for the business. This realisation that you’re working to get the best outcome for the business brings the relationship back to level grounds.

6. Relationship takes another hit – User Acceptance Testing. During User Acceptance Testing the business stakeholders try out your product rather than just looking at designs or demonstrations where you’ve talked them through it. This may lead to the identification of gaps in capability that cause the relationship to take another dip.

7. Relationship climbs back to positive – Delivery. Once you deliver tangible results to the business the relationship between project team and business stakeholders climbs back to positive grounds. This is the case even if the end result doesn’t include all of the capabilities the business stakeholders came up with, because they’ve been along the project journey with you and after all the hard work they have a delivered product.

How to reduce the dip and increase the speed of recovery

1. Limiting the high of the Initial excitement – During the initial brainstorming and conversations with your business stakeholders you need to pre-empt the feasibility lens being applied by the delivery teams. This means using your knowledge of IT and your previous experiences to avoid over promising! You need to apply a bit of a filter on unrealistic expectations and challenge the business on some of the things being asked for that don’t seem like ‘must have’ capabilities. For things that don’t directly relate to your project’s objectives, clarify the problem and look for non IT alternative solutions – It will save a lot of disappointment later on if you can stop the requests that aren’t ‘must have’ while still keeping your stakeholders happy.

2. Reducing the dip of the feasibility lens – Make sure you and your team have a session with a solution architect and your delivery team before approaching the business for requirements. This prepares your mind with what’s feasible so that you don’t steer the business down a path that turns out to be prohibitively expensive.

Also involve your delivery team in workshops with the business wherever possible. This way you can get much quicker feedback on feasibility and avoid setting unrealistic expectations with your stakeholders.

3. Limiting the growing anticipation of changes – This is where your experience on projects end to end will help you a lot. Having been through it at least once, you’ll know how tough it is to have a change approved when additional funding is required. It can even be very tough to just draw on contingency funds that the project has. So, apply the same feasibility lens as at step 1 however be much more ruthless, while still keeping your stakeholders happy of course! Be resourceful as well! Be very sure you’ve clarified the business problem and look for non IT alternatives that will solve the problem, maybe even better than an IT solution.

To keep the stakeholder relationship positive at this stage it’s more important than ever to make sure your stakeholders feel you’ve listened and understood their needs and made every effort to look for alternative solutions so that the core of the project delivery wouldn’t be thrown off course and still delivered a high quality outcome for the business.

4. Reducing the dip of the viability lens – For any changes you are seeking approval for, articulate the business benefits and the impact of not doing the change very clearly and succinctly. If you’re in a large organisation that hasn’t widely adopted the start-up mentality for project teams, there may be several gateways to go through before a change is approved. This gives your changes a better chance of going ahead.

Transparency will help the project team to business stakeholder relationship immensely. If the business stakeholders are on the change request journey with your team, they will feel involved and informed and be able to see that you are working towards the best outcome for them. If there is no transparency, the business stakeholders may assume you’re not listening to their requests and just going ahead with whatever you want. This can create negative sentiment that makes even simple things in the project difficult to achieve. Be transparent to keep your stakeholders feeling that you’re working for them, not against them.

5. Maintaining the level – Eventually as the business stakeholders realise you’re trying to help them, the relationship returns to lever. However you can actually improve the relationship further by using your resourcefulness to identify little to no cost solutions that can satisfy business needs on some of the requests that were put to the side. These requests would otherwise have gone unmet and by providing solutions you will improve the relationship the project has with the business stakeholders.

6. Reducing the dip of UAT – Test data. Make sure you allocate enough time and resources to properly setting up the data in the environment. Also make sure you allocate enough time and resources to make your UAT test cases descriptive enough for your users. These two things will avoid a huge number of problems that damage the reputation of your project and reduce your stakeholders’ confidence in your team. If these two things are in place, you’ll be giving your first users a much smoother experience with your product and your project team.

7. Maintaining the positive level of delivery – At this stage, if you’ve done all the above, your stakeholders will be smiling ear to ear and your product will sell itself! It’ll be so simple, clear and contain all the fundamental capabilities that deliver the expected business benefits of your project.

Do you see the same thing in your projects? How do you minimise the dip and increase the speed of recovery?