Managing Stakeholder Expectations

“THEY JUST DON’T GET IT!” We hear this all the time from our client’s development teams and from their stakeholders when talking about one another and the problems they face every day that halt forward progress. How can two groups be working together but at the same time be so unconnected? The universal answer to this question is the two groups are not communicating properly.

One of the most challenging aspects of software development is not building the right solution, but rather managing stakeholder expectations within the business. Often stakeholders come from diverse backgrounds and do not have a good understanding of the empirical process that coincides with building a custom software solution.

In the experience of the typical business leader, they tend to receive clear, upfront specifications, precise deadlines, and exact costs. We, the development team, do our best to deliver these things, but in an agile world we must convey the importance of flexibility and communication over rigidity and absolutes. Often our teams will face unforeseen obstacles because no one has ever done exactly what we are trying to do, and it is impossible to know everything we will face before the project starts. Plus, if we took the time to understand every tiny detail upfront, it would introduce a lot of rigidity into the process that could hinder the team’s future progress and would significantly stall us from delivering any value to the business.

Setting Up For Success

Considering the disconnect between stakeholders and development teams described above, what is the best way to shift the mindsets and stakeholder expectations to set everyone up for a successful project? The best place to look is the Agile Manifesto itself, specifically these four core principles:

1. Individuals and interactions over processes and tools. The group (that is the development team and all stakeholders) needs to agree that communication on all levels is the key to success. Regular, transparent communication is the only way to keep everyone on the same page and will always keep the team hyper-focused on the right things. Processes and tools are great, we put them in place to keep us efficient and consistent. However, if a process is hindering progress or the ability to deliver, people and interactions with one another should take over. These are the times when the group needs to come together and have hard discussions about things that need changed or improved to get the team moving again.
2. Working software over comprehensive documentation. Documentation is valuable and can be helpful in the planning, implementation, and training process. However, added documentation should function as an optional supporting resource to building software, not as a baseline to tell stakeholders what to expect before software is built. Working software speaks louder than documentation. The best documentation in the world can only show a picture of what an end solution can do. Showing working software allows stakeholders and end users to see the actual state of the solution instead of a proposed solution. Working software also allows stakeholders and users to give feedback and requests based on a real thing. The feedback you receive can then be actionable immediately in the next iteration, which can lead to a better solution in the end.
3. Customer collaboration over contract negotiation. In all software projects, there is some form of “contract or negotiation”– it may be a statement of work, a projected timeline, or an estimated cost. Contracts are inevitable in the development process, but all members of the team must see the contract as a guide that could adjust over time. Problems and hurdles will arise while the team develops the software. It is how both sides respond to the obstacles that matters. If both sides come to the table to collaborate during challenges, knowing the original contract may need to be adjusted because an issue added scope or increased timeline, the product will be better in the end. Often stakeholders will ask for change but demand the same cost or timeline which is unrealistic, or the dev team will require an extensive and complicated change request process to document why a contract may need to be adjusted. This process can be taxing on both sides of the table and cause friction instead of progress. If both groups partner together in collaboration and not worry about what a contract says, the team utilizes the most efficient and least wasteful process to develop the product.
4. Responding to change over following a plan. We make plans, projections, and roadmaps in software development, but these are made with the understanding that there is a high chance they will change regularly and often. We always need direction and vision in a project; however, we will learn new things about the business, market, and technologies as we build the solution. What we believe will be the best or the most needed features and functionality in the future today will not always be correct once we get farther down the road. Building and functioning in a way that embraces change allows for flexibility at all levels and increases the team’s ability to respond effectively to the curveballs that fly their way.

In Conclusion

These are the key philosophies to keep in mind when building software. They are mindsets to have when dev teams and stakeholders come together; fluid and clear communication is critical for developers to build a valuable solution while exceeding stakeholder expectations. It is easy to say all parties will focus on having these mindsets when approaching each other through the project, however, it is not always easy in practice once the project is underway.

These difficulties are why Scrum and agile have “tools” built into the framework to help teams communicate better, collaborate more regularly, and respond to change appropriately. There have been entire books written about these tools and processes, and we want to do justice for each tool.

Here is a list of the various tools used in the strategy and delivery phases of Scrum for managing stakeholder expectations:

Strategy Phase:

• The Product Goal
• Strategy Workshops
• The Software Development Plan

Delivery Phase:

• Focus on Business Value
• Sprint Reviews
• Backlog Prioritization
• User Acceptance Testing
• Sprint Planning

Be sure to follow Ascendle on LinkedIn for updates on upcoming articles exploring these topics!