Tag: Business Analysis

5 Challenges for the Business Analyst on a Hybrid Project

Written by Lavinia Mihaela Dinca on May 19, 2016. Posted in Articles.

Agile has become a common methodology used in many projects, and it’s being used more often. Experts agree that the future is not agile or another methodology, waterfall, but a hybrid of the two.¹

Hybrid projects combine methodologies in an effort to use the strengths of both and minimize each of their shortcomings. Implementing a successful hybrid project means needing to have experience with both.

I will give two examples where a hybrid approach will work.

A large project with both hardware and software components can use a hybrid methodology: waterfall for the hardware component and agile for the software component.

Related Article: 5 Lessons From Working With Agile & Waterfall

A second example is a more challenging one: a complex software project where the GUI is created using agile and waterfall is used for feature development.

Hybrid projects strain most of the team members, but it affects the business analysis team more because they have to keep track of everything being developed.

The hybrid project examples from above may be regarded as the separation of church and state. Using waterfall on a hardware part and agile on software part is not difficult, and most likely the BA teams will be separate anyway. “True” hybrid projects are rare, but they will apparently become a reality. By “true” hybrid project I mean a software project where different features are developed using both methodologies at the same time.

In my opinion, there are 5 main challenges a business analyst faces working on a “true” hybrid project:

1. What goes where

Knowing which part of the project will be done using waterfall and which using agile can be complicated. Waterfall tasks can be hardware implementation, application security features, enterprise business architecture, and critical core features. The agile tasks might be GUI design or business features which can change.

Determining what goes where should be set from the beginning of the project. Problems may arise later on if this isn’t done. When issues appear during the project, they should be discussed with the project manager and any other senior members of the team and an informed decision made about which feature goes where. It shouldn’t only be up to the business analyst to decide.

2. Requirements prioritization and integration

In a hybrid project, feature prioritization may be extremely difficult. The business analyst has to take into account which features will be developed using waterfall, meaning they will be delivered towards the end of the project.
Some features developed with agile might be dependent on the previous ones, and they should be rescheduled toward the end of the project if the prior deliverable is developed in waterfall.

Requirements integration is also challenging because of the same issue: some features will be delivered at the end, others before.

3. Requirements description and documentation

Requirements description is different in level of detail in both methodologies. On a hybrid project, the business analyst must be prepared to do both: requirements for the waterfall part and requirements for the agile one. The problem that might arise is the gap in documentation. Some features will be more detailed (the waterfall ones) and some more high-level (the agile ones).

I think that the most discrepancy will be in the testing documentation because in waterfall the test cases are developed in the analysis phase for all the features. In agile, the test cases are developed for every use case, in every iteration. This means that the application testing will be very difficult overall.

4. Trace / Identify missing requirements

Tracing requirements and, most importantly, identifying missing ones will be challenging. A common mistake is assuming that a certain feature will be developed in waterfall, meaning later on in the project, and business analysts might move on with other tasks.

Another problem is identifying missing features due to fragmented analysis. Some requirements were taken in the waterfall phase and others during agile sprints. Naturally some requirements might be overlooked and never developed. A common requirements matrix must be maintained regardless of the methodology used to develop the feature and business analysts must be involved in both stages of the project – and not have business analysts for agile and business analysts for waterfall.

5. Communication and collaboration

In any project, communication is very important, but in a hybrid one, it’s the difference between failure or success. The BA’s role must be regarded more as a facilitator for the team. The BAs will have an understanding of all the features being developed project-wide, regardless of the methodology, and they will be in a unique position to mediate misunderstandings, provide clarifications, and even help the team understand why a certain feature should be developed using certain methodology.
Personally, I think that “true” hybrid projects are still a long way to go and that most of the hybrid projects will isolate the agile and waterfall methodologies. I think this situation will last for a few years because there are still companies struggling with agile. Companies implementing agile projects still struggle to understand that a business analyst has an important role to play in an agile project and that this role is not obsolete.

Do you think it is feasible to do software development using both methodologies at the same time?

Do you agree the future will be hybrid? What items would you add or remove from the list?

¹ http://www.bridging-the-gap.com/traditional-vs-agile-the-future-is-hybrid/

5 Reasons Why You Need a Business Analyst Before Project Kickoff

Written by Brad Egeland on May 11, 2016. Posted in Articles. 1 Comment on 5 Reasons Why You Need a Business Analyst Before Project Kickoff

In a perfect project world, the cost of the project and the resources you use on it wouldn’t be an issue and the best resources could be available to the project 24/7 from the beginning. Oh, and they wouldn’t need sleep, and they would never get tired. In a perfect world – or at least some alternate universe.

But we don’t live in a perfect world and project resources do cost money – a lot of money. And, unfortunately, they actually do need sleep.

So in this imperfect world, we really don’t want the entire project team on board at kickoff time because there isn’t anything for all of them to do yet. They would likely end up charging time to the project budget that we don’t need. While we usually can’t get – or even want – the entire team assigned at kickoff, it can be extremely beneficial to have the business analyst assigned by that point. Why?

Here are my 5 reasons why assigning a business analyst at kickoff will help the project, the project customer, and the project manager.

1. Technical questions DO come up in the kickoff session.

Some technical questions need to go back to the project team AFTER kickoff and then handled via other communication with the project customer and his end users or subject matter experts (SMEs). And those I will cover later in this article. But some nearly always come up during the kickoff session that can be handled – and should be handled for the sake of forward progress – during this critical meeting. The project manager may be able to handle those, but the business analyst should be able to handle those and between the two some key decisions can be made – with the project customer and any SMEs present that will keep the discussion flowing rather than halt progress and create yet another issue “to be handled later.”

2. Next steps involve requirements, and the business analyst will play an integral role in the definition and documentation of requirements.

Usually, the next steps after the project kickoff session involve some discovery, some business process review, some AS-IS and TO-BE planning, and definitely the detailed project requirements definition and documentation. A business analyst who has been present in the statement of work (SOW) review, the draft project schedule preparation, and the discussions that happen at the project kickoff session will be that much farther ahead when both sides sit down to document real, complex, detailed requirements that the tech team will build technical design documents from and develop the solution from.

3. Prep includes the project schedule, and the business analyst can definitely add much value to the drafting of the initial schedule.

As I’ve stated, the drafting of the project schedule will happen prior to the project kickoff session. This project schedule likely won’t be reviewed in detail during the kickoff session, but it will be in the customer’s hands during that session and the more detail that goes into the schedule and the more that it makes sense, the more confident the project customer will be in the delivery team’s ability to roll out a quality end solution. And that first impression is always big. While I am always in favor of having a project manager who can fight his way out of a technical paper bag on his own, the business analyst is usually his superior technically, so his input to the draft project schedule that goes to the customer and helps drive the kickoff session discussions can be extremely beneficial.

4. There will be take away questions – having the business analyst present negates the potential for misinterpretation and miscommunication as those questions go to the tech members of the project team.

I’m not saying the project manager can’t handle this. I’ve handled this many times. But I’ve also led enough technical projects to know that if I have a business analyst sitting beside me, they are also representing the tech team that hasn’t been assigned yet, and their brain is already thinking that way while I’m still focusing on organization and next steps. Having the business analyst present during kickoff lessens the possibility of any misinterpretation or miscommunication of those questions that need to be taken to the tech project team.

5. The business analyst can add more precision to the estimates that go into the draft project schedule.

The draft project schedule that is taken to the project kickoff session is really more than a draft schedule. It is the active, living, breathing schedule at that point and should only need some minor tweaking as the kickoff session comes to a close. That being the case, having the business analyst assigned and putting that together with the project manager means that effort estimates that go into that schedule will be that much more accurate. As a project manager, consultant, and former developer, I consider myself a very good estimator of project task effort – yes, even all the complex development tasks on technical projects. But the business analyst usually – at least on my projects – has served to be the liaison between the project manager and tech team and they are usually even just a bit better at providing detailed, fairly accurate estimates than I can. And more accuracy and realism is always good as you head into the kickoff session and beyond.

Summary / call for input

The bottom line is this. In my opinion kickoff sessions and the project, in general, just go better if the business analyst is assigned as quickly as possible. Unlike the tech team members who really can’t do much until design starts, the business analyst can prove to be an invaluable resource from Day One as the project manager goes through the administrative work and planning to get the project kickoff session in place and the project schedule assembled.

What about our readers? What are your thoughts on the business analysts assignment to the project team and the timing of that assignment? What is your organization’s policy or does it depend on the project? What is your preference?

Strategy Spotlight: 8 Tools & Techniques to Apply to Strategic Analysis & Planning

Written by Richard Lannon on May 10, 2016. Posted in Articles.

There are many definitions, tools, and techniques that can be applied to strategy analysis. If you do an internet search you will find all sorts of options available. The challenge is selecting the best approach, tools, and techniques to use given the business problem or opportunity.

Another part of the challenge is understanding what strategy analysis means since there can be many definitions. This can make it confusing. It is best to simply say that strategy analysis is an approach to facilitating, researching, analyzing, and mapping an organization’s abilities to achieve a future envisioned state based on present reality and often with consideration of the organization’s processes, technologies, business development and people capabilities. Part of that whole process is the ability to bridge gaps that exist between the strategic, tactical, and operational aspects of the organization. This requires a look at the present state, the future state, risk and financials and the creation of change requirements to achieve the desired outcomes.

Related Article: Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

Even though the definition of strategy analysis varies, there is common thinking on the key planning requirements.

Preparation for planning through the identification and review of information relevant for strategy analysis
Performing high-level environmental scan looking at the internal and external business environment with consideration for mission, vision, stakeholders, structure, existing plans, people profiles, and question responses.
Applying a choice of different tools and techniques to analyze the present state of a business environment and mapping out its future.

Some of the more common analysis tools and techniques include:

VMOST: This stands for Vision, Mission, Objectives, Strategy, and Tactical.

Success in an organization happens with top-down or bottom-up alignment. I was recently reminded of is when working with a client who stated that their tactical is not connected to the strategy. VMOST analysis is meant to help make that connection.

SWOT: The standard analysis tool, defined as Strengths, Weaknesses, Opportunities, and Threats.

Strengths and weaknesses are internal to the organization, opportunities and threats are external. SWOT requires you to be candid and provide an honest assessment of the state of things. It forces you to create a dialogue with stakeholders to get different viewpoints. Eventually, you focus in on the key issues.

PEST: This is a great tool to use in tandem with SWOT. The acronym stands for Political, Economic, Social and Technology.

PEST reveals opportunities and threats better than SWOT, the direction of business change, projects that will fail beyond your control, and country, region and market issues through helping you create an objective view.

SOAR: This stands for Strengths, Opportunities, Aspirations, and Results. This is a great tool if you have a strategic plan completed, and you need to focus on a specific impact zone.

I used SOAR to help a business that needed to focus on their business development requirements due to an external market change. The organization needed to discuss how they would recapture lost sales by $1 million per month to ensure they maintained their profitably. Given that they had already done everything they could to cut costs and operate a lean business, the SOAR was critical in helping define the focus for the next 12 to 24 months.

Boston Matrix (product and service portfolio): This tool requires you to analyze your business product or service and determine if it is a cash cow, sick dog, questionable, or a flying star.

I have applied this tool to product and service reviews with to help make product decisions with consideration for market share and market growth. But it has no predictive value, does not consider the environment, and you need to be careful with your assumptions. It does force discussions on your present offering and whether it makes sense to maintain or enhance those offerings. For example, maybe you are holding onto a business product that you love but is really a sick dog and maybe there is a cash cow in your business that you are not optimizing. A decision has to be made.

Porter’s Five Forces: This tool helps you understand where your business power lies in terms of present competitiveness and future positioning strength. It forces you to analyze the bargaining power of suppliers and customers, the threats to new entrants and substitutes, and competitive rivalry in your marketplace. Using this tool helps you understand the balance of power and to identify areas of potential profitability. According to Porter, this model should be used at the line of business level.

Maturity Models: There are many maturity models that can be applied to a business. From the evolution model, the technology model, to the team model. The idea is that every business or department goes through a maturity cycle. The standard cycle is chaotic, reactive, proactive, service, and value. If you were looking at processes in a department, you would look to see where that process is on the continuum. Then you would determine where you need to be and what it would take to get to that point of maturity. This is a simple explanation. When using a maturity model, it is important that you have a clear problem definition and solution context.

Root Cause Analysis: This is important, as there are times in the strategy analysis process you need to dig deeper into a problem. This is where RCA is used. The key is that you need to identify and specify the problem correctly, analyze the root cause using a systematic approach, verify the causes, and determine the corrective actions. Implementation of the corrective action is extremely important.

There are many definitions, tools, and techniques that could be addressed. The ones mentioned here are only the tip of the iceberg for strategy analysis and become a foundational part of the strategy analysis toolkit. In a short blog, there is no way to mention them all. But you could create a tool checklist that you could use in your next planning and analysis engagement to help you and your team define the present, future, risk and change state that you need to succeed.

Until next time, be your best, invest in the success of others and make your journey count.

Richard

Check out Richard’s workshop at Project World * Business Analyst World Toronto on Thursday, May 12 – “Strategic Business Analysis – Techniques to Uncover and Define Business Need“

Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

Written by Richard Lannon on April 26, 2016. Posted in Articles. 1 Comment on Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

While waiting at a gate for the next available airplane at an airport, I met a fellow business traveler. We started talking about business and what we did for a living. He was a COO (Chief Operations Officer). So I asked about their planning process, what it means to be strategic and the common challenges he had witnessed. He opened up like a child that couldn’t wait to be heard. The conversation lead to eight common mistakes made in strategic planning.

1. Not knowing what it means to be strategic

Not everyone knows what it means to be strategic. To be strategic means you have to get clear on the future you want (future state), where you are at today (present state) and where you came from (past state). With that in mind, strategic planning looks to the future state and works its way backward to the present state.

2. Inappropriate use of the word strategic

Knowing the difference between a strategic and tactical discussion. Confusing things like marketing, people approaches, or technology with strategy. A value proposition, improved human resources, or technology integration is not strategy. These items are usually elements of a larger plan often requiring analysis and decisions by company representatives to determine solution options and to achieve the strategic results required.

3. Poor upfront preparation

We both agreed we see this one all the time. Someone says let’s do some strategic planning. They get a group of people together, go into a room, and use their preferred approach and develop a shopping list of tactical items that go nowhere. A poorly planned or guided planning (requirements) workshop was executed. Don’t make this mistake.

Strategic planning means you need a planned approach that is appropriate for your department or company. It is not one size fits all. I have a standard engagement approach, but it is adaptable relative to the client needs. Sometimes preparation could take up to 3 times the actual session time. This is especially the case in complex situations requiring a lot of preparation and communications.

4. Let’s look at last year’s plan

Looking at previous years’ plans at the wrong time can bring you down a rabbit hole where dialogue leads to nowhere. Mostly you end up re-hashing old items. There is an appropriate time to review previous year plans, but generally, it is not when you are embarking on future think.

Consider using the old plan as a historical document and a business artifact. Scrap what you did before and start again to discuss the future and then later bring in the now and old plans.

5. Not asking the right questions

Lots of people are not comfortable with asking questions, especially the right questions. Often the questions you ask are specific to the tool or technique you choose to use in your strategic planning process. There are natural questions that come out of a SWOT, PEST, SOAR, APAE, or from TTY (tomorrow, today, yesterday). The key is to focus your efforts on a specific area, use the best tool to address your concerns and develop a set of questions around that focus area.

6. Playing with your belly button

This is also known as navel-gazing. The mistake most often made is putting your attention on you. Dialogue needs to be focused away from the self-indulgent or excessive contemplation of oneself or a single issue, at the expense of a wider view. Things that are strategic can’t be mixed with tactical items. Items need to be categorized as strategic, tactical or operational.

7. Missing external world issues

By spending too much time on internal issues, you will miss the outside world impacts and opportunities.

Strategy means that your need to find ways to improve and move ahead no matter what is happening in the external business environment. We have all experienced good times and bad times. That is the natural course of the economy. You may have to change your business, try new things or potentially alter your business model entirely to achieve your strategic vision. This will come from having an outside-in view of your business.

8. Losing your imagination

This is the thinking by people that their product won’t change much because it is a bunch of plastic and metal. Therefore, there is not much they can do. If you hear this statement, you need to make some adjustments quick.

An option is to establish creative teams and have them answer the question, how could the whole market be served better in the future. Creative teams’ imagination generates scenarios and solutions for an organization whom product and thinking has matured. Strategic leaders leverage the creative minds and the imaginations of others to create options for tomorrow.

This was a great conversation to have. It was nice to get someone else’s perspective on the challenges in strategic planning. You just never know what you will discuss with a stranger at an airport. We both agreed that strategy is a long game – that it required overcoming some common mistakes.

Almost all business leaders tell me that their greatest asset is their people. If that is the case, with a little upfront work and guidance people can move their thinking from tactical to strategic and beyond the present state.
Invest in the success of others and make your journey count.

Richard

An IT BA on a Cross-Functional Technology Team

Written by Janet Walker on March 8, 2016. Posted in Articles. 1 Comment on An IT BA on a Cross-Functional Technology Team

If you, like me, have spent most of your BA life sitting amongst other BAs or inside a cluster of business partners, you can appreciate the “shock and awe” I experienced moving into a workspace filled with engineers and QAs.

Half of our IT team re-orged into system-specific cross-functional teams. The business analysts combined with the QAs, system engineers and even a database engineer (DBE) or two to form a cohesive group of support, brainstorming and execution. I went through this transformation last year and can say the experience has been nothing less than eye-opening.
Keeping the engineering side of your business in focus is important for any BA, but when our business wants to turn left and our engineers – developer, programmers, DBEs, etc. – are diligently working on how to use the latest technology to turn right, we find out how painful it can be!

The engineers (I lovingly refer to them as my Geeks) are as committed to driving our business as I am and are always looking for the inches of improvement around us. Suddenly, the total commitment to our business partners involves some tough choices for me, the BA.

One day I’m in a devoted business partnership, the next day I’m in a devoted partnership of driving the business during system upgrades and failovers!

The first thing that shocked me on the Geek-filled team was finding out I was actually skating on thin ice all those years as I was driving our business forward on top of new technology. Yes, I understood how the system worked and what some of the possibilities were, but all that time the engineers were looking for better ways and innovating like crazy. Suddenly, I understand why the engineering response to my change requests was often “WHAT?”, “WHEN?”, “WHY?” and sometimes “Wait!” I was driving the business on top of a system or systems the Geeks were constantly improving. Understand, our company culture is deeply ingrained in all team members, but sometimes during those days as a business BA I wondered if the Geeks and I worked at the same place. Getting on the same page, or not colliding on the same page, was the source for a LOT of discussions, but, the real challenge had been making the business better on top of the ice and how to make the system better below.

{module ad 300×100 Large mobile}

The second “wake up” moment was when I spent the first month with my Geek team and realized we had been meeting and making decisions over the years while saying the same words and meaning completely different things. For example, I have used the term Doc Type for about 14 years and never knew the engineers supporting my system have been mentally translating it to Doc Type Number. Only when I physically joined their world did I hear the comment from one to another “She means the number.” A simple difference, but really got me thinking. Geeks talk differently. In my part of the world, they speak English, but a different kind of English. There I was, thinking I was an expert at translating technical changes into business-speak, and I found myself needing to come up to speed on translating geek-speak to technical changes to business-speak.

Thankfully, I landed on a team with patient engineers and QAs. I think this patient Geek may be few and far between, but if you find one – listen and learn! My experience with Geeks is that they run fast and when they get an idea – watch out! A discussion can go from clear and orderly to “Wait, what if we do ….” and “No, I heard about something that ….” REAL fast. Your BA skills are needed like no time before. Remember how you led that meeting with business big shots and their conflicting agendas? Child’s play. Now you need your special skills, as I like to say, to herd cats. You are dealing with super-smart, ready-to-execute, get-it-done individuals and what we don’t EVER want to do is stop that innovation and passion for execution.

You just want to figure out how to do what our business needs us to do and make it to your next meeting (or lunch) on time. Remember how I mentioned I work with patient engineers? Well, even their patience is limited when it comes to asking them to remind me (again) what a thread is. You will want to decide what questions you need to ask during a meeting like this and what questions can wait.

My suggestions, if you find yourself gifted with an opportunity to work on a cross-functional technology team:

Concentrate on just listening during your first few team meetings. Ask an engineer or QA afterwards to translate what you didn’t quite “get”.
Slowly start asking questions to find out if anything on the agenda will affect your business partners. This is a way to bring the business closer to your engineers, QAs and DBEs.
Add something to the agenda that is pure BA, pure business. Get ready for odd looks, questions and maybe even some chuckles. This is where you find out how wide the chasm is between what your Geeks think the company does, and what you know it does.
Make an effort to educate your team members as you get educated yourself. Share your current business meeting challenge, your thoughts on acceptance criteria for a task or other things in your typical BA day. Pretty soon you find the discussions become mutually informative, and the action items have you all on the same page.
“BA” for your engineers! Give them the support and input they probably didn’t know they could ask for. Do the analysis, contact the subject matter experts for any clarifications, and learn to test something from the very bowels of the code. Show your cross-functional team what they have been missing all this time and why they need you in their lives!
Lastly, enjoy the most exciting team experience you have ever experienced. Dive deep, sweat a little and celebrate the big wins as a cross-functional team.