Tag: Best Practices


Think “Re-use” When Writing Requirements

When working on a project or product development initiative, the focus is usually on getting the product ‘over the line’ within a defined timescale. There can be immense pressure to create requirements artifacts quickly, creating just enough to communicate the key business needs to developers and other stakeholders.

This is completely understandable, but it can lead to somewhat of a ‘groundhog day’ like scenario where requirements that are very similar (or even the same) are written multiple times by multiple teams. When the pressure is on, there is less opportunity to think about re-use. Yet requirements re-use, when executed well, can save time in the long run.


Dispelling Myths: “Re-use” doesn’t have to mean copying & pasting

One common misconception is that because no two projects or products are exactly the same, there is no way that any requirements can be reused. However, re-use doesn’t have to mean literally copying & pasting—sometimes it can mean that a set of requirements are used as a starting point to build from.

Imagine that you write a set of non-functional requirements for a customer-facing web application. If, in the future, another team elsewhere in the organization needs a web app, then surely the NFRs that you’ve written would be a useful inspiration? The requirements might only be 80% similar, but the existing artifact means that there’s no need to start from a blank page.  Of course, this doesn’t remove the need to ask the right questions and engage the right stakeholders, but having an existing document to build from can save time.

In fact, there can be a benefit in having a “standard” set of NFRs for particular types of systems. Many organizations have their information security policies defined, their brand guidelines defined and so forth. Why not bring all of these policies together, adding other types of NFR, to create a corporate standard?  This will likely vary by context, but certain patterns will be relevant for particular situations. Clearly, building or maintaining an internal application is likely to attract different types of requirements to one that is exposed to the outside world.  This is just one example.




High level artifacts

It is also worth keeping high level artifacts that show the broad scope of what a particular system or product does. Context diagrams typically show the adjacent systems/actors that are relevant for a particular work area, and the high level data flow.  One day, someone is going to want to replace a key IT system… having an up-to-date context model would provide a massive head start. The same is true of business process models. If a new process is implemented, this is an opportunity to identify a process owner. The process owner is typically responsible for keeping the process model up-to-date. Imagine having a central repository with all (or even some) of the organization’s processes stored. This cuts down the effort of ‘as is’ modeling. (I say ‘cuts down’ and not ‘eliminates’, because it’s usually still necessary to see how people are actually undertaking the work, which may or may not be exactly as it is documented!)


Teams and Individuals

Another way artifacts can be reused is as examples or exemplars. When a new BA joins the team, they will often need guidance over ‘how we do requirements here’. Of course, experienced practitioners will bring their own views, but it is useful to have an expectation of what ‘good’ looks like. Too often organizations simply have templates or written standards. These are useful, but alone they are rarely enough… templates or standards with examples are far more useful. This doesn’t just apply to written documents, it can apply to models and requirements stored in repositories too.

These examples can also be used when a BA needs to show a stakeholder examples of business analysis work. Imagine trying to convince a skeptical stakeholder to engage with the BA team. Having a successful case study to show them, along with some fragments of requirements artefacts, prototypes and a working solution to show them might just help set the context. Stakeholder testimonials from the project will help even more.


But There’s No Time!

I know, I know, at this point you’re probably thinking “we’d love to do that, but there’s no time!”. I get it, deadlines are harsh and nobody wants to work even longer hours. There might not be time within the project, but there might be time afterwards or during natural periods of downtime if you are lucky enough to have some of those. Taking time to spruce up requirements artifacts, putting them somewhere central, and cataloging them so they can be found will save time in the long run. It is a short term effort for long term gain.

If you are a BA manager, you might consider building in an ‘air gap’ between project assignments for individual BAs to wrap-up their work and consider re-use (amongst other things). In many ways, this is building a sustained repository of knowledge for the whole team… and isn’t that an effort worth pursuing?


10 Common Problems Business Analysts Help Solve

Often Business Analysts are swept up by the hustle and bustle of project life and simply do what is needed to get to the end goal. Business Analysts focus on delivering a valuable solution to business stakeholders and they forget just how much value they add by help solving many problems along the way.

This short article outlines 10 of the common problems that Business Analysts help solve in the organization and especially when helping to deliver progressive change initiatives for the organization.

In no specific order of importance, find out more about these common problems that Business Analysts help solve and see if you can recognize some as familiar problems you often help solve too:


#1 Unclear or conflicting stakeholder expectations

Stakeholders may have unclear or conflicting expectations of what a project will deliver which hampers progress and can lead to disappointment.

Business analysts can help mitigate this problem is to ensure that all stakeholders have a shared understanding of what is achievable and what the project will deliver.

A Business Analyst helps to solve this problem by facilitating workshops with stakeholders to reach agreement on project outcomes, and by creating clear documentation of requirements that can be referred to throughout the project.


#2 Inadequate resources

Many projects also suffer from inadequate resources these days, which can lead to delays and frustration. Experienced Business Analysts can help identify which skillsets are needed to help deliver a project during the planning stages of the project to ensure resources are request early during the project set up stages.

Some more ways that a Business Analyst helps to solve this problem is by monitoring project progress and highlighting to the Project Manager where risks of resource shortages may occur. Where possible Business Analysts also help to create mitigating actions to avoid potential project delays due to resource constraints.


#3 Poor communication

Poor communication is often a root cause of many problems that occur during a project. Miscommunication can lead to misunderstandings, errors, and delays.

A Business Analyst can help to improve communication by facilitating communication between stakeholders, creating clear and concise documentation, and holding regular meetings to update everyone on the project status.


#4 Unclear or changing requirements

Unclear or changing requirements are one of the most common problems faced by Business Analysts. This can cause confusion amongst team members, as well as delays in completing the project.

One way that a business analyst can help solve or minimize this problem within a project is to ensure that requirements are well-defined and agreed upon by all stakeholders before work begins, whether they are working in Waterfall projects or Agile based iterations. This can be done through creating a requirements document which outlines all the requirements for the project and getting sign-off from relevant stakeholders.

In an Agile environment, the Business Analyst can help manage this issue by ensuring that user stories are well-defined and understood by all team members before work begins on them.


#5 Lack of engagement from stakeholder

Another common problem faced by Business Analysts is lack of engagement from stakeholders. This can be due to several reasons, such as stakeholders being too busy, or not feeling invested in the project or even mistrust of the business analyst.

The Business Analyst can solve this by ensuring a clear stakeholder engagement plan is a key activity within the project. The Business Analyst can also work to build relationships with stakeholders and ensure that they are kept updated on the project status and progress.




#6 Ineffective or missing processes

Ineffective or missing processes can lead to a number of problems within a project, such as errors, delays and duplication of work. This is often due to a lack of understanding of current processes being followed within the area the project is trying to solve for.

A way that the Business Analyst can help to solve this problem is by conducting a business process analysis to understand the current processes in place and identify areas for improvement. The Business Analyst can also work with the relevant stakeholders to develop new or improved processes where needed.


#7 Lack of understanding of user needs

A very common problem that a Business Analyst face is a lack of understanding of user needs. This is not because the Business Analyst is ineffective when engaging stakeholders necessarily, it can be due to several reasons including unavailability of key stakeholders and time or resource constraints that exist within the organization.

If there is a lack of understanding of user needs, it can lead to the development of a solution that does not meet the needs of the users, and ultimately will not be successful.

The Business Analyst can help to solve this problem by conducting user research and requirements elicitation to understand the needs of the users that will be using the solution. This can be done through a few methods such as interviews, focus groups, workshops or surveys.


#8 Lack of understanding of business goals

Many business analysts also find that there is a lack of understanding of business goals within an organization. This can make it difficult to align projects with organizational objectives and ensure that the right solutions are delivered. Often a Business Analyst will be assigned the task of developing a business case for a potential solution without having clear alignment of business objectives.

A way the Business Analyst can help to establish a clear understanding of the business goals is to work with stakeholders to document the business goals and objectives for the project. This can be done through workshops or interviews to understand the pain points that the organization is experiencing, and what they are looking to achieve by undertaking the project.


#9 Change fatigue

Another common yet less tangible problem faced in organizations is change fatigue. This is when staff members become resistant to change because change happens so frequently within the organizational area. This situation can make it difficult for Business Analysts who has to introduce new changes to business stakeholders and it becomes hard for Business Analysts to achieve their requirement outcomes.

One strategy a Business Analyst can follow to help manage the change fatigue of their stakeholders is to ensure that they keep them updated and engaged at the appropriate level throughout the project. They should at the same time aim to champion the benefits of the change to stakeholders and try to avoid asking stakeholders to repeat requirements or information that may have been articulated in the recent past by other Business Analysts. This is where it is very useful if Business Analysts can research similar project information to avoid rehashing the same content with fatigued stakeholders.


#10 Lack of governance

Finally, another common problem faced by Business Analysts is a lack of governance around requirements management. This can lead to several issues such as scope creep, requirements changes being made without consent or approval, and a general lack of control over the requirements. This can be a particular problem on larger projects where there are many stakeholders involved and the Business Analyst is not the only person working on gathering and documenting requirements.

A way to help solve this problem is for the Business Analyst to put in place a requirements management governance framework. This should include processes and procedures for how requirements will be managed, approved, and changed throughout the project. It is also important to ensure that all stakeholders are aware of and agree to the governance framework prior to the start of the project.



These are some of the top problems I could think of that Business Analysts often face and help solve. Some projects have multiple of these challenges happening at the same time which makes the role of the Business analyst very valuable as problem solver.


Constructive Conflict Is Better Than False Agreement

Over a decade ago, I was in a workshop with a range of different stakeholders.


Everything seemed to be going well, and people seemed to be agreeing and we were even running ahead of the meeting schedule.  Around halfway through the meeting a particular issue was being discussed, a conclusion was going to be drawn and a stakeholder interjected strongly and firmly with two powerful words.  They simply said:

“I disagree”

I remember being taken aback by the bluntness.  I live in the UK and our communication style is somewhat indirect most of the time.  It’s far more normal to say “Hmmm, interesting idea, or what about…?” which is code for “That’s a crazy idea”.  Or often the temptation might be to revert to the ultimate British stereotype and apologize “Sorry to be a pain here, but I’m not sure I entirely agree”.   I’m sure British culture is not the only one that has such indirect nuance.

The reason I remember this meeting so vividly, even more than a decade ago is that those two words initially made people visibly uncomfortable.  Someone was breaking the consensus; they were “creating conflict”.  Yet that wasn’t the intention, and of course they didn’t just say that, the stakeholder went on to explain the source of their disagreement, and what they proposed instead.  Thirty seconds later (once the stakeholder had explained themselves) any feeling of discomfort gently dispersed.  What’s more, other attendees of the meeting started to question things, interject and show disagreement.   One stakeholder questioning a decision had the apparent result in creating perceived permission for others to do so.  And you know what? I am convinced that the output of that meeting was better as a result.


Don’t Let Conflict Fester

Many of us have been taught to consider conflict as bad and consensus as good.  I suppose that is true in an ideal case, but if you’re working on any kind of large scale change how realistic is it that every stakeholder is really going to be ‘on the same page’ and in total agreement?  If a government implements a new type of tax and requires businesses to submit more information, there’s unlikely to be a standing ovation from business owners.  Yet that doesn’t mean that their input isn’t valuable—I would go as far as saying it’s essential!

Our fixation with consensus can lead to a situation where we achieve illusory agreement, a veneer of satisfaction.  Dissenting voices get marginalized, as they’ll never agree (so why spend too much time asking them?). We carefully facilitate meetings so that there aren’t big disruptive arguments, as we’re desperate to hit all of the aggressive (sorry ‘ambitious’) project deadlines. Yet this dangerous glossy veneer is very quickly broken when people start to interact with the product or service that we deliver. All we’ve done is defer the conflict to an even less convenient time, often a time when there’s so much political capital riding on the ‘solution’ that’s been designed that there’s no appetite to change it.

Cultivating Constructive Disagreement

As business analysts, we can help avoid these situations.  We have the opportunity to create space for constructive and respectful conflict, and we should certainly avoid us or others sidelining people just because they have contradictory views. In our analysis activities we should encourage constructive and respectful disagreement.

Taking an example, when setting up a workshop we have the perfect opportunity for creating the opportunity for a robust and respectful discussion.  We can lay down an appropriate set of ground rules that allow for differences of opinions to surface.  I’ve found myself opening workshops saying things such as:

“This is a controversial topic, and there are bound to be some differences of opinion.  That’s to be expected.  With that in mind please do speak up at any time and add your view, but please do be prepared to elaborate on it. Keep in mind I’ll be facilitating fiercely but fairly—and there might be times when I need to ‘park’ your item for later discussion. It absolutely won’t be lost, we will come back to it, but please don’t be offended if I need to do that.”

When we facilitate, we can actively prompt, asking questions such as:

“We seem to have complete agreement here; are there any contradictory thoughts. What have we missed?”

Ensuring that stakeholders have the ‘air time’, and ensuring that the most bombastic attendees don’t steal the limelight is crucial.  Using a range of tools and techniques in the workshop to consider not only what we want but also what could go wrong can be useful too.  Even just asking a question such as “That seemed too simple, might we have missed something?” can help.

Most of all, cultural nuances aside, we shouldn’t be afraid of the concise clarity of an expression such as “I disagree”.  When someone says it they provide us with a gift, an opportunity to better understand them.


Books To Bank On For Your Business: Five Top Reads For Avid Business Analysts

In the fast-paced world of business analysis, you live and learn from minute to minute. Keeping up with cutting-edge industry developments can be a Herculean task for even the most dedicated of business professionals.

So, when it comes to studying, ensure that you are expending your time wisely on quality learning from the best. Here to broaden your knowledge base, expand your vocabulary, and share insider experience, we have collated a small but perfectly formed reading list to equip anybody from post-graduate all the way up to leadership levels with the information needed to succeed. Rather than wasting your time wading your way through reams of useless information to garner a few insightful gems of wisdom when you could already be one step ahead in applying your newfound knowledge to your latest project, use our guide to the top five reads of the moment to help you cut straight to the chase.


1: ‘How To Lead In Product Management: Practices To Align Stakeholders, Guide Development Teams, And Create Value Together’ By Roman Pichle

Author of no less than four books and creator of his own blog alongside an educational product management podcast, Roman Pichler is your go-to consultant when it comes to leading in product management. Within the pages of Roman’s latest offering, you’ll find out how to guide your team successfully and to foster positive relationships with your stakeholders. While technical skills and knowledge of your industry are vital elements of leadership, Pichler lends his wisdom on the more nuanced aspects of the interpersonal relationships that must be cultivated as a good leader. This includes invaluable advice on building trust with your team, creating common goals, resolving challenging situations and maintaining your own wellbeing in this high-stakes environment.


2: ‘Seven Steps To Mastering Business Analysis (Business Analysis Professional Development)’ By Jamie Champagne

Written by Jamie Champagne, the first ever Hawaiian to become a Certified Business Analysis Professional, this book is a simple yet thorough guide to the complex world of business analysis. An insightful read for beginners and experts alike, Jamie uses her font of experience as founder of her own successful company, Champagne Collaborations, to provide seven clearly structured steps to business success. Champagne generously provides explanations of all key terms and concepts, alongside proven techniques that are coupled with real-life examples for ease of learning. A great resource for those studying for exams in the field, or for anybody looking to understand and  increase the value of their work or to broaden their professional horizon.




3: ‘Agile And Business Analysis’ By Debra Paul And Lynda Girvan

With 55 years of experience in the industry between the two of them, the brains behind Assist Knowledge Development Debra Paul and Linda Girvan have applied their expertise to an in-depth exploration into the use of Agile as an approach in business in this book. Paul and Girvan delve into what Agile means as a business analysis methodology, outlining their thoughts on it’s role in all of the most important aspects of business such as the understanding of customer requirements, the engagement of key stakeholders in the company or product, and the accurate measurement of how successfully the company is achieving its targets in relation to these.


4: ‘Agile Software Requirements: Lean Requirements Practices For Teams, Programs, And The Enterprise’ By Dean Leffingwell

With 30 years of experience in the software industry, Dean Leffingwell is an absolute authority in his field. Leffingwell generously shares his experience as the founding CEO of Requisite, Inc., and as Vice President of IBM’s Rational Software in a revolutionary compilation of his recommended best practices. No matter what your company structure of developmental process in the Agile business environment, Leffingwell has likely devised a business model to suit it. His application of the latest in Agile methodology, combined with his expertise in traditional management practices and lean product development creates an all-encompassing bible for anybody interested in getting the best from their business in terms of software requirements.


5: ‘Mastering The Requirements Process: Getting Requirements Right’ By Suzanne Robertson And James Robertson

Suzanne and James Robertson’s goal in writing this definitive guide to the requirements process was to teach business analysts how to identify requirements accurately, therefore ensuring an efficient and successful development process free from time and resource-wasting hiccups. Such has been the success of this detailed volume that it is now in it’s third edition, with constantly updated strategies that include information on how to apply it’s lessons to both traditional and to Agile business models. In this latest publication, the Robertsons have provided additional information on the Volere Knowledge Model and Requirements Process, the Brown Cow Model, as well as further chapters on specification templates, formality guides and story cards.

You can find more information about the writer at UKWritingsAcademized and State Of Writing


10 Principles for Working with Processes

Process: “a series of actions or events performed to make something or achieve a particular result, or a series of changes that happen naturally” Source: Cambridge Dictionary

When used correctly, process modelling is an invaluable activity, and along with process maps can be a powerful way of communicating of what is happening or should happen. At its simplest it helps us to decompose a process into a sequence of steps, with a defined start and end, and understand the various events that trigger specific actions. They can also help us to identify the users (‘actors’) and what their involvement is.

This provides the basis for analysis and optimization.

However, it can be easy to fall down the path of over-complication, especially when it comes to drawing up a process. Meaning that instead of being helpful, they can be time consuming and not fit for purpose.


Therefore, here are my set of 10 principles for working with processes, whether that be through a discovery activity to define an ‘as-is’ or through a design phase to build up a set of potential ‘to-be’ processes.

  1. Understand the purpose and why, before anything else — what are the models going to be used for? Is it to share with others to seek a consenus view on how something works? Is it to enable you to perform analysis activities off the back of? Is it to identify to a list of users (‘actors’) in an existing process?
  2. Consider your audience, and use notation frameworks sparingly. Notation frameworks such as UML and BPMN, can be helpful in the right circumstances. Especially as a ‘behind the scenes’ analytical aid. But, bear in mind, they often confuse many who haven’t had the same training.
  3. Focus on ‘just enough’, don’t let perfection be the enemy of good. Low-fi is generally fine, share early. Iterative process modelling is often the best form.
  4. Think about accessibility, when sharing process maps—not everyone may have a Visio or Lucid license. Consider the best tool so that everyone who needs to access it, can access it. If in doubt, export it as a PDF before sharing.
  5. Levels, know when you need them and when you don’t — you don’t need to model every level every time. However, you may need to understand something at a higher level first, before you can break it down further. All goes back to the purpose!
  6. Beware relying on previously documented processes — Beware of re-using or relying on the information in a previously modelled processes unless you have a robust process library, that is regularly maintained and with stringent change control. Processes have a shelf life!
  7. Consider sample size, like you would with any other type of research — there are documented processes, and then there are workarounds that users and customer actually do. Not everyone may approach or engage with it in the same way, so consider how many people you should speak to, in the same way you would with any other type of research activity.
  8. Talk to users who ‘do’ the processnot just the person who ‘owns’ the process. Expectations vs reality are often very different.
  9. Obsess over the events that trigger a process. They might be automated, such as triggered at a set time or upon a specific action being completed. They could be manual, triggered by an interaction from a user. Whatever, they are — invest time in understanding what they are, how they work and assess whether they’re helpful.
  10. Reference your contributors — its theirs, not yours — whether they’ve helped you to to understand how a current process works, or if they’ve been involved in designing an improved or new process. Not only is it polite, to reference those who you’ve collaborated with along the way, it‘s a helpful record when looking back. It may also prompt others, to suggest additional people who should be involved.




Lastly, remember processes are different to customer journey maps, service maps, business capabilities. Don’t be fooled into thinking that you don’t need to understand processes, if you have a good grasp on the customer journey or business capabilities. They provide different thinking and perspectives, and will uncover different information. Especially in discovery settings, processes are the closest you can get to understanding what is actually happening for all users involved. They also consider both visible and invisible triggers and events.