Don't forget the end users. Cartoon of a robot showing different interpretations of requirements
Project managementStakeholder Management

Don’t forget the end users

Psoda blog author avatar
Guest Author
2 September 2014

Let’s admit it, when working on a project, the word ‘stakeholder’ may mean different things to different people, depending on their role.
As a project manager, you will talk about the project sponsor and the business owner as your key stakeholders.
In all fairness, they are key to the project, as they are the ones who keep track on its financial viability, approve budgets and have a say in who runs which projects and when.
And you, as a PM, need to make sure your key decision makers are happy.  After all, if they are not engaged or are unhappy with the progress of the project, there will be no project.
To me as a business analyst, the key stakeholders are the end users.  They are the people who are going to be on the receiving end of the application once it’s delivered.
Too often though, I have seen how engagement with these stakeholders is underestimated on projects.
Of course, project managers will always offer good reasons why end users can’t be engaged as a stakeholder group, such as:

  • The actual user base is too large and external to the organisation, so it’s near to impossible to go out and interview them for requirements,
  • The project has a short timeframe to deliver and we can’t afford going through validating the requirements to meet the deadline,
  •  There is no support by the business owner to engage the users because they may be too busy or are remote to the project team location.

But what happens when the end users are not involved on the project?
The results vary from missed requirements, or requirements which are communicated vaguely by business owners not familiar with the detailed business use cases and processes, or (and this is scary) decisions about usability being made by developers!
It’s not hard to guess then that when the end product is delivered, it may not be one that users are willing or even capable to use.
At worst, the business value for initiating the project in the first place may not be delivered.
For example, if your project promised to deliver operational efficiency and end users are struggling to use the system or are resisting changing their processes, operational costs may actually increase.
This kind of outcome will bring into question the validity of initiating any future projects that promise to deliver operational efficiency.
While I agree you may not always have the luxury of having a dedicated end user on every project, there are certainly ways to overcome this and to maintain the focus on delivering the business value your project promised.
If the audience is external, engage user experience designers to consult and provide requirements.  Even if the input does not come directly from end users, you will receive advice on best practice approaches for usability.
And, if prospective users are internal to your organisation, but the business owner is still resisting engaging them, approach the training team who may be familiar with internal processes, the users and how they work.
If your project is on a tight deadline and you only have a short timeframe to engage with users, ask your developers to create prototypes of those tricky interfaces that need to be nailed down.  You may be surprised how much feedback you can get from a visual and semi-interactive presentation in a short session.
Admittedly, it’s not an easy task to persist with engaging your end users. But ultimately, it’s better to risk annoying business owners to ensure this happens, than to end up with irate users and a tool that causes more headaches than it solves.

Marina van Wyk is a Senior Business Analyst with 10 years’ experience in software development projects. She offers insights from her involvement in various IT projects at Telecom, Vodafone, Auckland Council, Vero Insurance and others. 

Leave a Reply

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