Tag: Business Analysis

Dear 007, Am I Finished?

Written by Marcos Ferrer on August 20, 2015. Posted in Articles.

Sometimes I get questions from BAs and PMs, and when I can’t answer them, I pass them on to CBAP 007. With an IIBA license to drill, no business analysis issue is too big or too small for this experienced professional. Here is one from July 2015:

Dear 007:

My project manager tells me to “finish the requirements”, but no matter what I turn in, she says it is not finished. When I ask what else she wants, she says she wants everything. When I suggest that everything costs infinity, she says I have an attitude.

She is right (about my attitude). What should I do to “finish” the requirements?

Signed,

More Finished Than She Thinks

Dear More Finished Than She Thinks:

I assume that you, like most BAs, understand that requirements are rarely “finished” in the sense of being complete to the satisfaction of every stakeholder.

The most complete requirements ever written for a cell phone did not include the contingency factors inherent in a pair of boot-cut Calvin jeans worn two sizes too small and stuffed with an understructures oversize phone chassis.

Don’t even ask about rubber gasket temperature requirements for Space Shuttle boosters – they WERE included as requirements, but ignored by project management in spite of their completeness (“But Reagan is sending a teacher into space and giving a big speech – it’s a deadline!”). Deadline, indeed, but not a requirement.

SO, I assume that the words “finished” and “everything” means something different to your PM than they do to you. Let’s try a few definitions – if one of these fits you may realize what to do.

Does finished mean? :

I (the BA) can’t tell that anything is missing
She (the PM) can’t tell that anything is missing
We (the other Business Stakeholders) can’t tell that anything is missing
They (the Implementation SMES) can’t tell that anything is missing
It (the solution as implemented) can’t tell that anything is missing (everything” works)
Notice that none of these definitions involve anyone saying “I can see that X, Y, Z are missing” which would be more helpful.

Now for a definition that helps. Completeness is best defined at a GIVEN LEVEL OF DESCRIPTION. In the BA profession, we look to BABOK for the correct categories and levels of description. In this case, requirements have the following levels of description:

Business Requirements (High-level statements of key business needs, approaches and strategically justified capabilities that must be met regardless of stakeholder wants)
Requirements[Stated] (stakeholder wants and concerns not necessarily analyzed)
Solution Requirements (functional, work to be done)
Solution Requirements (non-functional, qualities of any solution to be implemented)
Transition Requirements (temporary needs and efforts, until “full” implementation)

“Our business has a need to deliver legal documents to its customers every day on less than one hour’s notice,” might be a COMPLETE business requirement. Make sure to comb your requirements and collect all the “high-level” actual business needs (as opposed to personal preferences, see below). You will discover some “low-level” requirements that imply high-level requirements, and vice versa. Separate them (analysis) into their own groups, rewrite them to fit their level and category. THEN IT BECOMES EASIER TO SEE WHAT IS MISSING AT THE HIGH-LEVEL. This is where MOST IT project mistakes get made and is the most important to get complete.

“I want a car so I can make those deliveries for the business” is COMPLETE in the sense of being a stakeholder requirement [stated, not analyzed]. Make sure that you comb your “requirements” and collect all the “not-really requirement” statements and put them into an “elicitation” document for further analysis. The “requirements” are not finished, because they are not analyzed, but COMPLETE in the sense of being everything the stakeholders said).

“Bicycle couriers average 12 miles an hour in city deliveries, vs. 7 miles an hour for cars. Feasibility ANALYSIS suggests outsourcing delivery to couriers (or we can buy the stakeholder a bicycle instead of a car).” This might be a COMPLETE solution requirement (functional) – DELIVER LEGAL DOCUMENTS. Collect all the actual work functions implied in all your requirements, and list them in one place. It becomes easier to see what is missing (e.g., PREPARE PACKAGE WITH CORRECT DELIVERY INFO, and CONFIRM TIMELY DELIVERY WITH CUSTOMER). To be complete, list all the IMPORTANT business processes, and let the less important arise as needed (e.g., we need to ASSIGN DELIVERY TO COURIER SERVICE as a critical business function, but we can decide to implement this assignment via text message as we negotiate with the courier service. Is the requirement complete, if this “text message” spec is unresolved? Not really (see the beginning), but it is LOW risk and focus belongs on other higher level issues (e.g., how to MEASURE delivery performance objectively, once assignments are made).

“Delivery in less than on hour” was already stated as a business requirement – it is (for this simple example) the COMPLETE solution non-functional requirement – a service level guarantee. Can you think of any functional requirements that would help guarantee that service level? Put those above – group like with like.

Finally, transition requirements. Who has to be informed, trained, won over? Do we have to convert data from the secretary’s Rolodex to a label print system for the courier packages? What is the implementation plan (oh project manager mine). The project plan (think about it) is largely “transition requirements”, and should lump upon the head of your PM as much as on you.

IN short, if you use BABOK categories, you avoid level mixing, confusion, and you gain the ability to see what else belongs at that level. If you do it right, you will perceive redundancies between levels. This is normal, and shows traceability and shows that requirements are related across levels (that is why it is so easy to mix them up and get confused about how complete they are). An example of a seemingly redundant requirement was “Delivery in less than an hour”. At the business level, it is a service strategy defined by a performance level. At the non-functional level, it drives measurement, verification and other functional requirements. By putting it in both places as appropriate, COHERENCE is achieved, which helps stakeholders in perceiving completeness.

ALWAYS START BY FILLING IN THE HIGH LEVELS TO MAXIMUM COMPLETENESS. IF there is no time to “finish” a lower level, you might not even start it. Don’t spec the detail steps of MANAGE USER PRIVILEGES just because you can – stick with high value high-level critical business processes such as VERIFY TIMELY DELIVERY, and try to “complete” the success scenarios. If you have time, go for the top 3 alternate scenarios. At each step, decide how much you can accomplish and put BABOK boundaries on the work so the completeness can show.

THEN when your manager says to “finish” the screen color requirement, you know which requirement and what is missing.

Je suis finis – et vous?

Please comment below – let me know what you DIDN’t get, so I can finish it 🙂

Use This Simple Technique to Quickly Understand an Organization

Written by Clarence Worrell on August 20, 2015. Posted in Articles.

As a Business Analyst, your work is generally concerned with developing an understanding of an organization, and then communicating that understanding in ways that are efficient and actionable. Use this simple technique, outlined below, to quickly understand the aspects of an organization that are typically of interest to a BA.

MODEL OF AN ORGANIZATION

The technique assumes the following model of an organization:

The organization is engaged in a business
The organization offers products
Product development, production, sales, delivery, maintenance, etc. are accomplished through processes
Processes may include tools, techniques, and deliverables
Processes may be supported by technology

The figure below that illustrates this model:

Using the example of a city public library, let’s examine the model in more detail.

ORGANIZATION PERSPECTIVE

The model is general and applies to organizations at all levels. For example, it can apply equally to any of the following:

A city public library
A branch of the library
The library’s payroll department
The library’s IT department
The IT department’s database team

Each of these organizations is engaged in a different business. For instance:

The city public library is in the business of providing library and information services to residents of the city.
The branch library is in the business of providing a subset of these services to a community within the city.
The payroll department is in the business of issuing paycheques to library employees.
The IT department is in the business of building, operating, and maintaining technology for the library. This technology supports processes (like inventory), tools (like employee email), techniques (like Dewey Decimal System cataloging), and deliverables (like employee paycheques).
The database team is in the business of building, operating, and maintaining databases for the library. For example, it might currently be working on an upgrade to the library’s DBMS.

PRODUCT PERSPECTIVE

One organization’s product can be another organization’s process. Or tool. Or technique, deliverable, or technology.

For instance, the library might purchase new bar code scanners for its inventory management system. From the library’s perspective, the scanners are tools. But from the scanner company’s perspective, the scanners are products.

The scanner company likely has processes for development, production, sales, delivery, and maintenance of bar code devices. For instance, one of its tools might be an automated order entry system.

Let’s say that the scanner company has engaged a consultant to help improve its order entry process. From the scanner company’s perspective, the order entry process is, unsurprisingly, a process. From the consultant’s perspective, the order entry process is a product. And so on.

THE TECHNIQUE

The technique is this – Make a table using the following template, which is based on the organization model. Fill it in with information about the organization. Discover this information using whatever techniques are at your disposal (observing operations within the organization, conducting interviews with employees of the organization, studying documentation, etc.). This may or may not be easy to do, but the “doing” is the most important part; it is where you will organize and clarify your thinking about the organization. (However, the resulting artifact may itself be useful, as described later on.)

Following is a partially completed table based on the public library example:

SOME USES OF THE TABLE

Scenarios in which this technique could be useful to you, as a BA, include:

You are starting a new job, either with your current employer or with a new employer: Use this technique to assess what you need to know in your new position.
You are assigned as a consultant to a new client: Use this technique to develop a high-level summary of the client’s “as is” organization.
You have just hired on with an IT startup: Use this technique to identify what processes, tools, and technologies are currently in place, and which ones need to be defined.
You are job hunting: Use this technique to define the gap between an advertised position and your own competencies; this is a variation of assessing training needs.
You are asked to assess the training needs of your team. Use this technique to define the gap between team member competencies with respect to your team’s products, processes, tools, etc. Simply expand the table to include columns for each team member. Enter an assessment of each team member’s competencies and clearly assess where the training needs are.

An example of a training needs assessment, using our library example, could like like this:

From the training assessment table, we can surmise the following:

Arjun has the greatest training needs. It looks like he may be new to library work. It also looks like he is new to Scrum.
Anna has need of training in the Conference Room Reservation System (maybe she has previously specialized in the Inventory Management System).
All three team members are in need of training in use case modelling.

THAT’S IT!

The model and technique are pretty straightforward. I’ve found it useful in various settings but also have gotten into seemingly circular arguments about it. For example: “Why isn’t there an arrow from Technology to Products? Technology supports Products, right?”
If you find that the additional arrow helps, by all means use it. In my thinking, though, each Product is ultimately a Deliverable of some Process. Since Deliverables are supported by the Technology, no arrow is needed.

In any case, I’d like to hear your comments about (and criticisms of) the model and the technique! I hope you find it useful.

Why Does my Development Project Need a Business Analyst?

Written by Stephanie Vineyard on July 31, 2015. Posted in Articles.

The short answer: Because you want a project delivered on time, meets your specifications, and works for the end customers.

The long answer: The following project is a real example to illustrate the missing pieces and how a business analyst could have made a huge impact. Do you see similarities with a project you have?

Background

A team member (let’s call him Guy) worked with the client managing multiple Excel spreadsheets. Guy saw a pain point and realized he could do something about it. He suggested building a web application with relational databases to help the team. The client liked this idea because they realized this new tool would impact forecasting and reporting – affecting the bottom line.

Guy set to work with the client outlining the project and developing the tool. A talented project manager (Pam) joined the project. Despite Guy’s knowledge of the business process and technical skills and Pam’s attention to detail, this product was behind schedule. The end customers found that this tool relieved some pain points but didn’t address all of their needs or use cases.

What happened?

Why did a product that started out so promising end behind schedule and not fully addressing the end customers’ need?
Simply put, because there was no business analyst. Guy spent his time working with the client to understand the use cases instead of developing the tool. Pam spent the majority of her time collecting the requirements from the client. No one talked to the end customers. The only requirements provided where the “Shalls” included in the contract that did not cover the full scope of the tool. And most importantly, no one ensured Guy spent his time developing instead of gathering user stories.

What does a business analyst provide?

The most important value a business analyst provides is getting the right information to the software developer in the right manner. The business analyst works with the team to make sure the product delivered fits their needs. In this case, a business analyst allows the developer to focus on developing code.

Business analysts bring:
• An understanding of the business needs and the client needs
• A full understanding of user stories and use cases for the end customer
• Detailed requirements translating the customer needs into technical tasks
• Clear communication with the developer to create the right tool
• Detailed work with the project manager to confirm deliverables are on time and meet the contractual obligations

Wrap up

So why should I spend extra money for a business analyst? Because omitting this crucial team player will cost me in time and quality of the final product.

Do you have an example of a project that succeeded because of a business analyst’s work? Do you have a project that could have been better with the help of a business analyst?

BA or Not BA

Written by Marcos Ferrer on July 21, 2015. Posted in Articles. 1 Comment on BA or Not BA

BA	NOT BA
Traceability matrix	Slavishly make this
Functional decomposition	Dump on free thinking positions
SWOT	SWAT
Balanced scorecards	Biased scarecrows
Verify requirements	Vilify requirements
Active listening	Passively missing meeting
Clarity, completeness, coherence, concision	Confusion, carveouts, crazy, carrying on & on &…
Prioritization	Riot promulgation
Enterprise architecture	Architect renter prizes
Decision analysis	Revision paralysis
Agile methodology	Methodological fragility
Measured outcomes	Declarations of victory
Brainstorms	Stormdrains
You found the error	You didn’t find the error

Thanks for reading, and be sure to use your comments (BA) not your fists (not BA), below 🙂

How Business Analysis Benefits Your Projects

Written by Beata Green on July 13, 2015. Posted in Articles. 1 Comment on How Business Analysis Benefits Your Projects

While it may seem to many that the benefits of business analysis are obvious, the truth is that many businesses don’t completely understand how analysis can help their business. In actuality, business analysis can be the glue that holds a business together.

What do Business Analysts Do?

Business analysts help to make work easier to understand by breaking it down into smaller and more manageable pieces. Testing and developing is also made far easier by business analysts as a result. They also help to keep all projects on task by documenting their scope.

Support

Sometimes during challenging projects, project managers can become overwhelmed by reports, budgets and schedules. Business analysts can help by providing their support, both to project managers, their teams and their sponsors.

Communication

They also help to keep communication lines open by filling in any gaps when there is a breakdown. As well, any confusion as far as requirements, testing or scope can be eliminated with the explanations and assistance of a business analyst.

An Understanding of Benefit Increase

Professional business analysts understand how to increase a company’s potential benefits. Not only can they uncover new business needs, but they can ensure that the priorities of a business are focused on value.

What 2015 Holds for Business Analysts

There are many exciting predictions for 2015 as far as the role of business analyst is concerned.

They will be asked to take on several project roles, including testing and project management. Many of them will also begin to offer their services on a specialist basis, such as scoping, cost-benefit analysis and IT project requirements.

Those who already have a background in business analysis will continue their migration to more influential positions in different areas of an organization. As a result, their title may change from ‘business analyst’ to a more appropriate moniker. However, this may also cause more confusion and disagreement over their exact responsibilities and job description.

Hiring a Professional Business Analyst

Companies questioning whether or not to hire a professional business analyst or a project manager are urged to ask themselves what kinds of value each can bring to a project. In some cases, a project manager may have analyst experience. That being said, it is important to determine how well they can examine facts and other information, whether they can ask the right questions and perform thorough research. Finally, they must be able to aggregate and distill information into several charts, workflows, and other documents.

Any professional business analyst being considered for a spot on your team should have experience in the IT discipline you require. While this may seem like an obvious consideration, there can be a world of difference between one IT discipline and another.

Effective documenting, problem-solving skills, and industry knowledge are other qualities that a professional business analyst should possess. They should also have current core competencies and be motivated and self-directed.

Finally, a business analyst should have the communication and skills necessary to work as a team to solve problems.

Don’t forget to leave your comments below.