2. Engaging Your Stakeholders to Get Them What They Really Need
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, 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
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.
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.
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.
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.
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."