Involve important people (part 2)

A few weeks ago, I wrote the first in a series of short articles about who needs to be involved in the software design process if it’s to have an increased chance of succeeding.  We covered involving users then, but they are only part of the overall picture.

This article looks at the stakeholders – those people who have vested interests in the success of the project.

Pictire of a business baby

To them, they may have been given the responsibility to see a project through to delivery and beyond; they may be in charge of teams of users and therefore their own productivity and effectiveness is impacted by that of those users.  Get it wrong, and their bottom line is threatened.  Understandably, they’ll want to get involved and keep an eye on the progress of the project.

In today’s troubled financial climate, you can guarantee that stakeholders’ bosses will be keeping a close eye on things too; the decision to proceed with a new software project is often made from fairly senior levels.  Support from senior execs doesn’t grow on trees, so when you do get it, you can’t take it for granted.  They’ll expect something in return, and that price is invariably success.

Stakeholder management is, of course, a science and an art unto itself, so I won’t cover that here, but it’s worth taking the time to scope where their individual priorities lie.  Some will be looking for a direct impact – software that enables their team to do better, say – and others will look to gains by association with a successful project.  Some may have competing priorities, or hidden agendas, and it’s certainly no bad idea to tread cautiously when involving these people.  Even if all is well, there is always a real danger of ‘too many cooks spoiling the broth’.

One project I worked on suffered from just this problem.  It was a large-scale system-integration which aimed to provide a consistent interface to a number of systems both old and new.  That in itself was fine and a challenge to relish.  However, every system within scope (and a few out of scope) came with its own set of stakeholders, many of whom would try to force their ideas upon the overall design without necessarily considering its impact to the others.  A difficult thing to manage, but software requirements prototyping helped by giving the freedom to build quick mock-ups to test ideas out and influence the stakeholders to reject the occasionally inconsistent, flawed or even wacky suggestion.

This said, stakeholders hold responsibility and accountability within the project, and they will want to be involved.  Do so, and they will provide domain and contextual knowledge which would be difficult to obtain any other way.  They will also invariably be involved in the eventual sign-off of any design, so by involving them throughout the design process, they will already have a better understanding of, and buy-in to, the eventual design.

About John Clark

My name is John Clark and I previously ran a software house called Reynard Thomson, from which this blog originally grew. In the meantime, we launched a video-based user testing service (Kupima) which didn't really take off, and I have since moved into a new field specialising on software-based research & development consultancy. I'm active on LinkedIn, and would love to connect to anyone who has an interest in software prototyping or R&D:
This entry was posted in General Business, Prototyping and tagged , , , , , , , . Bookmark the permalink.

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>