Tag: Best Practices

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/

Failing for Success

Written by Bob Prentiss on May 18, 2016. Posted in Articles.

Failing never feels good because, well, it feels like failure. Nobody wants to fail. We are driven to be number 1, top dog and the big winner. Nobody has ever said, “Wow! That’s awesome! You failed!” The black and white checkered flag falls, and the winner is ordained. The fear of failure is so strong and painful that it’s amazing how far we will go to avoid it. Fleeing, running, hiding, or avoiding it all together.

We put ourselves into a make-believe world where no mistakes can be made, and we overwork ourselves to the point of exhaustion all in the name of ‘not failing.’ We keep ourselves deluded in the belief that failure isn’t an option, and we are at a loss on how to handle failure.

Being fearful of failure, we create elaborate plans to avoid it but it happens anyway. Systems, processes and people just don’t operate with 100% accuracy. If everything ran perfectly every time, we certainly wouldn’t need a helpdesk or second level support.

But failure isn’t as evil as we make it out to be. How did you learn to walk? You certainly just didn’t jump to your feet and start running a marathon. It took lots of trial and error to learn how to put one foot in front of the other to propel yourself forward. Even crawling took some trial and error! After we get on our feet, we forget that in order to get there, we fell, toppled, and wobbled our way to success. There wasn’t a surefire way to learn to walk. We had to fail in order to learn.

Experimental learning has taught us that failure is the best way to learn. Remember back to the days you first started to learn something new like riding a bike. You didn’t do it perfectly the first time and probably fell a few times. Someone was there to pick you up off the ground and put you back on the bike. You learned by failure – that leaning too far one way or another will cause you to fall off the bike.

The last thing I learned was my home thermostat. It connects to the internet and allows me to control the temperature and fan from anywhere. After successfully setting up the thermostat, I started to play around with it. I failed multiple times trying to figure out some of the features. At one point I simply wiped it clean and started over. In learning how to fix the things, I also figured out some cool new ways I could save energy and use it better. I experimented, failed, and learned.

An interesting experiment was performed by Ryan Babineaux and John Krumboltz a few years ago for the book “Fail Fast, Fail Often”. This experiment was simple. A group of students was divided into 2 groups. The first group was told, “You have 90 days to create was many clay pots as you can.” This first group or “Volume Group” was told to focus on volume and forget about quality. The other group was told, “You need to make one perfect clay pot.” The second group was the “Quality Group” and was focused entirely on quality and avoided any kind of volume. Both teams were told they were in a contest to see who could make the best looking and functional clay pot.

You would expect that the group focused entirely on the quality of clay pot would have the most well-designed pot because they were entirely focused on the design. Since the volume group was focused so heavily on just making pot after pot, odds are none of their pots would be that well designed.

At the end of the 90 days, both teams put all their pots out for judgment by a panel of clay pot artists and experts. I’m don’t know who these people are, but I will say they have one incredible niche job for judging just clay pottery. Can you even make money at that?

The surprising result was that the volume team that just made as many clay pots as they could won the competition. How is that even possible? Why did volume win out over quality?

The quality team has so focused on quality and creating the perfect design that they didn’t take any time to experiment or play with the clay. The volume team, on the other hand, interacted with the clay constantly. The first few clay pots produced by the volume team were damn ugly, but they continued to play and experiment. The volume team while trying to achieve a greater volume of clay pots actually learned more about creating clay pots and were more comfortable with the clay. So even though the volume team had a lot of failures, they succeeded and won.

Failure can make you stronger and more agile if you choose to learn from it. “That didn’t work – let’s try something different” attitude. This is the whole concept around failing fast. The faster you fail, the more you learn from that failure. Don’t fail just once, fail multiple times.

Failing safe is about creating an environment where experimentation and learning do not cause injury to yourself or your organization. Like in the experiment, an environment needs to be created in which experimentation can occur with wild abandon safely. No one was harmed in the making of clay pottery.

In the technology world, we use the term “prototyping”. Many prototyping situations in technology are severely limited. The environment is too confined or restrained for experimentation, and often very few failures occur to learn from. A better safe environment in on that this not restricted and open for experimentation.

Playing and changing everything in a production environment where your customer experiences your experiments has a tendency to make your customers unhappy. Build an environment where you can play without consequence. You may have to start over from scratch and rebuild the environment after a wild night of experimentation. Plan on creating a way to rebuild your safe environment quickly so that experimentation isn’t slowed down.

Create other safe and soft landing environments where you can bounce your ideas of others. Maybe your environment isn’t about a physical space or system but a room filled with flip charts and whiteboards.

Pulling together a group of colleagues to idea share, collaborate and innovate creates a safe environment as long as ground rules and expectations are set ahead of time. Set the expectations that experimenting and innovating is the goal. The more ideas, the better. We are not driving for perfection. It’s like a brainstorming meeting on steroids. Encourage crazy ideas and actually try it out. There are no judgments and the wildest crazy ideas are always welcomed.

Another tactic is to experiment with screen or report design by having multiple variations mocked up. The key is not just to focus on one mockup but to have many mockups. This allows the group to “riff” off each other by taking elements of different mockups and combining them together in new exciting ways.

One of my favorite tactics is user experience development and testing space. User experience folks will tell you it’s a preferred tactic to have users just play with your interface (screen or report) and watch how they use it. Gather a group and invite them to play or experiment with a design. The designers in the room are silently watching actual users interact with their design. The designers learn from watching the group play and experiment with the design. Designers then change the interface based on their observations. Rinse and repeat. One session is usually not enough. They key here is not to tell the user how to use the interface but to let them play and experiment freely in a safe environment.

A badass professional can open themselves up to new experiences so they can learn. They understand that failure can happen and work to create safe environments in which to play and experiment. Our culture needs to change the way we see failure. We must start seeing failure as an opportunity to innovate and not as something bad.

To succeed without learning is a failure. There are many instances in my life where I have executed a task perfectly the first time only to fail the second time miserably. Beginners luck can be a curse because you miss the opportunity to learn from failure. Only through failing do we truly learn.

A badass professional is reflective in their failure but not to the point of obsession. Look back and determine if there was a lesson to be learned. What went well? What didn’t go so well? What still baffles me? What if I did something different instead? Then get up off the warm fuzzy safe pillow in your safe environment and try it again. Remember you didn’t learn to walk without falling first.

Take the example of switching jobs. You prepare that killer resume and get in the door for an interview. You did your homework on the company and prepared yourself for the usual interview questions. It seems like everything went well but you didn’t get the job. Learning from failure requires being reflective or thinking about it. This shouldn’t be an all-day marathon conversation going around in your head. Jot down a few things you thought you could do better. Follow-up and get some feedback from the interviewer if you can or a colleague on interviewing better. You failed to get the job, but you succeeded in learning how to do it better next time.

Let’s build a strategy together on how to help your organization fail in a safely and fail faster so they can learn and drive innovative new solutions and approaches.

Requirements In Context Part 2: The Functional View From 10,000 Feet

Written by Dan Tasker on May 17, 2016. Posted in Articles. 1 Comment on Requirements In Context Part 2: The Functional View From 10,000 Feet

In the first installment of this series it was stated that the overall objective of these articles is to improve the quality of requirements produced by business analysts. Following the adage that “Context is Everything” it established that a number of different contexts will be explored. And in keeping with this principle it set business information systems as the context of the requirements to be addressed.

Classic Business Functions

My very first position as a business analyst 30 years ago was with a company that had just completed an enterprise-wide planning effort.⁽¹⁾ They had gone so far as to remodel one of their conference rooms for the specific purpose of displaying the results on multi-layered whiteboards. The most prominent board displayed a functional model of the business. It was said to be a view of the company from 10,000 feet up. The functions were organised into three categories: Management, Support and Line of Business.The following diagram is a slightly simplified version of that model:

In my first article I presented the classic “Swings” cartoon. It is a classic because it has remained relevant all these years. I consider the high-level functional model presented above to be a classic. It too has stood the test of time. Throughout my years as a business analyst, working in a wide variety of industry segments and government agencies in three countries, this model has proved to be both relevant and useful.

Related Article: Just Know It! Requirements in Context

Not all organisations utilise every one of the functions shown. And some organisations have multiple lines of business. For example Walt Disney – Film production would be one, theme parks another. In this style of model, each would have its own ‘Line of Business’ functions to provide contexts for dealing with very different products. Regardless of the numbers of lines of business, the Management and Support functions are applicable across the organisation.

Enterprise Resource Planning

Thirty years ago using a model like this to plan an organisation’s business information systems was leading edge. Database management systems had been around just a few years. Their use typically involved one-for-one replacement of application-specific files. A batch processing inventory management system would be upgraded to an online inventory management system supported by an inventory database. A batch processing sales management system would be upgraded to an online sales management system supported by a sales database. And on and on.

High-level functional models like this were used to demonstrate to the organization that a shared set of data could and should be used to support multiple functions across the business. The idea was to stop developing application-specific information systems and start developing an enterprise-wide one. Fast forward to today and this vision has become business as usual for many organisations. It is common today for an organisation to have a relational database that holds data utilised by multiple business functions. Some of these systems have been developed in-house. Others utilise one of the commercially available Enterprise Resource Planning (ERP) systems. Probably the original and best known of these is SAP.

The following is a list of integrated SAP modules that an organisation to pick and choose from:

Human Resource Management
Production Planning
Material Management
Financial Supply Chain Management
Sales and Distribution
Project System
Financial Accounting and Controlling
Plant Maintenance
Quality Management

Quite a striking correlation between these modules and the high-level functions from that 30-year old model.

High-level Requirements From High-level Functions?

This series of articles is about requirements in context. The Functional context is where we are starting. The functions from the 10,000-foot level are the most general functional context I can imagine. Could these be used to draft requirements? I can think of one scenario where they could – an organization interested in acquiring an ERP system. Here is an example of one such high-level requirement:

“The system shall support Accounting processes integrated between themselves and with processes of other functions.”

Each ERP function the organisation is interested in should have its own requirement naming a high-level function it wants within its integrated system. Each would be assigned its own priority. Some would likely be must haves while others might only be nice to haves. (Who am I kidding? – we all know that to business users every requirement is a ‘must have.’)

Processes within Functions

The view from 10,000 feet is an interesting functional context, but outside of acquiring an ERP system we need business functions closer to earth. Fortunately the majority of functional modelling techniques include the concept of functional decomposition. That technique used to produce the model above offered a simple three-level decomposition scheme. The things at the top level were called Functions. A level below functions were things called Processes. The third and lowest level things were called Activities.

Functions were considered to be ‘ongoing’ activities. A person working in Accounting or HR does their job year round, year in and year out. Processes in the context of this model were defined to be things that have a start and an end point. A given Function typically would decompose into 10-ish Processes. Again using SAP as an example, we see its HR module breaks down into 12 processes:

Organizational Management
Personnel Administration
Recruitment
Payroll
Travel Management
Personnel Management
Time Management
Compensation Management
Training and Event management
Wages
Personnel Development
Workforce Administration

It’s easy to envision most, if not all of the above processes having start and end points. For example, while it could be argued that Recruitment goes on continuously, in reality filling a specific position starts with some form of notification of the opening and ends ideally with a successful candidate coming on board. Here is an example of a high-level requirement utilising a Process context:

The system shall support the recruitment process including keeping records of published notifications, candidates, interviews and proof of fairness during the selection process.

Activities within Processes

The term Activity can be defined as the individual steps in a process. Visualise a workflow diagram. The boxes in the diagram that don’t themselves require further decomposition would be considered activities. The basic idea is that an Activity is that it should be simple enough that an individual is able to complete it in a single ‘sitting.’ No need to hand the work off to anyone else mid-activity or to have to wait for some other activity to complete. An example of an activity within the Recruitment process would be one called “Make Offer to Candidate.” An example of a high-level requirement ustilising an Activity as a context would be:

The system shall support keeping a record of offers made to selected candidates.

I have used a variety of functional modelling techniques from dataflow diagrams to business process modelling notation (BPMN). Regardless of the terminology used in any particular method, I have found the definitions of the three functional levels presented above to be excellent guideposts for both functional modelling and drafting requirements.

Next Time – Project Scope as a Context for High-Level Requirements

Gathering of requirements is typically managed within a project, and part of managing a project is establishing its scope. Requirements are expected to address the things within this scope. Next time we will look at scope and how high-level requirements can be derived directly from it, and actually as part of the scoping effort.

(1) The enterprise-wide planning methodology utilized by the company described was called Strategic System Planning (SSP) developed by Robert Holland.

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?

It’s All About Decision Making

Written by Kupe Kupersmith on May 3, 2016. Posted in Articles.

In August 2013 I started out on a mission to convince the world what business analysis was really about. After long conversations about decision making with my colleague Kate McGoey, who first introduced me to the concept, I wrote this blog post “Decision Making: An Underlying Competency Or What A Business Analyst Does“

It was my early take on the concept. Based on the positive reaction to the post, I knew a revolution started. Since that post, we started helping clients use this concept to improve their project outcomes. I created a 1-hour seminar to spread the message, and a workshop was formed to take a deeper dive into understanding how decisions help teams become more efficient. David Olson, a Senior BA, wrote a post on LinkedIn outlining the same message I was trying to spread. My views on decision making have expanded since this last post almost 3 years ago, so I want to share some of those thoughts here.

Related Article: 8 Steps to Making Better Decisions

Let’s look at how the IIBA defines business analysis:

“Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.”

They go on to say:

“Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders.”

For me, that definition is too abstract and maybe inaccurate. Is business analysis about defining needs and recommending solutions? I bet many of you can name many conversations where your business partners came to you saying we need to implement system “x” because we have problem “y.” I can often argue that is done without any “business analysis.” That says to me you can define needs and recommend solutions without knowing anything about business analysis or involvement from a person that practices business analysis. So what is then?

I think it is very simple. Great business analysis is all about facilitating decisions. The goal is not just to enable change; it’s about enabling the right change. The practice of business analysis is helping other make decisions so the right needs are being met. I don’t think it is a secret that if a decision is not made, nothing happens.

I am going to assume you are with me at the conceptual level. Now, I want to cover a piece of the puzzle that answers the questions of why should you care at the tactical level.

Viewing your role as a facilitator of decisions answers the question of what is just enough analysis. There is plenty of talk that good business analysts need to do just enough analysis. Analysis paralysis is not an option in today’s fast moving environment. It’s easy to say, “just do enough analysis.” But how do you do it?

The first step is realizing everything that happens on an initiative boils down to a set of decisions to be made. Someone needs to decide on what problem or opportunity we are going to go after and someone needs to decide if that problem or opportunity is worth solving/going after. Once in the details, someone has to decide the priority of the features or stories or functions. The solution team has to decide how to build the thing that will address the problem or opportunity. Are you feeling it? Who’s with me?!

So if all these decisions have to be made, business analysis is the set of activities to help the decision makers make the best decision. Good business analysis is facilitating all the necessary decisions. There are three key components that pull all of this together.

You need to define all the decisions to be made.
You need to know who the decision maker is for each decision. This may be one person; it may be many.
You need to know the criteria, or information, the decision maker(s) will use to make the decision.

Knowing the criteria each decision maker has for each decision to be made is how you determine what information you need to elicit, analyze, and communicate. Once the decision is made, stop analyzing. Once a decision could be made you have done enough analysis.

Easy, right? Not so much. There are many factors at play. For one, it is not always clear to decision makers what their criteria is for each decision. And when multiple people need to make a decision they are not always on the same page. Gaining buy-in from all decision makers takes some work.

The good thing is I’m excited to be delivering a 1-hour webinar via BA Times on this exact topic on May 17th. Please join in so I can get you to think about business analysis in a whole new light!

All the best,

Kupe