Building better stakeholder relations through prototyping
These 6 tactics will help Business Analysts create good stakeholder relationships throughout the software development lifecycle, resulting in less rework, less time wasted and more projects brought home on-budget.
The statistics are a little daunting for any Business Analyst: the average IT project takes 230% longer to complete than originally planned, and costs 178% more than expected. Managing stakeholders is one of the keys to avoiding statistics like these on a digital development project, so it’s unsurprising that Business Analysts are keen to get relationships with stakeholders right. But despite the best of intentions, Business Analysts can sometimes flounder when faced with difficult stakeholders or conflicting demands; how do you keep all your stakeholders happy and still keep requirements, scope and spend realistic?
While stakeholder relations are tough, they’re far from impossible. By employing these 6 tactics, a savvy mix of ‘soft’ people-management skills and ‘hard’ technical solutions such as prototyping, BAs can improve communication, put limits on project scope and manage expectations.
Typical problems of BA stakeholder relations
While every SDLC is different (BAs have to be flexible and creative for this very reason!), Adrian Reid writes in Bridging the Gap that there are some common ‘complaints’ that BAs hear from stakeholders on the regular: perceptions of BAs wasting time, reluctance among stakeholders to agree to requirements, and reticence in sharing business objectives, can be some of the most common obstacles to good stakeholder-BA relations. If your stakeholders are harboring any of this negativity towards your project, you’ll experience conflict, misunderstandings, baggy scope and missed deadlines. You need to bring back the shared focus and commitment to your product solution by improving your stakeholder relations, the sooner the better.
Why it’s important to improve them – what you stand to gain
So if stakeholders have the potential to be so intransigent, why should Business Analysts go out of their way to improve relations with them? Successful management of the relationship can result in aligned requirements, defined and controlled project scope, less reworks and better all-round communication.
Following these tactics will increase your chances of keeping your stakeholders onboard throughout the software development lifecycle, and producing a great product as the final result. And they should make your life as a Business Analyst just a little easier too.
Improve stakeholder relations with Justinmind prototyping platform
Draw up a communications planning matrix
Establishing and maintaining clear lines of communication with all your project stakeholders is obviously vital if you’re going to keep everyone on the same page and informed. However, no two stakeholders are alike, and therefore how you communicate with them effectively is almost as much an art as a science. A Communications Planning Matrix (traditionally a tool employed by Project Managers rather than Business Analysts) will help you put order into how you manage stakeholder communication: using your stakeholder analysis, mark out each individual group of stakeholders and note their role in the project, what kind of information you’ll need to keep them abreast of, how often and in what format. This document will minimize chances of miscommunication and ensure that you talk to each stakeholder in the right way at the right time. A collaborative prototyping platform such as Justinmind optimizes communication: Teamwork features allow the creation of shared prototypes on your own servers, which means stakeholders can be kept in the loop about changes and iterations as and when they happen.
Yes, it is possible to get your stakeholders to do more than merely validate your requirements; you can get them excited by ‘excitement requirements’. A great concept identified by Stephanie Famuyide in Business Analyst Learnings, excitement requirements are “those that customers did not think of, or even think were possible.” Stephanie uses the example of a word processing app that imports stencils like a modelling tool to explain excitement requirements: stakeholders don’t expect to be able to draw with their word processors, so when they do they’re happy. You’ve created a positive point around your requirements and given the product a competitive lead. What’s not to get excited about?
But how can you work a little excitement into your requirements in practice? Elicitation methods such as user observation, ideal visioning and pain storming can help you find your users’ latent needs and desires and answer them with an excitement requirement.
Agile requirements management through collaborative technology
Accoding to EnFocus Solutions, 91% of BAs they surveyed used wordprocessing to define and manage requirements. But there’s nothing more likely to give a stakeholder a headache than a hefty 100 page (or more) requirements doc for them to plough through. And amending these text documents, never mind tracking and actioning changes, is unwieldy to say the least when you’re dealing with multiple teams throughout the product development lifecycle. Worse, missing requirements are hard to spot until you’re on to coding, when backtracking has already become a costly endeavor.
A more agile approach to requirements management is to manage them within a prototyping tool, which allows your requirements to be both collaborative and iterative. Adding stakeholders as users will allow them to collaborate directly on the requirements, and having a version history within the prototype makes traceability easier. Confirming implementation of each requirement will negate any stakeholder complaints of time-wasting on the part of the BA, and increase accuracy when aligning the prototype with your requirements.
If for some reason you’re not using a prototyping tool, collaborative communication tools like Enfocus Requirement Suite can keep requirements live, but lack the added value of having a prototyped solution there on hand to compare against requirements and validate them.
Manage requirements and your stakeholders will manage themselves
Well, maybe not quite manage themselves, but the ability to trace requirements, changes and rationale will take you a long way towards building strong stakeholder trust and engagement. Make clear to stakeholders what you need from them in the requirements process and ensure you get their collective sign-off on your strategies to gather and validate requirements. Once your process is out in the open and stakeholders are fully informed of your plan, you’re more likely to count on their support in moments of unexpected change or uncertainty.
Maintain open dialog between developers and stakeholders
Getting the software development team and stakeholders to speak the same language can be a tough call. But if you can create an atmosphere in which developers and stakeholders cross the divide and start to work in a more collaborative manner, you’ll have more chance of produce a digital product that fulfils requirements. In practice, this means gathering requirements into a prototyping tool, having developers prototype up a solution, sharing that with stakeholders and having them feedback into the prototype. Iterative redesigns can then take place with realtime endorsements from stakeholders, without having to get everyone together for meetings. Your stakeholders will thank you for that.
Use soft skills for better stakeholder management and better software projects
Technical tactics such as prototyping, requirements and scope management will take you far in building better relations with stakeholders; but there are also so-called soft skills that a good BA can’t neglect. Managing obstacles positively, consistent follow-through actions and treating stakeholders as partnerswill increase stakeholder engagement and support of you as a BA. Check out this great post from Bridging the Gap, which goes into more detail on how to strengthen the all-important emotional element stakeholder relationships.