Engaging the Stakeholder

by Brenda J. Christie

Years ago there used to be this breed of IT professional who essentially espoused the philosophy of "if you build it, they will come."  They got a whiff of what the business said it needed, came up with a solution immediately, and then off to the races they charged.  Using the Waterfall methodology, designing, testing and producing the deliverable usually took months, after which the stakeholder said, "But that's not what I wanted."  Everyone was disappointed.

Fortunately, thanks to the advent of Agile and the whole concept of collaboration, those types of results are, hopefully, infrequent.  Not that Waterfall was the culprit.  After all, any tool is only as good as the person using it.  I'll use my experience as an example.  

How I approach stakeholders, whether using Waterfall or Agile, is to listen to them and try to understand them.  However, it would be a crap shoot, by which I mean risky, to think that would be sufficient.  In creating the BRD, I usually use process diagrams, I'll create a mock application using Access or SQL Server or something similar to imitate the behavior of what the application is intended to do.  I'll use Word or Excel to create a report if that's part of the deliverable.  

Then I'll sit down with the Stakeholder to have a dialog, i.e., 2-way conversation on whether, I got it right. Obviously this is can be an iterative process and quite different from the decades ago type who acted like Samuel L.Jackson's character in Rules of Engagement.

Fortunately for me, my approach was successful 99% of the time, and I stayed, and continue to be, gainfully employed.

But why engage Stakeholders at all?

Well, as I mentioned above, it's a good idea to engage stakeholders because it contributes to continued employment.  It also aids in eliciting the project requirements.  Opening up a dialog with stakeholders also has the potential to reveal what the stakeholder expects to gain from the project, whether there is a limitation to using the deliverable (i.e., an obstacle to overcome), what the stakeholder's motivation may be with regards to the project, and by extension, whether the stakeholder is even on your side.

To a large extent, engaging the stakeholder can often take different forms.  Some prefer one-on-ones, some will participate in round table discussions, some will participate in conference calls, and some only want to participate via email.

However they participate, stakeholders have the potential to make or break a project.  Some pack more influence than others, and this is a distinction that needs to be made early on.  However, this distinction can only be made by contact with stakeholders.  They are real whether we choose to acknowledge them or not.

Brenda J. Christie