Tag: Agile

Improve Prioritization Using a Combination of Techniques

Written by Steve Jones on September 28, 2022. Posted in Articles.

Software development projects have a long history of unsuccessful delivery for myriad reasons. A lack of success is often determined by what didn’t make it into the final product release; like a core functionality, while some enhancement items did make it in. This begs the question, “Why weren’t all of the core capabilities the focus until they were complete?”

Rarely does everything in the requirements get implemented, so knowing the core capabilities is necessary to keep from getting derailed by enhancement requests. When a project includes multiple stakeholders, it isn’t uncommon they end up fighting for the wrong thing as it relates to the project, “their stories.” What gets lost in all the fighting over each stakeholder’s “priorities” is the real goal – achieving the right outcomes for and by the project.

What’s the problem?

TLDR: There are challenges when using just one prioritization technique to provide guidance of what to work on next.

User stories and requirements can be prioritized using several different techniques (Ranked Order, MoSCoW, Scaled, $1/$100, High/Med/Low, Story Mapping, Weighted Shortest Job First [or WSJF], to name a few), with different benefits and drawbacks to each of them.

Ranked order, i.e., setting out to identify the explicit order to be worked, is a very time-consuming challenge. Changes, whether from business decisions or technical limitations, can happen at any time during the project and cause a reshuffle every time they occur.
Using fixed amount methods to prioritize, such as the $1 or $100 methods, are good at giving clear indications of importance by virtue of the highest number. Fixed values limit the number of stories that can be created without resorting to restructuring the whole valuation system. On reviews and revisits, any change forces a recalculation of many stories.
Categories produce multiple stories with the same value (many ‘High’ or ‘Must have’) that do not always provide enough information to know priority. When there are so many with the same value, it forces a break in the effort to know what should be worked on next, unless a tie-breaking method is already defined.
Story Mapping helps manage the big picture of the project since it displays all themes / activities of users. The themes and activities are ordered along a top row, then broken down into smaller stories and ranked in priority. Early in the project, the number of stories and ranking effort is focused, more easily identifying high value functions / stories.
Weighted Shortest-Job First, WSJF (pronounced wiz-jif), rates each story on business value, time criticality, and risk reduction / opportunity enablement (the business valuation, known as ‘Cost of Delay’), as well as factoring in the IT effort to deliver the story. With several criteria getting a valuation for each story, it becomes easier to see the highest business priorities to work on next. This can still mask the core needs that must be delivered.

Another challenge to prioritizing arises with many of these techniques when new stories are added. Sometimes a key requirement is missed during early analysis or through story decomposition and story splitting. Other times, demonstrations of work inspire new requests or research identifies a new need. How are the new stories valued, ranked, categorized? Do the newly added stories all get the same value as the original when split or does the ranking need to be done again? What becomes of highly valued stories which are just enhancements? Enhancements may have higher business value than some core technical stories. Some of these techniques handle additional stories more easily than others.

Maintaining prioritization is a challenge in itself

Capturing all this prioritization detail can be a frustrating challenge but maintaining it over time is just as frustrating. If you have a software tool that can automatically adjust rankings, some of these techniques may not be as much of a problem. But what if you are using physical cards or sticky notes to keep it all organized? It becomes a tedious task to manage the series, which will drive some to stop updating after a while, especially after repeated changes. Choose your method of prioritizing wisely, you will likely use it often.

How do we solve it?

Story Mapping is an effective approach to keeping an eye on the big picture goals without getting lost in the details. This is beneficial as it provides a more complete end-to-end view of the project, in addition to providing a view of the lower-level details in accompanying stories. Each of these stories can then be identified as a core ‘must have’ vs a ‘nice to have’ enhancement.

Combining multiple techniques simplifies project priority determination. For example, utilizing the business valuation portion from the WSJF does a good job identifying the value for any given story. The valuation can be used for easier ranking without the need to constantly revalue everything below (see Figure 1). In addition to identifying the value of each story, it is very helpful to identify what is needed for core delivery and what is enhancement. When splitting a story, make sure core functionality is clearly differentiated from what may be an enhancement.

Taken in combination, stories are identified as a core delivery need or enhancement AND with each story’s individual business value (the number inside the ovals in Figure 1). While there may be enhancement stories with high value (sometimes viewed as the next shiny new thing), they may not be core functionality. Keeping the high-level view of core delivery items distinct from enhancements enables the focus to stay on outcomes. This perspective can be crucial to maintaining reasonable prioritization efforts in limiting unnecessary re-work of rankings, and identifying enhancement stories to address after all the core functionality is complete.

In the end, using more than one technique to manage project and product priorities ensures that the team is focused on getting the right overall outcomes, instead of persistent debate over individual stories. Practice quality communication and utilize your tool kit to experiment in finding what works best with your stakeholders and team.

Think “Re-use” When Writing Requirements

Written by Adrian Reed on July 28, 2022. Posted in Articles.

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

Written by Esta Lessing on July 27, 2022. Posted in Articles.

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.

Conclusion

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.

10 Principles for Working with Processes

Written by Jamie Toyne on July 14, 2022. Posted in Articles.

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.

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?
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.
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.
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.
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!
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!
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.
Talk to users who ‘do’ the process, not just the person who ‘owns’ the process. Expectations vs reality are often very different.
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.
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.

Why Good Business Analysis Involves More Than Gathering and Managing Requirements

Written by Indu Koul on July 13, 2022. Posted in Articles.

While the basic function of a Business Analyst (BA) may be broadly understood as gathering, developing and managing business requirements, so many more activities contribute to effective and authentic business analysis practice.

Good business analysis ultimately results in wide-scale improvements and value creation as well as a deeper and clearer understanding of technology and its purpose across an entire organization.

Outside of requirements management, here are just a few of the important elements of effective business analysis.

Budgeting, financial forecasting, modelling and reporting

Generally, BAs are engaged with a project after the project is approved with defined budget and timelines. However, this practice can produce many challenges and limited project success. Challenges include not fit-for-purpose solutions, scope creep, budget variations, limited usage of existing enterprise platforms, multiplying applications of similar functionality … and an end result of insignificant business value.

To address this, BAs at VU conduct a minor but critical analysis prior to projects commencing in order to approve and assign budget to the project. We call this a short mandatory analysis to check the viability of the project, focus on identifying the value of the project and aligning it with VU’s IGNITE framework Value Identification Phase.

Running for 3-4 weeks, this process is led by BAs to understand the business problems and various solution options (internal/external) with a priority of assessing internal enterprise platforms first. The short analysis consists of:

Understanding the business problems through user journey maps.
Building a blueprint of high-level AS IS process.
Identifying gaps in AS IS process.
Building blueprint of TO BE process.
Identifying Minimal Viable Product (MVP) deliverable within a few sprints.
Devising context solution overview that shows the overall system with user interaction and dependency on other systems (this identifies the impact on existing systems and their integration points, and the impact on other business areas).
Providing solution options keeping future in mind.

The outcome of the analysis is shared with vendors for quotation. The MVP option becomes vital in establishing realistic budget and timelines for the project. Post analysis, BA inputs become critical to submission of New Initiative Funds Request (NIFR) to justify the existence of a project through its value and benefits.

A pilot of the short analysis was conducted in 2021 with VU’s introduction of a new Academic Integrity Register. The Academic Integrity Register is an online system developed to record, report and support academic decision-making in relation to academic integrity concerns and breaches of students studying in the higher education and vocational education sector.

Identifying stakeholders and managing expectations

Identifying relevant stakeholders at the commencement of the project is as important as assigning stable budget to the project. At VU, BAs identify stakeholders and map them through a tool known as a Stakeholder Power Interest Map. The mapping is conducted collaboratively by the business team, communications team and the BA. This helps stakeholders visualize the importance and relevance of the project. Stakeholders can vary from business sponsors to business owners and end users to operational support teams. Mapping demonstrates the stakeholder’s power and interest in the project which tells us how we have to manage their involvement and expectations.

To return to our Academic Integrity Register Project as an example, there were business owners, business sponsors, and roughly 2000 academics as end users of the system. At the commencement of a project, BAs should work closely with business owners to develop a communication plan which includes who needs to be involved at which stage of the project. For example, with our Academic Integrity Register project, business teams led by business owners were involved at all design related workshops and system testing phases. However, it was not possible to involve thousands of end users in User Acceptance testing (UAT), so we asked for senior representatives from each stakeholder group to participate and ensure transition to the new system was successful. These senior representatives became champions of VU’s Academic Integrity Register digital transformation.

Another critical aspect of stakeholder engagement is formulating a Project Control Board. The project owner (business sponsor) assembles a Project Control Board (PCB) and its members to assist in oversight and decision making needed to drive delivery of the project outcomes. BAs identify risks and issues and provide recommendations on approach which are presented at PCB for approval. The PCB also helps in maintaining buy-in and interest of senior leadership.

Seeking opportunities for greater value creation/realization beyond the immediate solutions required

A system implementation is successful only when the system is used and exploited by end users to a level that value is generated, and business benefits are realized during a defined period of time. For a system to continuously generate value, it has to be designed with future needs in mind. In all projects, though we focus on resolving immediate business needs through delivering MVPs, the entire system architecture should be designed based on future needs and solution expansions.

It goes without saying that implementing a system, deploying it to end users, and asking them to use it without bringing them on a project journey is a big risk to value generation. That’s why it’s essential to ensure representation of each user group at all stages of the project. Taking users along the journey with you keeps them invested and interested. This practice becomes a critical part of value realization. Users must not only accept the system but use it to a level that more opportunities are identified to improve the system, processes and solution itself.

A successful project with high acceptance from end users automatically opens doors for further opportunities in terms of engagement with other strategic prospects, process improvement, building branding through enhancing reputations. For instance, our Academic Integrity Register project enabled many across the business to learn more about CRM products which helped in product selection for other business areas. Project teams, including BAs, became recognized for their expertise and engaged in other strategic initiatives where learnings from this project could be applied.

Building beneficial relationships – not only with stakeholders but with developers, architects and partners

BAs lead the analysis of business needs, articulate the needs, perform market analysis and internal platform analysis, Request for Information (RFI), Request for proposals (RFP), product selection and vendor on-boarding. Though the BA leads these initial activities, they require Subject Matter Experts (SMEs) from other areas to ensure all the ends meet. For example, BAs collaborate with architects for establishing architecture vision and solution design, and with cybersecurity teams to ensure cyber risk assessment is conducted prior to vendor and product selection. If a decision is made to leverage a third-party provider for implementation to achieve cost saving or shift special functions to more experienced providers, BAs collaborate with partners to ensure the product is built per the business requirements and is fit for purpose. Partnering with external providers comes with its own risks and BAs have to manage these risks and ensure the project continues to be managed effectively.

Historically third-party partners have worked in a more siloed way, creating systems based simply on what was presented to them in the business’ technical specifications document. However, today there is a set of expectations on partners and their developers to add further value to the system implementation and its processes by providing their expert views and leveraging past experiences. This requires a great deal of collaboration, trust and strong partnership between BAs and implementation partners.

Our Academic Integrity Register solution was developed by a third-party partner. Over the duration of the project, a great relationship was built between BAs and the third-party partner. Post success of the project, the third party became VU’s strategic partner in managing the services through a managed service agreement. Win-win.

In summary, experienced and effective Business Analysts observe the pattern of business operations. Findings through these patterns become essential in driving solution recommendation, direction in investments, and alignment in the strategic roadmap.