Skip to main content

Tag: Tools

The icon library: My favorite analogue tool

Written by Line Karkov on . Posted in Articles.

With the growing use of agile practices and design thinking, there is also a growing awareness of the importance of working visually. If you are an inexperienced drawer, this is can be a major barrier for starting with sketch noting, visual facilitation and graphic recording. In this article, I recommend establishing an icon library to document your learning and growth as a visual practitioner.

An icon library is my repository of the icons and symbols that I have used. I have it so that I can reuse icons by simply looking them up. And yes, it is in an analogue format. In fact, it is a notebook with each page divided into six squares and room for a name for the icon.

The icon library is my box of LEGO bricks. They are the building blocks, that I use when creating visual content. To work efficiently, it helps to actually think if it as a box of LEGO bricks. Meaning, when drawing I have what is available in my icon library. I can use color, size, and the relation to other elements in the visualization to convey meaning. I can also combine icons and thereby create new ones. In that respect, I can use it as a constraint that forces me to think more creatively. While building with LEGOs you usually do not have the option to just go out and get new bricks. You use what is available.

The senior LEGO designer Søren Dyrhøj advices to copy other people´s LEGO models with the bricks you have available. Because when you copy, you are practicing the skills you need to create something original. The same goes for visualizations. When you get started, do not worry about coming up with something unique. Look around you and use what you see; imagery used by your company and established modeling techniques, and do not be ashamed to look icons up online.

Advertisement

When I am not under pressure to deliver, I do take the time to come up with new icons and symbols while creating visualizations. I try to always have the discipline to add them to my icon library then. When I start working with new subject matters or domains, I always make sure to invest some time in coming up with icons and metaphors that I can use for visual content. Also, when I start engaging with a new group of end users, I create an icon for that user. Usually, 70-100% of the drawings I use, are from my icon library. The LEGO metaphor is also one that I have used several times before in different contexts. It is suitable for topics concerning IT architecture consisting of “building blocks”, and for illustrating collaboratively creating a product. Another reason why I like it is because it also refers to my cultural heritage as a Dane (LEGO is a Danish design icon that we are very proud of).

Sooner or later, it is highly recommended to learn from a professional visual practitioner. There are many options for training available, and several books on the topic. This will familiarize you with a visual alphabet, which will take your skills to the next level and enable you to create original content. I personally recommend the book “UZMO – Thinking with your pen” by Martin Haussmann, who is one of the pioneers in graphic facilitation. His bikablo concept is very useful and easy to learn.

Working visually in analogue formats can be a truly liberating experience because you are completely free of the constraints built into digital tools. It can also improve the way you process and present information when you get rid of the abstraction level of the keyboard, and thereby have a closer connection with your content. With the right approach established – e.g. having an icon library – you can work just as efficiently as when using digital tools.

Building 747s: A study of Traceability

Written by Anne Sams on . Posted in Articles. 1 Comment on Building 747s: A study of Traceability

Early in my career I was part of a project team that handled a variety of one-off projects.

The nature of the work meant that we were usually engaged mid-project and were expected to handle the Business Analysis and Project Management roles until project close.  We engaged in weekly team calls to discuss organizational goals and upcoming projects. 

“We’re building 747s in flight,” my manager would say proudly each time a concern was raised about how a project was to be handled.  

These conversations happened at a time before I identified as a Business Analyst and long before I had ever read the BABOK.  Even so, I distinctly remember wondering why these projects had to be done in flight.  Didn’t it make more sense to land the plane, figure out what we needed, start building, and then take off?

How did we get here? 

How did we get 30,000 feet in the air and not know where we were going?

I wish I could say those were the only times in my career where I was dropped into a project mid-flight with no parachute and the expectation that I could help build the plane before it landed or crashed, but that’s not true.  Whether it was through a new job, being brought in as an opportunity to organize what already exists, or simply realizing that the project in flight needs a BA, I have finished significantly more projects than I have started. 

When I am brought in mid-flight to a project I want to know “How did we get here?” When asked that way, I usually end up with blank stares or finger pointing as answers.  Instead, I’ve started asking “Do we have traceability for these requirements?”  This still gets me blank stares, but at least the finger pointing decreases. 

Traceability is the first task of Requirements Lifecycle Management, according to the BABOK.  The implication here is that not only is Traceability important, but it is the base on which all other tasks of the Requirements Life Cycle are managed.  So why does no one ever know if we have any?

Perhaps it comes from becoming a BA by circumstance instead of design.  Perhaps it’s because it has never been done that way before.  Perhaps it’s because the project team was so close that everyone was aware of all the requirements throughout the entirety of the project. 

Advertisement

Most likely it’s because people don’t know what traceability is and even if they do, it seems daunting.

Most things written about traceability are scholarly and technical.  They explain about numbering requirements and creating a matrix and documentation…It doesn’t need to be that complicated.

Instead, think of traceability as a list that needs to be checked at every step of the project, just like pilots have a checklist that they perform before getting in the plane each and every time.  They examine the plane from all angles, make sure all the equipment is working, and familiarize themselves with the plane before they ever leave the ground.  Even while in the air, the pilot is still performing checks.

Because most project I do are mid-air, I trace all the requirements backwards in order to understand where we are.  Sometimes the requirements may be as simple as “we need two wings”; or they may be significantly more complicated as we discuss thrust, lift, air speed, air pressure, and molecular structure of the metal.  Any project should have enough information that a BA thrown into it can use the checklist to review requirements during prototyping, solution design, User Acceptance Testing, and every other step of the project. 

Why is this important?

Imagine being brought into a project in flight, perhaps during UAT, and being presented with the fuselage of an airplane. The project was to build a 747.  Common sense says that airplanes have wings.  Looking through the artifacts, the original requirements say that the airplane should have wings.  The users were expecting wings. So why did the airplane get built without wings? How did we get here?  This is where the blank looks and finger pointing start.

But the truth is it doesn’t matter how we got here.  To move forward, the project needs to take some steps backward or the user is going to be presented with a half solution that requires workaround processes.  Either way, the end user isn’t happy and project deadlines are stretched because, along the way, someone forgot the wings and no one checked. 

In one instance, I was brought on to a project for which I was not the original BA, and was asked to sign off on test cases.  After evaluation, I determined there wasn’t enough information for me to sign off, despite growing pressure to complete this stage of the project.  The vendor with whom I was working could not trace the test cases to any of the requirements. Not only did I not write the original requirements, I couldn’t even find the original requirements.  Yet I was being asked if it was ok to move on to the next phase.  To have confidence in the next stage, I had to reinterview stakeholders, complete and organize information to provide a full picture, and review the test cases. The turbulence was manageable, but could’ve led to a crash landing. 

I did fly an actual plane once.  My instructor walked me through each step as I did it.  He told me how I was supposed to hold my hands, which gauges I needed to look at, and how to tilt the nose of the plane.  When he felt confident that I understood everything I was supposed to do, he let me fly on my own for a while before he instructed me in the last step of the process, landing.  Only when we were on the ground did he tell me that landing is the most dangerous part of flying.

With proper traceability, business analysis can be as easy as flying a plane. 

Taking on Current State Analysis

Written by Anne Sams on . Posted in Articles.

Business Analysts may feel pressured by the organizations in which they work to deliver requirements quicker.

It may be tempting to skip steps in order to deliver a product quicker, however Current State Analysis should never be skipped.

 Current State Analysis is an integral process with which Business Analysts should become intimately familiar.  The following cases illustrate the importance of a shared understanding of current state among all stakeholders in a project. 

Case #1

Not too long ago, I was pulled into a discussion about a Continuous Improvement item that had been in “In Requirements” status for 3 years without being closed.  “I need someone who can do use cases for this,” the Business Systems Analyst told me. 

She went on to explain that the Business was having difficulty explaining their requirements to the Developers and the Developers were upset that the business kept changing their requirements.  The developers outlined solutions based on the requirements given but the Business never felt satisfied with the solutions.  Needless to say the Steering Committee was unhappy with the entire situation and was pushing to get answers about whether or not this was even a viable ticket.  I brought out a use case template that I had used in the past and quickly discovered that there was not enough information to allow me to understand why the solutions kept failing to meet the user needs. 

I started doing interviews so that I could understand the current workflow that was causing distress to the end user. 

Case #2

Another time, a Continuous Improvement Item was handed off to me.  The structure of the company was arranged in such a way that the development team was aware of continuous improvement items before a BA was involved.  Often the developers had a solution in mind prior to requirements being written, this time included.  Because of unfamiliarity with the exact process that was being modified, I indicated that I needed to understand current state prior to writing requirements.

“Everyone knows current state,” he replied.  “The system isn’t working for this process.  It’s right there.”

I stuck my ground.  “Give me until tomorrow to get current state outlined” I pleaded.  He reluctantly agreed and left me in a room with a whiteboard and a junior developer. 

Advertisement

Case #3

There was an instance where I had spent hours interviewing stakeholders about how the integration was supposed to work.  I understood the business need clearly.  The information is needed to be fed into one system so that it could narrow down choices based on criteria set up on the back end of another system.  I diligently documented the process in each system and discovered that changing one piece of information would cause the whole structure to collapse.  I raised the risk.  The team responsible for the transition told me that these weren’t risks.  What had I missed?

In a world where systems evolve quickly and companies transition from Waterfall to Agile methods of project management, one thing that doesn’t change is the need for a shared understanding of the Business Problem., In the cases I illustrated, it was through Current State Analysis that the true requirements were discovered

In the first case, I created a non-traditional system diagram to show how the user input triggers combined with system functionality led to undesirable results because the developers and the end user had a different understanding of a single word.  The developer used the word to define a Process (verb) while the end user saw it as an Object (noun).

The original requirements documents did not point out this difference or the relationship between them. 

Outlining the current state allowed us the opportunity to redefine the ask and stop playing the blame game.  The development team finally understood why they felt like the user kept changing requirements and the user finally understood why the development team couldn’t give them a solution. 

Oftentimes in Business Analysis the old adage holds true that“ A picture is worth a thousand words.”  A current state diagram does not have to be fancy.  My simple method is to keep a notebook next to my desk where I draw sloppy pictures that help me articulate what I am seeing.  When a Waterfall Project requires it, I translate my scribbles into a Visio diagram that can be added to the ticket or the Requirements Package.  In a more Agile approach, my simple sketch may be enough to move us from point A to point B.

In the second case, the junior developer and I walked through the system and the code together to understand where the change needed to be made and why.  We called a meeting to walk through the current state with all stakeholders in the room. 

As we walked through the system and explained what the system was doing at each step, it turned out that not everyone did understand current state.

Because the developer and I had worked through what the system was doing and why together, we were able to move to a mutually acceptable solution more quickly.

In the third case, I had not walked through current state of the full process.  My logic kept failing because of one missed piece in a system that I did not have access to, instead of relying on other people to tell me what the system did.  After weeks of frustration, I finally had the end user walk me through the entire process from end to end.  My mistake was glaring at me.  By not having a complete understanding of current state, I could not make any solution work without asking for an unnecessary platform change.

Although often dismissed as “time-consuming” or “obvious”, Current State Analysis creates a shared understanding of the process that is essential to the success of Business Analysis work. Whether it’s formalized in a presentation, written on a cocktail napkin, or communicated in Morse Code Current State Analysis is invaluable to the BA process.

Rising to the Challenge

Written by Anna Rajander on . Posted in Articles. 1 Comment on Rising to the Challenge

Visions. Missions. Goals. Objectives. They are great for creating a shared understanding and bringing teams together for a common purpose… until they’re not.

Having a team contribute to the goals and objectives for their project or area can be a great way to communicate the organisations vision and promote team cohesion. Measuring progress against objectives can help maintain momentum and allow the team to see progress, identify issues, and share success.

Sounds great, right? Or alternatively…

Visions and goals are just overly-optimistic business jargon that serve no real purpose. They have no bearing on my work and discussing them is a waste of time when I could be doing something more important. Objectives are just a way for management to shirk their responsibilities, and measuring objectives leads to unnecessary paperwork and micromanagement.

As Business Analysts, it is drilled into us how important a shared vision and/or goal is when coordinating a team of individuals to implement and sustain business change. Cascading visions and objectives can be a great way to align work across an organisation, ensuring the goals and objectives of the component parts contribute to the organisation vision and/or mission as-a-whole. It is accepted practice to set, regularly review and tweak goals and objectives, and there are several techniques to support the discovery, definition, communication and monitoring of goals and objectives, including MOST, SMART, and Balanced Scorecards.

However, for some, it can be hard to see the point of goal and objective setting. There can be a variety of reasons for this, including but not limited to:

  •     Feeling threatened by the prospect of being managed/measured
  •     Disappointment with previous efforts to define and deliver on goals and objectives
  •     Difficulty seeing how the wider vision relates to their day-to-day work
  •     General resistance to change

In cases where you have several individuals that feel this way, trying to define goals and objectives as a group is likely to prove fruitless.

So how can you bring a team together without a shared goal? Are there other ways to create a clear, shared purpose for a team?

The Challenge.

An alternative to setting a goal is to set a challenge. Having a challenge to overcome can create the clear direction and purpose required to coordinate work across a team.

The difference between a goal and a challenge you ask? Not a lot.

Overcoming a challenge is as good a goal as any. However, while the end-result may be the same, the mindset for getting there can be quite different:

Advertisement
  •      ‘How can we contribute to the organisation vision?’ vs. ‘What challenges do we face in meeting the demands of the organisation?’
  • ‘What is our common purpose?’ vs. ‘What is stopping us from moving forward together?’
    •     ‘How do we measure progress against the objective?’ vs. ‘What steps have we taken to overcome the challenge?’

In the same way you can analyse and decompose goals to create objectives and requirements, a challenge can be further decomposed into target conditions and steps. Ultimately, challenges can be reworded to create goals, target conditions objectives, and steps requirements – meaning they can still be analysed and aligned to the visions/goals of the wider organisation/department.

Are there techniques that can help?

Yes, there are. More generic techniques such as Brainstorming, Mind Mapping and Affinity Mapping can help with the initial identification of challenges. However, when it comes to decomposing challenges into target conditions and steps, the A3 is a particularly useful technique.

The A3 (so named because they generally cover a single sheet of landscape A3) is a technique that has been developed and used as part of the Toyota Kata and adopted by Lean organisations. It is used to identify, define and manage process improvements. While Toyota uses A3’s as part of a wider process improvement philosophy and cultural mindset, an A3 can be a powerful stand-alone technique for supporting the discovery, definition and documentation of challenges, as well as record any progress in overcoming them.

The main idea behind the A3 can be summarised in four simple steps:

  1.      Understand the Challenge
  2.      Grasp the Current Condition
  3.      Establish the next Target Condition
  4.      Experiment towards the Target Condition

Templates for setting out an A3 vary. I have provided an example below. However, it is important to note that regardless of how sections are laid out on the page, it is important that the four key elements of the A3 are tackled in the order set out above – Challenge, Current Condition, Target Condition, Experiments. It’s also important to realise that the Target Condition should be the next Target Condition – there may be multiple Target Conditions before a Challenge is overcome.

ranaj

There are a couple of benefits to using the A3 technique:

  •     Its very logical, so will likely suit people who have a more logical mindset
  •     It’s can be used as a way of documenting and allocating discrete pieces of work
  •     It works well for situations where the path from the Current to the Target Condition is unclear, allowing time to think, explore options, and experiment – rather than feeling forced to articulate a solution straight away.

In the end…

Challenges and Target Conditions may be used as an alternative to the traditional approach of setting cascading goals and objectives. Involving team members in the process of discovering and defining challenges can be a good team-building exercise, especially in circumstances where a team feel removed from the vision of the wider organisation. A3’s can be used as a framework for documenting challenges and working towards overcoming them. While not a panacea for dealing with resistors and detractors, it is another tool that may prove useful in any journey the involves coordinating groups of people, aligning goals and objectives, and creating a shared vision to support the successful implementation of business change.  

Resources:

Toyota Kata: Managing People for Improvement, Rother, Mike, 2009.

Anna Rajander, February 2021.