Tag: Assessment

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.

Speaker Spotlight! Business Analysts – Do We Need Them?

Written by David Barrett on October 20, 2015. Posted in Articles.

Come hear David at Project Summit BA World Boston on October 27 delivering his keynote presentation “What’s In Your Communications Engine?”

I originally wrote this post in 2010 as I sat on a flight from Sydney to Wellington, New Zealand. I was there running a Business Analyst conference in each city. Here is what I wrote at the time…

These folks, (business analysts) are really struggling: for recognition, for job security, for a well defined career path and for a recognized set of defined core competencies. Most of their organizations are just now figuring out what a BA is, and can do, but unfortunately the recognition is limited to a few departments or individuals.

Most of their peers have not got a clue as to what they do.

If you are project manager working on construction, engineering or any other large capital project – ignore this plea. You have your architects, you appreciate them and you support them. Thank you.

But all other PMs reading this – it is time you woke up and realized how valuable a BA can be to you. If you want good, solid, detailed specs for your project – find a BA. If you want to work on a project that has complete customer sign-off before you even get on the scene – find a BA. If you want to walk into an environment that has all stakeholders identified and consulted with – find a BA. If you want a ‘partner’ on your project that will help you when anything changes in mid-stream – find a BA!

Business Analysts are out there and every IT and non-IT business project needs one. Not all projects will get one – but they need one. BAs are being educated, they have conferences to go to, they have their own association (IIBA) to belong to, a body of knowledge and a professional certification programs to aspire to.

For years you have been complaining about incomplete customer specifications, weak links to the stakeholders and no blueprints whatsoever. This is why we need business analysts! They are called Business Analysts (BA), Business Systems Analysts (BSA), Requirements Managers, Systems Analysts and many, many more titles – but they all mean roughly the same thing. They will help you build the right thing the first time. And so now in 2015 I re-post… Some organizations understand this. Others hear it but have still not taken up the challenge. Others are still in the dark.

Where are you on this?

Your Backlog Might Be Broken If…Part 1

Written by Angela Wick on October 13, 2015. Posted in Articles.

How does your team build and manage their backlog? Is your current process working well or does your backlog need a reboot?

One of the most overlooked factors of team success or failure is the health the backlog. Success or failure often hinges on the amount of love and attention an organization gives to their queue of needs, features, feedback, bugs, and enhancements.

I am concerned that teams and organizations continue to focus too much on getting items developed faster vs. developing the right items—the items that add the most value to the organization. Traditional and Agile teams alike are experiencing these challenges.

Poor backlog management yields inefficient and ineffective projects/iterations/sprints/releases, and ultimately less value delivered overall. If you neglect your backlog and let it wander off, unattended, into the crowded project circus, it will dart to and fro distracted by every bright shiny object. Your team’s sense of direction will suffer, objectives will be murky, requirements will churn and value will be lost.

Successful teams give their backlog lots of TLC. They approach their backlog with strategic purpose—continuously reevaluating what’s most important and shifting it to the front of the queue. The items in the queue shift and evolve, but the overall goals and objectives are clear, the process is transparent, and teams gain efficiency.

Strong backlog management practices:

Keep teams focused
Deliver value quickly
Inspire innovation and creativity
Mitigate negative risk

It can be quite difficult for organizations to assess objectively the health of their backlog management processes and even more difficult to implement changes. These processes are often unwritten and entrenched years of evolving organizational politics, culture, and values. But admitting you have a problem is always the first step, so I’ve identified a few indicators that might shine a light on your broken backlog. Read and ponder the first two indicators this month and I’ll give you a few more to think about in Part 2 next month!

Related Article: 7 Habits of Highly Effective Business Analysts

Your backlog might be broken if…it is not prioritized.

How does your backlog get prioritized? What criteria are used? A healthy backlog delivers only the right work at the right time to the team. The most important things need to slide to the top and should be prioritized by value to the organization.

Prioritizing the backlog in traditional and Agile environments entails elicitation, analysis, and decision-making. As BAs and PMs, we may be the one facilitating this process, or as Product Owners we may own the decisions on the priorities. Either way, it’s our job to keep the development stream clean! Only items that yield true value to the organization should flow into development. We use tried and true analysis and elicitation techniques to ensure that each item is understood from an end-user and organizational perspective so it can be effectively prioritized.

If you are like many organizations your backlog may be 100s if not 1000s of items long. That seems impossible to prioritize! So, how do you deal with a backlog that is simply too long? Here are a few ideas:

Make sure the backlog is not just something the technical team is managing; it needs to be aligned with the business. The right business drivers should guide the backlog prioritization.
The top 10 (or about 10) items should be known and rank prioritized by value
When an item hits the top 10, elaborate additional details and requirements
The rest of the backlog can be grouped into like categories. Please do not categorize them by technical application, component or task, but rather by feature, process, or something of tangible business value that is understandable to the business decision makers.
Revisit the top 10 as often as needed to always have a top 10 in place.
Track the time something has been in the backlog…. seriously consider deleting/archiving the item if it remains in the backlog and not making the top 10 for six months (or whatever timeframe seems appropriate).
Make sure everyone knows the top 10 ranked priorities and get everyone focused on #1!

Warning: If your team seems to be using FIFO (first in first out) or SWGG (squeaky wheel gets the grease) processes for backlog management, the team is at high risk for not delivering value and spending the organizations resources appropriately.

Your backlog might be broken if…it is inside out.

Does your backlog focus inside out (technology and technical tasks) or outside in (user and business point of view)?

Backlog items should be written from the user or business perspective, NOT from the perspective of the team or the technology components. A piece of technology, all by itself, does not typically provide value to the user, especially in our complex integrated environments.

To prioritize the backlog we need to understand the value each item provides by writing our backlog items in ways that express the value to the organization, end customer or end user.

When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience. If your backlog items have names like “code profile page” or “write SQL for DB call” or “map data for credit card validation,” your backlog might be broken.

Backlog items should express the WHO, WHAT, and WHY, in terms that the end customer understands and can be prioritized by business leaders.

Some ideas to transition poorly written backlog items:

Item 1: Add a SAVE button at the bottom of the screen.

Rewritten: Give the customers the ability to save an order mid-stream while entering all of the order data so that they do not risk losing information already entered if they step away or get interrupted while entering.

Item 2: Upgrade the database to the new version

Rewritten: For customers to be able to enter orders after Oct 1st, 2015 we need to upgrade the database to the new version so that the version works on the operating system.

Item 3: Code the server file to add the new volume properties

Rewritten: To serve our expanding customer volumes we need to update the server file to accommodate more users at one time.

Is your backlog broken?

As you evaluate your backlog this month, ask yourself these important questions:

• How are our priorities really being determined?
• Are the items on our backlog written in a way that makes it easy to understand value and identify priorities?

Our backlog health check will continue next month when I share a few more “broken backlog” indicators in part two of this article!