Click here to monitor SSC

Simple-Talk columnist

On Identifying the Real Stakeholders

Published 17 July 2014 10:18 am

When it is appropriate, I’m sold on the idea of evolutionary development and delivery based on iterative and incremental phases as one’s understanding of the business domain increases. Even when we had plenty of trained systems analysts, and only primitive ‘waterfall’ methodologies, the requirements were all still vague and full of hand-waving generalities at the beginning of the software development cycle. Under any software methodologies, therefore, continuous customer or stakeholder involvement is very important. From my own past experience, though, the major struggle in development is in finding out who the customer really is, and in identifying the key people in the organisation who really understand the business processes. It’s not always as easy as you might imagine.

stakeholders

‘So which of you guys can help us understand how the returns system works?’

When I started designing large-scale applications for the enterprise, I remember being amazed at the lack of understanding of the essential processes of the organisation that the designated ‘users’, ‘stakeholders’ or ‘customers’ had. When any important application gets the go-ahead, one might expect a general concerted action within the company to assist and ‘make it happen’, in order for the company to reap the benefits of efficiency-savings: Sort of like an Oklahoma barn-raising.

Reality comes as a shock. Let’s take as an example a corporate application: The panel of designated users is seconded from various departments. No manager will willingly part with competent staff. Instead, canny managers see this as a means of cleaning out from their department those staff that are burned out or demob-happy. Departments who are liable to contract or be reorganised by a successful IT initiative will deliberately nominate difficult and disruptive people. This is an unlikely mix of humanity from which to draw insights into what is now called the ‘business domain’.

I’ve seen projects where the developers have failed to realise until too late that their ‘stakeholders’ haven’t grasped the basics of the company’s activities, or who might even want to mislead. In any large organisation it is often an uphill struggle to discover what is really going on. The proportion of people with a broad perspective in what is going on can be very small, and they are too essential to be seconded to an IT project. and there are plenty of people who want to throw sand in the air to disguise how little they are contributing to the company. With staff turnovers increasing in recent years, evolving an effective application from their insights is like expecting primates to write Shakespeare on typewriters.

I remember once tracking down the only person who really understood the full shipping process for the organisation for whom I was developing an app. His office was in a trailer in the back of the car park. One needed rubber boots to get there. I thought to myself at the time ‘is this really a developer’s task to do this?’ Yes, I can say in hindsight, it might be essential. I think the technical term is ‘identifying the real stakeholder’, and it isn’t always easy.

Guest Editorial for Simple-Talk

14 Responses to “On Identifying the Real Stakeholders”

  1. Mxaza says:

    I very much agree, its not always easy. Would I be wrong in saying that we sometimes focus in creating applications that “perfectly” function within an organization that we forget about the external people that the application will somehow affect? Thus leaving out certain stakeholders.

  2. Phil Factor says:

    Often, we focus on creating applications that ‘perfectly’ function according to a poorly-selected bunch of stakeholders who don’t really understand the business processes, and, yes, we miss out on the knowledge of the important people.

  3. Robert Young says:

    I spent a considerable number of years working for a Fortune X00 company, in a smallish division (bought in, not organically grown) which (had, long ago) made a COBOL-DB2/z application for insurance companies. It had begun life on VSAM, not surprisingly, and the data view both in-house and at the clients was decidedly ante-deluvial.

    But, with the rise of the innterTubes and servlets and applets (for a while), the clients focused solely on the eye candy, and continued to view data as their daddies did 40 years ago.

    In sum: there are worser situations to be in than having to track down real stakeholders; they can be right in front of you and dumb as a sack of hair, but with the authority to perpetuate The Dark Ages.

    Be grateful, Grasshopper. Be grateful.

  4. sdmcnitt says:

    Sometimes the real stakeholders are business folks that have created vast Shadow IT “utilities” that work around all the short-comings of your production systems.

  5. Keith Rowley says:

    Given the opportunity as a developer I would prefer to be given the leeway and opportunity to learn the business processes myself. Not from a committee or meetings but from spending enough time “in the field” as it were, actually spending time with the people who DO the process as they do their jobs, learning how they do what they do by actually doing it alongside of them.

    Unfortunately companies are rarely willing to pay a developer to stack boxes, pull merchandise, or work a register, for all that this kind of real world immersive learning can provide much better results at a lower long term cost to the company.

  6. willliebago says:

    I love working with good system analysts :)

  7. sterbalr says:

    It is equally important to communicate who the stakeholders were who created the application to help the users understand the perspective that was used developing the application.

  8. Timothy A Wiseman says:

    This is an excellent point. In a large organization it is not always obvious who really knows what the software should do. I do not think there is a good answer to that, though I suspect that talking to a large swatch of people that use or will be affected by the software would help a great deal when it is an option.

    A related issue is that people often do not know what they actually want until they see it. This comes back to the iterative approach mentioned at the beginning of this article. It is often a good idea to present a “rough draft” as early as possible and ask how close it is to what they want. Even if it perfectly complies with the requirements stated so far it may well prove to not be what they want anymore.

    I have had co-workers directly tell me that I did exactly what they asked, but that now that they have seen it they know it isn’t appropriate. So, I get feedback and revise. I think that process is often essential, though I would agree it is much easier on small projects than on truly large ones.

  9. TodConover says:

    My thought… this is another crack in the veneer of Agile. When you shortcut the development process you make mistakes. If it’s OK to have do-overs in the games you play, then don’t expect your customers to take you seriously. Good systems development requires work. It’s hard to get complete requirements; it requires you find all the correct stake-holders and ask all the right questions. If you say it’s OK to develop systems without complete requirements, then why are you complaining about not finding the right stake-holders?

    Agile is a recipe for failure; it’s part of its DNA. If you are finally getting tired of that, go back and learn how to do real systems development without shortcuts. There are actually techniques for ensuring complete requirements are gathered up front. Anyone arguing it’s not possible, is simply lazy and has not taken the time, or put forth the effort, to learn how to do it right.

    • paschott says:

      I’d disagree with this a little bit. If you’re doing Agile correctly, you should start with a pretty good idea of where you want to go, but go back to the customers/stakeholders frequently to make course-corrections. I’ve seen too many waterfall method projects fail due to the devs never deviating from the original plan, only to deliver what isn’t needed now months late. A more agile process has helped us tweak the desired product along the way to make sure we meet the current needs. I will agree that if you don’t try to develop proper requirements in the first place you’re doomed to fail, but I don’t blame that on Agile. That’s just poor project management – agile or not.

  10. SAinCA says:

    Perhaps an equal danger is when the software team usurps the role of the SME or the Product Manager. This is a high risk factor for public-facing websites, especially when several members of the current software team designed the original product. When Enterprise structures change, and change they had to because the former “perceived to be great” product didn’t sell, those former software content definers must learn very swiftly to become software designers and developers who conform to a now-externally defined set of product requirements.

    This tandem approach, where, as you rightly point out, the experts rule the requirements, and the software team implements the vision, should bring about success. Absence of external experts, or self-declared experts in the software team exceeding their purview inappropriately, put that success at great risk.

    And therein lies my personal, current, conundrum. How to respectfully remind one’s software manager and team members that their former roles must be relinquished in deference to the declared Product Manager(s)…

    Tricky, eh?

    • Robert Young says:

      – Perhaps an equal danger is when the software team usurps the role of the SME or the Product Manager.

      I’ve seen too many cases, the Fortune X00 application vendor is but one, where the SMEs or Managers dictate the system design. Mostly because either a) they’ve been the Head Honcho for decades and are only comfortable with data that looks as it did in the beginning and have the power to persist that view of persistence, or b) they’ve been using some macro-infested spreadsheet for years, which is now being upgraded to a real application, and they feign confusion if the data structure isn’t exactly the same.

      If we’re serious about building xNF databased applications (with lots o cores and lots o RAM and some SSDs), then we need to lead to the future, rather than shuffle on when ordered back to The Dark Ages. (Too ranty?)

  11. paschott says:

    Reading that I’m glad that I’ve usually worked in organizations where we knew who the real stakeholders and go-to people were. That doesn’t always mean we had productive meetings, but we’ve been pretty good at getting the correct feedback most of the time to make good decisions. We’re also good about doing course-corrections mid-project rather than just building it the way it was originally spec’d.

    I do recall a time when a project manager had nothing to contribute and ended up taking a really long time to give his update in a meeting. The person in charge forbade him from speaking the rest of that meeting or the next. Strangely enough, the meetings were more productive after that as people kept their updates short, relevant, and to the point (as well as coming prepared for that particular meeting).

    For internal apps, that’s a bit harder. Knowing who wrote things, why they wrote them, and even harder – who is currently the go-to person is difficult. Many times there’s some knowledge transfer along the way, but not always and we often find out well after the fact that we missed something.

  12. greentian says:

    Choosing the stake holders can be complex, since many of our projects are in quite volatile fields. Because the business may be changing the stake holders may suddenly change as well.

    Therefore, identifying the current stake holders is not enough. The next step is to also find the influencers of the already identified stake holders. They may already be thinking of significant changes to be made that will hit like a bombshell.

    To the extent, even the limited extent, that you can get a window into where the organization is moving, to that extent you can plan for the likelihood of change.

    It also means being very skeptical of “never” and “always”. Doing some extra planning on how to overcome a change in those absolutes will often give you a good payback.

    And, of course, you need to bring to the table all of the appropriate skills, some of which have already been describe.

Leave a Reply