Introduction | 1. Building Trust Within Your Team 
2. Engaging Your Stakeholders to Get Them What They Really Need
3. Making Project Risk Management an Organic Exercise
4. Understanding the Environment | 5. Applying LEAN Principles | Understanding the Basics

2. Engaging Your Stakeholders to Get Them What They Really Need

Figure 2

As a PM, you are probably well aware of the fact that a lot of software projects end up delivering something other than what the stakeholders wanted or needed. This problem is due to many different factors and it has spawned a whole set of new methodologies trying to solve this problem. However, even in the era of Agile development,[3] we still sometimes fall into the trap of building the wrong thing.

Stakeholder analysis is essential but often starts with the wrong question. Without asking the question, "Why are we doing this?" many projects are initiated and incorrectly defined, falling into the trap of building towards a solution that never addressed the real business need. In conjunction with the "why," Top PMs must ask a follow-up question: "for whom?" Which stakeholders are we supporting, in order to deliver the solution, to cover their "why?"

Here is where a Top PM recognizes an important distinction. The solution can be defined as an output or deliverable, but a Top PM understands that any solution itself will not necessarily cover the original business need. For example, if the stakeholders think their business need is to implement an ERP system, then the PM has to help them to uncover the real business need behind using a solution such as ERP. The ERP itself is a solution, not a business need.

Recognizing the true business need requires a deep understanding of the context and the stakeholders. This includes their attitudes, power or influence level, interest level, their impact on the project, the project's impact on them, their concerns, and of course, what will they accept as the project's success?

Thus, in order to make projects more successful in achieving their purpose, i.e., creating solutions which impact business goals, the project manager's responsibilities expand past the solution creation itself. It extends to where the solution goes live, and then clearly measuring whether the value actually produced aligns with the expected objectives in original the goal definition.

In other words:

PMs should always keep in mind that throughout the entire process the real benefits of delivering the project have to be aligned to the real business needs, goals, and objectives.

Too often, the business goals are forgotten in the midst of development and requirement changes. Often, projects end up delivering functional products, that solve some, but not all real business needs that initially prompted the development of the product in the first place. This can be prevented if stakeholders are managed properly and presented with product iterations often.

Top PMs also recognize their role in leading the project, and thus do not expect stakeholders to communicate all requirements at the outset of the project. They understand that some stakeholders do not always know how to articulate their needs, and it is their role to help stakeholders articulate their needs, from requirements elicitation, through to project delivery. It's also important to remember that during the requirements elicitation process we have to elicit not only requirements from the stakeholders but their concerns as well.

For example, in less mature organizations an interesting paradox often happens at the beginning of new projects. During the project initialization phase, the development team expects stakeholders to clearly identify all the requirements and needs for the solution they are expected to develop. At the same time, stakeholders expect the delivery team to provide accurate estimations in both time and cost.

However, at the very start of project scoping, there is too much uncertainty to nail down these estimates accurately. But by so doing so, there is a real danger of presenting unrealistic answers. At times, some stakeholders include as many requirements as possible, to allow for the current uncertainty of less tangible solutions. At the same time, the delivery team may provides a very approximate estimate to cover for the unknown.

Consequently, the result will most likely be a solution that will only get 20% of the full requirements required by the stakeholders. The rest will be developed with no clear goal in mind making the project over-budget and over-schedule.

Luckily, Top PMs know precisely how to engage stakeholders and guide them through each step of the VUCA (volatility, uncertainty, complexity, and ambiguity) world of their project. These project managers are able to break down the project into more tangible increments and engage stakeholders while actively creating and reviewing feedback throughout.

Key takeaway: "The solutions are built to solve the business need, PMs need to make sure this goal is not missed when the project gets created. Make sure that your stakeholders want to build the right things, by engaging with them to address their core needs and concerns."

1. Building Trust Within Your Team

3. Making Project Risk Management an Organic Exercise

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page