Capabilities versus Components: An Agile Conundrum

What do your stakeholders REALLY want - capabilities or components? Don't assume...use a little common sense...and a lot of persistent communication.

We don't always know exactly what our stakeholders want on projects, but we should be able to have a pretty good idea.

This would seem to be a trite statement. We SHOULD know what our stakeholders want! The problem is that many things can get in the way - not the least of which are ourselves and our stakeholders!

persistent communication

Getting Beyond Ourselves
Did you ever hear the saying, "We have met the enemy, and the enemy is us!"

Projects tend to take on a life of their own. This means that many assumptions made along the way tend to get ingrained into the team as established fact. Ways of doing things get routine, and we tend to assume we are doing the right thing.

This type of thing is exacerbated by two things: size of project, and distance. Size of the project can make change difficult, and can make the assumptions mentioned above become more ingrained int eh culture of the team. Distance - referring to lack of collocation, multiple locations, non-proximity, and the like - can produce gulfs of understanding that can widen if we don't give it proper attention.

We have to take a very honest look in the mirror and ask ourselves if what we are doing is driven by the end goal of the project...or if there are other factors involved. We need to be honest...and also need to work hard at asking questions until we decompose the problem down to the right level.

Getting Beyond Our Stakeholders
At times it can be tempting to BLAME the stakeholders. They are not clear enough, they don't give the right requirements, they don't prioritize properly, they distract us from getting our valuable work done...

In the end, it is highly likely that the stakeholders want the same thing we do: success on the project. It's our job to use that essential and immutable common ground to find the areas of agreement and level set our efforts.

One way to do this is to HELP our stakeholders to define what it is they want. If we find requirements lacking, what can we do to help the stakeholders better provide what we need...and how can we adjust what we need to make it more practical for the stakeholders to provide?

The stakeholders need the project team...and vice versa. It's a symbiotic relationship...and we need to try and see that in the end we are all essentially on the same team.

Use Common Sense, Solid Logic, and Solid Communication
We have to get beyond the black and white...and learn to see beyond our noses! We need to learn to read between the lines. Here are three things we can do to bridge the gap between our project team and the stakeholders:

Use Common Sense - Often, the problem on projects is that there are misunderstandings as to what is needed. Requirements are unclear, and there can also be a diversity of stakeholders with somewhat conflicting interests. No matter what someone says they want, we need to apply some common sense and ask, "What do they really want? What are they really trying to say, and what will they really want in the end when the dust clears?"

Be Proactive - Anticipation is the key. If we are to LEAD the way to project success, we need to think ahead and take action. We need to try and avoid getting into a reactive mode, as this is the antithesis of leadership and in the end will produce poor results.

Make Communications Priority One - You've probably heard this a thousand times. We all have. But communications breakdowns and misunderstandings occur anyway. don't expect that people will just understand. It takes a lot of effort to continuously communicate and make sure people are on the same page. Never stop, and develop a resilience in yourself and on your team to be persistent always in your communication - until you get the job done.

Do your stakeholders want capabilities or components? Make sure you are all on the same page. It's not easy.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>