Tag: All

‘Twas the Night before Implementation

Written by Aaron Whittenberger on December 21, 2022. Posted in Articles.

‘Twas the night before implementation and all through the warehouse

not a program was working, not even a browse.

The programmers hung by their screens in such despair,

with hopes that soon, a miracle would be there.

The users were nestled all snug in their beds,
while visions of working systems danced in their heads.

When out in the snow there arose such a clatter,

I sprang from my desk to see what was the matter.

Away to the window I flew in a flash,

tore open the shutter, and threw up the sash.

And what to my wondering eyes would appear,

but a Senior Business Analyst with a six-pack of beer.

His resume glowed with experience so dear,

I knew in a moment; the miracle was here!

More rapid than the programmers could consume, his requirements they came,

and he shouted and clamored and called them all by name:

“Now Update! Now Inquiry!

Now, Create and Delete!

On Batch Job! On Interface!

On, Closing and Functions Complete!

To this programmer! and to that programmer!

Now code away! Code away!

Code away all!”

He was dressed in a tux, from his head to his foot,

and his clothes were bright, all glowing and afoot.

His eyes—how they shined! Fingers nimble and lean,

from weeks and weeks in front of the screen.

His cute little mouth was drawn up in a smile,

and his hair, every strand in place as he worked a mile.

He stopped only to take a swig of his beer,

as the work ahead circled in the atmosphere.

He worked so fast, and smiled aware of his self,

and I looked upon his work with dismay, in spite of myself.

A wink of his eye and a twitch of his head,

soon gave me to know I had nothing to dread.

He spoke not a word, but went straight to work in great affair,

turning out specs and models with such flair!

And laying his finger upon the “Enter” key,

and giving a wink, the system came to life to a tee!

The updates updated, the deletes deleted,

the inquires inquired and the functions completed!

The testers tested each whistle, and tested each bell

with nary an abend, all had gone well!

The system was finished, the tests were concluded,

the users’ last changes were even included.

And the client exclaimed with a snarl and taunted,

“That’s not what I asked for, but exactly what I wanted!”

–Aaron Whittenberger

The Importance of Creativity in Business Analysis

Written by Giorgos Sioutzos on September 14, 2022. Posted in Articles.

Being creative may seem contradictory to an analyst structured approach to everyday tasks but this is far away from truth. Creativity is something required in every aspect of our life. Although, a deterministic approach is synonymous to analysis and decisions are being made using careful research, still there is much room for creativity.

In the business analysis field, the aim of developing creativity as a skill is to provide value to the whole business analysis lifecycle and to contribute not only to better outputs but also to significant outcomes.

Below are just some occasions when creativity can be required from a business analyst:

Creativity is required in finding the best way to elicit the actual business needs. You may modify and tailor an elicitation technique in order to achieve the most accurate and helpful results from elicitation activities. A creative business analyst will pose “clever” questions in order to better understand the customer. Will continuously modify predefined techniques in order to tailor them in accordance with the context and the special needs of the stakeholders.

In case there is not a predefined product that will be used, and the solution is built from the scratch, creativity is detrimental in order to find feasibly solutions that will provide value to the end users.

Business analysts advocate for the business while communicating what can be achieved with available technology. The way business analyst will transfer the information from one side to another requires creativity. Providing a bridge between technical and business viewpoints is sometimes challenging. Unorthodox ways of presentation and communication of the information may be the key.

Drawing out additional meaning from the elicitation results requires creativity resulting from a creative dispute mindset. Asking what the actual need of the customer is and how might the end user has defined the success imply sometimes filling information gaps using creative thinking.

Creativity skills can be learned and improved throughout professional life. What you first need is a desire to explore your unique creativity and a spirit of curiosity. Just ask yourself and try to come up with creative ideas in your everyday tasks. The most important is to be critical against conventional wisdom and try always to take into consideration the context in order to tailor and use wisely the conventional wisdom.

The Importance of Creativity in Business Analysis

Written by Giorgos Sioutzos on August 11, 2022. Posted in Articles.

Below are just some occasions when creativity can be required from a business analyst:

Creativity is required in finding the best way to elicit the actual business needs. You may modify and tailor an elicitation technique in order to achieve the most accurate and helpful results from elicitation activities. A creative business analyst will pose “clever” questions in order to better understand the customer. Will continuously modify predefined techniques in order to tailor them in accordance with the context and the special needs of the stakeholders.

In case there is not a predefined product that will be used, and the solution is bult from the scratch, creativity is detrimental in order to find feasibly solutions that will provide value to the end users.

Business analysts advocate for the business while communicating what can be achieved with available technology. They way business analyst will transfer the information from one side to another requires creativity. Providing a bridge between technical and business viewpoints is sometimes challenging. Unorthodox ways of presentation and communication of the information may be the key.

Drawing out additional meaning from the elicitation results requires creativity resulting from a creative dispute mindset. Asking what the actual need of the customer is and how might the end user has defined the success imply sometimes filling information gaps using creative thinking.

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.