Tag: Assessment

Analysis Efficiencies: Turning The Mirror On Ourselves

Written by Adrian Reed on June 23, 2022. Posted in Articles.

As analysts, typically we’ll spend a lot of time examining and critiquing the processes of other departments. We might be looking for ways to make an operational process slicker, quicker and ‘better’, or we might be looking to solve particular problems. There are a whole set of elicitation, problem analysis and process analysis techniques in our toolkit that help us do this. Yet how often do we turn these tools in on ourselves to examine our own practices to see if there are ways that we can improve? As practitioners of change, surely we should be looking to continually improve ourselves too?

I suspect we all intuitively do this, at least to a degree, but I wonder if it’s an area where there’s room for improvement. I’ve included some examples to whet your appetite below:

Deciding How To Decide: Have you ever got to an approval gateway in a predictive (waterfall-type) project and it’s unclear who needs to make the approval? Or the approver shirks responsibility? This can manifest differently on adaptive (agile/evolutionary) initiatives, for example with wrangling over the ‘definition of done’ with different stakeholders having different (and unresolved) perspectives. These things can fester if unresolved, perhaps stakeholders concede in the short term and sign on the dotted line, but resentment builds and bubbles up, only to explode out later at the most inconvenient time.

This creates friction and drama that takes time to resolve, and when it comes to organizational change, time is money. It’s therefore beneficial to spend a little bit of time up front agreeing how these types of decisions will be made. This sounds so obvious doesn’t it? Yet, so often in the blind rush to “just get going” it isn’t discussed… and it is only as the decision emerges is the omission spotted. Practical tools such as the RACI matrix can be extremely useful here.

Planning the Requirements Architecture: When BABOK® v3 was released back in 2015, one of many significant additions was a more explicit recognition of requirements architecture. If you have ever found yourself mid-project with a whole set of useful, but disparate requirements artifacts (“These process models are great. But how on earth do they relate to those user journeys, these scenarios and those wireframes?!) you’ll know what I mean.

Taking time up front to quickly and roughly sketch out how it’s anticipated that the requirements will fit together helps avoid this. Of course, things change, as requirements emerge, new types of artifacts suddenly become relevant (“Ah, so statuses are important… I think I’ll include a state transition model…”), however having a starting point to deviate from when appropriate is better than fumbling around in the fog.

On a legislative project, you might write a quick problem statement to act as a high-level goal/outcome, and define some critical success factors/key performance indicators which will act as desired outcomes. These will all link to the organization being compliant with a piece of legislation, that’s another (external) artifact, but one which some rules can be derived from. Those rules will include internal decisions about how the legislation is interpreted; so those probably need to be captured too. Those rules might be automated or orchestrated via processes, and there might be steps in a process which will be automated via some detailed functional solution requirements. You can see how these different concepts relate to each other here; and of course there will be other types of artifacts too. The point is that creating a quick sketch showing how the concepts map together before creating them will prevent artifacts from being created that don’t clearly relate to each other.

Planning How To Store/Manage Requirements Artefacts: If you’re lucky, you’ll have some form of requirements (or story) management tool. If that’s the case, does everyone actually know how to use it? Is there a common agreement around how things like priorities/statuses and other metadata will be used? If not, will this create noise and friction as the initiative progresses? If so, a short discussion up-front is likely to yield significant benefit.

If you are using documents and a shared document repository (e.g. word processing tools, drawing tools, spreadsheets etc.), decide things like naming conventions and version control conventions up front. It can be very confusing when someone in the team is using a file naming convention that uses “v0.1”, “v0.2” then “v1.0” when it’s signed off, when another person is using “FILENAME v1.0 (Updated) (Second Updates) (Final) (Really Final This Time) (Updated Again).docx”

Plan For The Analyst And Stakeholder Of Tomorrow: Stuff you’re creating today will be useful for the analysts and stakeholders of tomorrow. That process model you’ve created? If it’s detailed enough, I bet the training team would love to use it, and the operations team might too. It might be the catalyst to the creation of a single, unified process repository (if that doesn’t already exist in your organization).

Those performance non-functional requirements for your customer-facing website? You know, the ones that were like pulling teeth to elicit, that required benchmarking and speaking to the technical folk? They might be a useful baseline and starting point for others producing customer-facing web applications within your organization.

As we create artifacts, we ought to be thinking not just about how they can be used today, but how they might be used tomorrow and how we can ensure they will be found. This is a much bigger, organizational, question—however it’s one of the many areas where BAs can nudge the agenda. By creating common pools of knowledge, and by encouraging information sharing we open up channels for these types of artifacts to flow. This has the advantage that information flows in both directions and also that there will be a wider range of documents available at the start of projects too.

Of course, these are only four suggestions, there will be many more. The key is that we shouldn’t rest on our laurels; as BAs we should be looking to hone our craft and improve the efficiency and effectiveness as much as we can. This involves not just “speeding to get the job done”, but also thinking about the stakeholders of tomorrow!

10 Characteristics of an Awesome Business Analyst

Written by Brad Egeland on March 1, 2016. Posted in Articles. 2 Comments on 10 Characteristics of an Awesome Business Analyst

Does your organization handle large, complex technical projects? Do you have diversely skilled project teams assigned to those projects? How about overloaded project managers? Are they juggling several projects at once?

This sounds like every organization I’ve managed projects in and every company that I’ve consulted for along the way.

If this is your organization, too, then you likely need the best of the best in terms of a business analyst on each project being led and executed on for the project customers your organization is serving.

If you do need the “best of the best”, then what skills or characteristics are you looking for? What defines the best for your organization’s project needs?

While BAs are not project managers, the most successful BAs manage the entire business analysis effort. This means that the BA is proactive and dependency-aware. It also means they manage themselves well, the stay on track with respect to commitments and deadlines, and can handle task delegation, decision-making, and issue management as needed on the project.

I’ve thought about the overall skill set and characteristics needed to conduct this role efficiently and productively. Coupled it with my experience leading projects, working in combined project manager and business analyst roles I’ve come up with my list of ten characteristics of an awesome business analyst.

{module ad 300×100 Large mobile}

As you are reading through these, please be thinking of your own personal experiences and comment with your additions to this list.

Great customer interface. The great business analyst is a critical liaison between the project manager and the technical team. This person is often the driving force behind the accurate, complete, and detailed documentation of the final project requirements. Why? Because the organizational to tech cross-over ability and skills that many project managers will lack must be handled in this role. And they help the tech lead interpret those functional design ideas into technical design specifications for the design and development work on complex technical solutions.

Subject matter expert. The skilled business analyst is vital in their project team role as a subject matter expert. This helps them to work with the client to document accurate business processes that are then used to create detailed, complete, and accurate project requirements.

The business analyst’s technical knowledge coupled with his understanding of the design process and the likely end solution makes him an invaluable resource for the project manager the project team and the project client.

Good technical cross-over. The very valuable business analyst has a diverse amount of technical knowledge. Not necessarily tech lead or developer knowledge, though that is a plus, but rather a very good technical acumen that gels with the project management-type organizational skills and knowledge they also likely possess.

Can project manage it when needed. The indispensable business analyst can and often acts in the role of project manager, both when the project manager may be tied up on another project and also when interfacing with the team and client and a decision needs to be made if the project manager isn’t currently available.

Critical attention to detail. Detail-oriented focus is needed by the business analyst on the project for a variety of reasons: to assist the project manager and fill in there as needed, to work closely with the customer sponsor and team and the project team to define and document requirements, and to help track and resolve issues throughout the engagement.

Skilled communicator. I’ve often said that communication is Job One for the project manager. However, communication skills are possibly the most important characteristic of the awesome business analyst if for no other reason than the vast responsibilities this position has on the project and with the team and customer.

Miscommunication can lead to so many problems on the project. The awesome business analyst ends up interfacing with all stakeholders, making accurate and thorough communication necessary.

Facilitation skills. The business analyst is going to be required to facilitate many meetings and sessions during the project such as periodically leading the team meetings and formal project status meetings for the project manager and then requirements meetings with the customer as well as design sessions with the technical project team.

Experienced critical thinker. Business analysts are responsible for evaluating multiple options before helping a team settle on a solution. While discovering the problem to be solved, business analysts must listen to stakeholder needs but also critically consider those needs and ask probing questions until the real need is surfaced and understood. This is what makes critical thinking and evaluation skills important for the business analyst on the project.

Skilled with PM and organizational tools. The business analyst needs to have a good command of the use of various project management related tools such as project scheduling software, basic tools like Word, Excel and PowerPoint, and others that might be needed such as task management software, bug tracking software, risk management software, file management software, and even modeling tools like Visio, etc.

Conflict resolution. From time to time conflicts can arise. I’m not talking about fisticuffs…at least I hope not. But disagreements among technical team members or with members of the customer’s staff can arise. The skilled BA will recognize this quickly and work with both sides to come to a mutual agreement. Patience is also a virtue because any conflict resolution requires patience and understanding. And good listening skills.

Summary / call for input

The business analyst isn’t necessarily the leader on the project, but his role may be the most diverse and sometimes the most critically necessary for project success. The project manager will serve as the overall communicator and decision maker on the project, but the business analyst will likely have an even closer customer facing role than the project manager, meaning this position may be the most valuable in helping ensure customer satisfaction and completeness and acceptance of project work performed by the project team.

How about our readers? If you’re a business analyst, what do you think about this list? What would you add to or remove from this list? What are your top 3 or top 5 characteristics for a valuable business analyst? Some organizations – often smaller organizations – may only hire a project manager or business analyst to handle both roles. Have you worked with such an organization and did you find it to be successful?

The Business of Process Analysis

Written by Anton Oosthuizen on December 15, 2015. Posted in Articles.

As Business Analysts, we’ve probably all had to map processes. But the question is ‘did we succeed in what we set out to do?’

Process analysis and its subsequent mapping are seemingly very rudimentary business analysis skills. It is something that a Business Analyst should be able to handle even at a fairly junior level. When we set out to perform process analysis do we really understand what we are trying to get out of it and are we properly prepared to deal with whatever the result?
Thinking back over my time as an analyst I can recall quite a few times where I would be doing process analysis in a fully prepared state, or so I thought, but in hindsight, I was doing little more than conducting meetings and doing even less with the results.

So why would we do process analysis in the first place? To understand the AS IS state is one obvious reason. Another common response would be that it needs to be done as part of a contractual deliverable. But even in the absence if these most basic reasons there are many other good reasons why we should be doing it.

Let’s Visualize our World

Doing process analysis and mapping out the results allows all stakeholders to see the bigger picture, and not just their part of it. Whether they like what they see or not is irrelevant. What is relevant is the fact that the bigger picture stirs up a lot of discussions which leads to the second reason why we do it.

Solve the Problem

All the talking and discussions that result from a process map gets the creative juices flowing and not only helps stakeholders to rethink those processes where they knew they were not doing too well but, more importantly, help them rethink those processes that they thought they were doing great.

Identify Functional Gaps

Potentially the most dangerous reason why we do process analysis. I say this because you have the very real danger of exposing functional gaps in your supporting systems during the analysis process. Hopefully, there is room to close these gaps but there is also the danger that they cannot be closed within the scope of an existing project. I mention that it is potentially dangerous but not exposing such gaps can be even worse.

Once you know why you want, or need, to do process analysis and you understand how to manage the possible outfall the rest is fairly simple.

Know Your Stakeholders

Getting to know your stakeholders means that you have an understanding of how they interact and where they fit into the bigger organization.

Select Techniques

People, in general, tend to become set in their ways when they are not actively challenged. Business Analysts are no different so reevaluating your approach and techniques is always a good idea. Sure, the way you have done things in the past worked so don’t fix it if it ain’t broke right? Maybe. But every audience is different and the techniques that you will use needs relatable. Remember that the stakeholders will be (should be) active participants in your analysis process and for somebody to be active they need to be engaged. You cannot engage somebody in something they do not relate to. No matter what techniques you decide on you can improve the efficiency by

Conducting Research

Research as an analysis technique is often neglected. Doing research to understand the background of what you are trying to achieve is vital and will give you an important head start. One of the key aspects of facilitating a process analysis workshop is the ability to question everything, but the line of questioning should be aligned with fact. Your research will provide you with these facts. Try to be as unobtrusive as possible when researching and stick to the basics. DO NOT be tempted to skim over something during the workshop sessions because you already KNOW it.

Being Agile

Select a technique that will allow you to be agile. Things can change quickly during a workshop session, and you do not want to be apologizing for spending lots of time fixing or changing something. While a whiteboard allows you to erase or redo anything, it becomes a bit messy when you are at gate 34, and you need to make a change at gate 2. Messy is a fact of life when it comes to process mapping workshops, but it must be a good messy i.e. controlled chaos. I prefer using post-it notes on flip chart pages. Depending on the process I would stick the flip chart page onto a wall and proceed to draw out the process using the post-it notes. The post-it notes allow me to be very agile while the flip chart pages allow me to expand in any direction. While I tend to stick to the more conservative side, the availability of post-it shapes and colours allows you to be very creative.

Being Comfortable

Stick to techniques that you are comfortable using. Hopefully, as a Business Analyst, you are comfortable in your position as a facilitator but that only gets you to the point where you need to use a technique or tool. Stakeholders can smell blood in the water, especially hostile ones. If you do decide on a technique or tool that you are not 100% comfortable using, then practice until you are. An analysis workshop is not the time to ‘wing’ it.

The Workshop

This is where the rubber meets the road, where all the preparation you have done pays off. You did prepare, right? Who goes into a meeting or workshop as a facilitator and do not prepare? Well, there is prepare, and then there is PREPARE. I’ve done both, and I can tell you that they are not equal. So some pointers when the time comes to show off your skills.

Ensure everything works. If you are using a technique that requires that a large open space, make sure the technique is possible in the actual venue. Keep factors like lighting, ventilation, and accessibility in mind.
Engage ALL stakeholders. Make sure that the seating positions are arranged to ensure that everybody has an equal opportunity to participate. Remember that they might not even need a table in front of them and even standing in a semi-circle around a chart could work with a small group. Standup meetings have been proven to be a great way to get people going, and keep them going. It can apply to a workshop too.
Question everything, well almost. Not only is it a very effective way of engaging stakeholders, but asking questions also makes them think. You did your research so you have some facts that you could use to raise sensible questions.
Focus on the AS IS. While it might be very tempting to show off you prowess as a Business Analyst by highlighting shortfalls in the existing processes, it is much more effective to focus on what they are currently doing. The time to fix it will come soon enough. But don’t squash ideas coming from stakeholders. Save these ideas for consideration during the TO BE process designs.

The workshop is done, and you have walked away with a heap of information. It is time to produce the output, probably in the form of an analysis report containing the AS IS and TO BE states for the processes you have mapped. The output is as, if not more important than the actual workshop. While only a select group attended the workshop, the report will find its way to many who were not part of this initial process.

Use a format that all stakeholders can relate to and understand. Most people are familiar with the basic flow diagram and decision gateways, so that is a good starting point.
Breakdown big processes into smaller sub-processes for easier reading.
If your objective was process improvement, make sure that the proposed TO BE state is something that can be supported, either by the project scope or supporting systems.
Make sure to spell out clearly what can be achieved and what cannot. You might want to map out TO BE states in a phased approach when the best possible solution cannot be implemented within the current scope constraint.
Highlight changes that will have a significant impact on resources. These impacts could be training or hiring needs.
Most importantly, produce the output as soon as possible. Do not be tempted to reprioritize activities just because you have taken careful notes of all the proceedings.

And you are done. There are few things as satisfying as delivering a good quality document to stakeholders that they can understand and agree on. The cherry on top is actually implementing the improved process changes. But all this success is only possible if you used the right techniques and tools, prepared properly and produced quality documentation.

Early Startup Go Project Manager or Business Analyst?

Written by Brad Egeland on November 30, 2015. Posted in Articles.

You’re an early startup bringing in new projects to work on. Clearly you need help. You need some structure. You need organization.

Your customers love your work but a couple of times it’s become obvious that the most senior techs need to be more hands on with every engagement and not involved as much in the day to day management of each project and the customer interfacing that always needs to happen. You’re doing it right by not trying to grow too fast – that can be disastrous. But now is the time to expand and add some structure to your project delivery processes.

Go Project Manager or Business Analyst?

So, do you add one or more Project Managers right now or do you look at adding a couple of experienced Business Analysts instead? It’s a tough decision because you know what you’re real need is, but you want to and need to grow slowly. The hope is that you can afford both. As a Project Manager, I believe you need both. I like to get my hands dirty on technical projects, but I certainly think that on technical, complex projects beside every great Project Manager is an equally great Business Analyst. The Business Analyst makes the Project Manager better at their job, helps the project to go more smoothly, certainly helps ensure that technical requirements are well documented, and helps ensure that smooth transition and translation of requirements to the technical development resources. Basically, the Business Analyst is the Project Manager’s and the tech lead’s new best friend and often the glue that holds the administrative side and the technical side of the projects together.

So where do I stand on Project Manager versus Business Analyst when you can only have just one? First, let’s determine that you can have only one.

Let’s review the scenario again. You’re a relatively early startup and going through some growing pains. You are taking on more projects and taking on projects that are likely increasingly challenging and complex in nature as your capabilities grow and your staff expertise grows. Now you’re faced with a decision. Up to now you’ve been having technical resources lead your projects, but you’re on the verge of landing (or have just signed up) some bigger clients and you are actually faced with the need to add structure to your project processes, and you need to do that fast. Which direction do you go? Do you grab two or three good Business Analysts and ask them to take on the PM and BA roles for now or do you acquire two or three experienced Project Managers and possibly another one or two senior technical leads and go from there?

Let’s face it, you’re growing well and acquiring clients so eventually you are going to need everything. If you have enough now to staff Project Managers OR Business Analysts, what do you go with first? My suggestion would be to write a cross-over job description, post it and see what interest you get. You could even post it as “Project Manager or Business Analyst.” Or post it twice – once under each title but with basically the same job description and experience requirements and make sure they cover some key aspects of both roles. The available and interested applicant pool may actually make the decision for you, but not likely. You’ll get Project Managers, Business Analysts, and independent consultants – many of which have plenty of experience in both types of roles. In fact, you may just – for now – create a hybrid role that is more of a “Project Analyst” role that may even include some additional technical hands-on work depending on who applies for the role.

My Ultimate “Right Now” Choice – Go Business Analyst

Eventually, if you’re showing the ongoing forward progress and success that this article is assuming, you’re going to need to significantly expand your project management infrastructure. Organizations like this are usually best served to have a formal project management office (PMO) in place led by a PMO director. Of course, that is not where we are in the scenario – yet – with this article. But you are growing, and the big question is what is the best area to focus on and use your money wisely on? And it is my belief that the first real expansion move is to add some business analyst talent to your technical staff as that’s the likely next real need on the growth curve. I’ve been added as a PM successfully to an organization that was in exactly this situation. It was the right move for them, and I don’t think an organization could go wrong either way as long as the growth is slow and well-planned out.

Call for Input

This is definitely a good problem to have – I think just about everyone will agree with that statement. You’re growing, that’s great. You need Project Managers AND Business Analysts, and that’s great, too. And you’re trying not to augment your staff all at once with everything you need because you know full well what can happen if you expand rapidly and lose a client or two through the learning curve and ramping up process, it happens, and it’s unfortunate and it can affect your client base, your reputation with customers and your reputation as a hiring organization…as well as make your current dedicated and experienced employees uneasy – and you absolutely cannot afford to lose a single one of them at this point. Backwards progress is not on the table.

What are your thoughts? You’re the CIO or CEO making tough choices. Which way would you go and why? Project managers and senior technical additions or Business aAnalysts and senior or possibly even – for now – junior technical additions? You know you’re going to eventually need all of the above, so there’s really no wrong move. But what serves you – and your current and short-term future project customers the best? That’s the tough question. Please share your thoughts (and experiences?) and discuss.

Leadership Lessons: A 7 Phase Methodology – Phase 2 – Establish Rapport

Written by Peter de Jager on October 27, 2015. Posted in Articles.

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1 and check back every week to read the next phase.

As someone involved with ‘selling’ the change, remember the lesson from sales. People buy from people they like. Do they trust you? Change management is an exercise in diplomacy.

Don’t have all the answers.

Change ‘agents’ have a tendency to outline the entire change. They see the change as something they ‘own’ and must, therefore, dictate the exact ‘solution’. A system written with the users input will ALWAYS have a better chance of success than a solution foisted upon them by an isolated IS. The role of a ‘change agent’ is to make change possible, not to define the change to be adopted.

Support empowerment

Empowerment means giving the target audience the option to make decisions. The flip side is that you, the change agent, must give up the desire to make all the decisions. The more you leave in the hands of the target audience, the more you build their sense of ownership.

Don’t ask for ‘buy in’

When you ask for ‘buy in’ you’ve already failed. It means you’re presenting them with both a need to change and the ‘solution.’ To be more precise, you are presenting them with your solution. You’ve invalidated any empowerment you may have created.

Seek out their ‘vision’

Again, this meets their need for ownership in the change. We resist change most when it leaves us powerless when we have no control over our future.

Identify influence leaders, early adapters, and resistors

Influence leaders are those whom others look to for guidance; they are not necessarily those early adapters that take to a new change first. Your time is best spent getting influencers to change, rather than catering to the early adapters or resistors. (Of course, sometimes you’ll be in a situation where the biggest resistor is also the biggest influencer.)

Change thinking: ‘Change Agent’ vs. ‘Inflictor of Change’

The term ‘change agent’ creates an image of a person on a mission. Another phrase more in keeping with the reality that change hurts is ‘change inflictor.’ It forces you to keep in mind your primary task is to disrupt the status quo. When you think like a ‘pain inflictor’ then you have one strong objective – reduce the pain. Consider your local dentist. His single goal is to minimize the pain experienced during a specific ‘change’. By showing concern for people’s reluctance to leave their status quo behind, you also reduce their resistance to the proposed change.