The Business is our Business

When scientists study animals and plants in the laboratory, they get some understanding. It's not until they live in the environment with these that they really understand. You don't get bit by a mosquito when you're staring at a Tiger behind the glass at the zoo. I say this because we seem to spend a lot of energy claiming that the processes that we use 'involve' the business. I think that before we can be a tool for the business, we need to see the business problems from their perspective. You can't see that when you're looking in.

Too much problem solving can be bad

When you find that your day to day activities are actually doing what the busines does, you've probably stepped over the line from helping the business to doing the business. If your goal is to do the day to day business activities, then congratulations you are now in the business role. A BA should not be doing the business role, but rather helping the business communicate their needs to solution providers.

The big secret to BI success

For some reason BI seems to frequently exist in the realm of ad hoc development. Entire systems are created with hundreds of tables and billions of records, and the only test is the final product.

How do you keep these projects from failing? Requirements! I was sceptical, but a funny thing happened while I was writing detailed report requirements. The business got exactly what they wanted, and it was tested. It seems that, although most businesses want reports instantly, they'd rather have accurate reports a little later.

As BA's we've always understood that a well documented requirement, is one of the best ways to ensure an accurate design.

CBAP Certification

The next wave of CBAP certifications is coming up. If you haven't done anything but wait to see what you'll have to do, you may be in for a surprise.

Requirements Specialist

I saw a job titled "Requirements Specialist" as a job title for a business analyst. The requirements specialist should be the subject matter expert. I think that the BA is the requirements specialist, then we've missed the point entirely. We don't own the requirements or the solution. We are not the requirements specialist, but we work with those that know and understand the requirements to obtiain the correct requirements to solve the business problem.

Focus on the Business

HELPING BUSINESS CHANGE
I think it's important to remember that we are all here to help the business. Business objectives are what make a business successful. The role itself evolved because of the lack of focus on the business.

BEFORE VS. NOW
When the early IT departments were growing their automation solutions, they would approach the business with a big mainframe standing behind them. The focus in the 70-80's was, "How can I solve your problem with this big box?" Given that there were few other options available, this was considered acceptable. When other client/server options became available, the question should have changed to "What is the most effective way to solve your business problem with what we have available today?"

CHANGES IN TECHNOLOGY
Eventually some of the larger companies hired their own analysts on the business side to focus on their business needs. These analysts tended to help the business better because they were focused on the business need. They were successful if they solved the problem, regardless if they used the IT department or purchased a solution. They became more valuable to the business than systems analyst for obvious reasons. They were actually solving business problems.

EVERYONE NEEDS TO FEEL THE PULSE OF BUSINESS NEEDS
I don't think business analysts are the only ones that should be focusing on the solutions for the business, but they should be intimately familiar with how we're doing at meeting the business needs. Everyone needs to understand the business needs, and be involved with solving business problems. Although BA's are the liaison between IT and the business, they need to be in the front seat with the business. They need to feel the challenges of the business, and not only the IT team.

We all need to be the pit crew for the business. The BA should be on the headset with the driver, but everyone on the crew needs to be ready to quickly address changes needed. Any technology or methodology tools that we put together should improve our performance.

Peer Review

I've learned more from peer review than I ever learned from presenting my own requirements. Anyone else out there with thoughts on peer reviews for requirements documents?

Help the business give you great requirements

If you think about interviewing somebody to find out how their house is laid out. What rooms, carpeting, etc... Most people will get it wrong. What color is the paint on the stairway? What kind of light fixtures are in the bedrooms?

I think that when we're interviewing the business to understand some of the details that aren't as clear, we need to help the business picture that area of the business.

How do you make sure that your requriements are accurate?

Debug your Requirements

I'm an old school data flow diagrammer from the CASE methodology days, but I learned a few tricks with DFD's that make them a tool I can't be without on large projects. I use them to debug my flow of data. You can do this during any of the phases that add more information to the process. If you use bubbles (circles) to indicate a process, anything going into the process is an input and anything going out is an output. Pull on the outputs by asking yourself "Can I produce this output with the inputs that are feeding this process?" Sometimes I'll ask the business users "If I put you in a room with just __(the inputs mentioned in the process)__ would you be able to produce ___(the output)__?"

Don't discount the process of learning the process

Sometimes it's not how good the process is, but how the team gets to the solution.

When introducing new process, like tracking defects or managing resources I've found that sometimes the business and the development team need to have some room to work their way through it. For example I've Introduced Issue/Fix/Bug tracking to several clients over the years; along with managing assignments of these to resources. I know of a couple of ways that are very effective, but the client is rarely ready to just use the solution in it's entirety right away. Over time the process eventually becomes what it needs to be, but the team feels like they brought it to where it needed to be.

Data Flow Diagrams

I ran into a web site that shows a good data flow diagram that seems fairly simple to follow. I prefer using simpler flow lines (e.g., visio DFD makes this easy)

http://www.umsl.edu/~sauter/analysis/dfd/dfd.htm

It also goes into the gory detail behind the diagram.

What's the big deal about Business Analysts?

I've run into people that have done various tasks over their career that could be a bit of business analysis, and project management. They seem frustrated with the Project Managment assignments and would like to get into more BA work. What gives?

I personally think that most seasoned project managers have 80% of the skills needed for BA tasks. If they've ever completed a complex project charter, they've used most of the skills required for gathering requirements and specifications.

I know I end up doing project management on most of my assignments. Usually the Project Manager is too busy, or the project is too small to warrent a PM.

Who's the process owner?

I was talking with a business associate about a project I worked on at a startup wireless company back in 2000. I interviewed 12 different transportation companies to find out how their business process would work with wireless solutions. The kicker is that I had only 1 day to meet with the business and discover their process. In order to make it work, I HAD to meet with the right people or there was no way I'd get an accurate picture of the process.

What I found was what I call "Process Owners". A process owner is someone that either developed or has been responsible for the process for a long period of time (a couple of years or more). There are many ways to find these people. You can follow the worn carpet to their office, or just ask someone "If I were to change this process, who would be REALLY upset?" If you are changing a process, they are usually the first person to your desk to tell you why you shouldn't change the process.

To contrast Process Owners, I'll point out that there's another group of people that are process users. These are people that know quite a bit about how to use the process, but they don't really care if it changes. Many of us BA's prefer to interview these because they are much more compliant and willing to help us change the process.

Find the process owner and understand their concerns. Spend the time to sell them on the solutions, and your project will have a much higher probability of success. You'll also see why the process owners are so obstinate about their process.

Six Sigma - What's the buzz?

I've run into a few six sigma black belts in the past few years. Most of these sounded like many of the BA's that lock into a methodology and try to take over the world with it. I've heard some good and bad about Six Sigma. What's the buzz? Do you think BA's should add it to their tool kit?

Interpreting Requirements

A good overview article about why gathering, documenting, and interpreting software requirements can be a difficult task.

Interpreting Requirements in a He Said/She Said World
by Deb Jacobs , Software Engineering Services

Recommended BA Books

Real life experience is always best but what books have helped you learn the trade of being a business analyst?

Here are some of mine...

1. Mastering the Requirements Process (2nd Ed) - by Robertson and Robertson

2. Software Project Survival Guide - by Steve C McConnell

3. Use Case Modeling - by Kurt Bittner and Ian Spence

How much RUP

How much RUP experience does a mid level and senior analyst need? What areas of the RUP methodology are must knows for mid level and senior level Business Analysts?

BA Certification War

Who will win the BA Certification war? I understand this will bring unity and consensus to the role of the Business Analyst however does there really need to be only one authority? Also if we do have one authority will this stop the natural evolution of the role?

To RUP or not to RUP

Jeff asked this question, and it's a good one. When do you use RUP, and when don't you use RUP?

Iterative Process

While doing some research into Rational tools, it occurred to me that nearly every deliverable should be iterative. If I'm working on a requirements document, the document itself is the deliverable. The process of delivering that document should have the Inception, Elaboration, Construction and Transition phases within it. That means you would have some requirements for the document itself, some analysis and design of the document, testing and deployment. There is also Configuration and Change Management.

Tools of the trade

My theme as a BA for the last 20 years has been "To effectively Solve Business Problems." I enjoy helping business identify and solve business problems. What I've found is that the tools that the business understands are the most important ones to put in your toolbox. I use DFD's (Data Flow Diagrams) and Use Cases for the discovery phase, depending on the person I'm interviewing. If they're a visual learner, I use DFD's; otherwise I use Use Cases. Sometimes I'll do both. Capture the requirements with a Use Case, and then convert that Use Case into a data flow diagram. (For those in the RUP camp, I am not talking about a sequence diagram - which would be the logical next step for a Use Case)

I guess, now that I brought it up, I should explain why I use a data flow diagrams. They're a very old Case methodology tool, but I still use them because of the debugging capabilities. I can actually test the results while I'm interviewing the subject matter expert in the business to make sure that they'd work in real life.

Business Analyst vs. Systems Analyst

Here's a question that's been troubling the BA world for over a decade. We have "Business" business analysts and "Systems" business analysts. One is employed by the business to solve business problems, the other is employed by IT Systems to solve business problems using the systems in place. I consider myself a Business focused Business Analyst, with a strong knowledge of systems. What that means is that I focus on understanding the business first, and then help the business use whatever the best systems solution is available at the time.

What I've found is that solving business problems is always the best solution. If you focus on systems, you're only going to have temporary solutions, and you'll always be trying to fit the business into some new system scheme.

There are a few schools of thought on how to discover the business. My favorite is using process. I've found that most people in business understand a process that they repeat. It's especially true in manufacturing, but goes across the board into almost every aspect of business. Some of the tools for process discovery are Use Cases, Data Flow Diagrams (Context Diagrams), Document Flow Diagrams, and Sequence Diagrams. There are also many others.

Another way to discover the business is using data. Reports, forms, tables, catalogs, etc... Dissect the data and the process will follow. This is somewhat true, although I've found that BA's that focus on data assume that all of the data is part of all of the processes. The primary tool to analyze data is the Entity Relationship Diagram.

Go Live Checklists

I've been working on high profile conversions for awhile, and I've found that an accurate Go-Live checklist is a very effective way to manage the go-live. I prepared the list months before the go-live, and reviewed it with both the business and technical staff several times (usually weekly or bi-weekly with the technical staff). I'm also facilitating a simulated go-live process that gets the business involved in the go-live process. All of this seems to be bringing the right information to the table.

BA Forum

Welcome to the BA forum. This blog is created to help BA's share knowledge and information between peers. I look forward to hearing from you.