Tag: Business Analysis

The Transformational Enterprise Business Analyst

Written by Kathleen B. Hass, PMP on September 25, 2015. Posted in Articles.

Why do we keep talking about the Enterprise Business Analyst (EBA)? Because it is quickly becoming the pivotal business/technology role of the future. The EBA is a business-driven strategic partner and integrator, an enabler of organizational change, and the driver of business success. As a strategic partner, the EBA often becomes an internal consultant – a business relationship manager at the top of the food chain of the BA profession.

Operating at the enterprise, strategic level, the EBA engages in radical collaboration, as the Stanford University Design School refers to it. The EBA understands that today’s complex projects demand an unprecedented amount of teamwork and cooperation among all key business and technology roles in a critical project. Indeed, shared project leadership is replacing old project management models. Perhaps the most valuable partnership when operating at the enterprise level is the one between the project manager and the business analyst.

The BA and PM work together to ensure projects are launched to bring about innovative solutions, value to the customer, and wealth to the bottom line. All decisions are made with the customer in mind. Changes that add value are not only welcomed but sought after.

THE RISE OF THE ENTERPRISE BUSINESS ANALYST

The rise of the EBA marks a significant departure from business-as-usual business analysis. The EBA is a strategic asset to decompose strategy into valuable change initiatives. The EBA plugs the gap conducting the burden of analysis that is too often missing from business/technology project prioritization and selection.

EBAs work up front and personal, in support of an investment framework based on business value. The EBA performs the due diligence that is so often missing during project initiation. This due diligence includes competitive analysis, problem/opportunity analysis, experimentation, creative brainstorming, early complexity assessment, and captures the results in the form of a business case to propose a new change initiative.

TRANSFORMATIONAL PRACTICES

The EBA employs transformational practices to bring about value-based decision making and project management practices.

TRANSFORMATIONAL ROLES

The EBA fulfills many strategic roles, essentially putting a finger in the dike for many areas that have been woefully inadequate in organizations today, from business relationship manager to internal strategic consultant.

Business Relationship Manager and Internal Consultant

As business relationship manager, EBAs fully understand the needs of the business, from vision and strategy to execution of operations. EBAs build executive level relationships as well as relationships with lower level managers and practitioners. They decompose strategy into valuable projects and programs. They lead creativity sessions to ensure we conceive the most innovative solutions. They create business cases to propose new initiatives. They conduct competitive analysis to understand where their industry is headed. They coach project teams to ensure the teams understand the business need and the value expected from the initiative.

Strategist

The EBA often has a seat at the table with the executive management team, participating in strategy sessions, facilitating the management team through problem analysis, alternative analysis, and opportunity analysis.

Innovator, Designer, and Architect

The EBA understands that creativity is a skill that can be learned. Understanding and using design principles enable EBAs to lead sessions to design the transformation prior to examining alternative solutions. Using architectural techniques, the EBA makes the future visible through models and rich pictures.

Business/Technology Optimizer

World-class EBAs stay ahead of trends within business analysis, technology-enabled business practices, and in the industry of their choosing. However, staying up with trends is a difficult undertaking because of the amount of information that is out there; it is voluminous and can be overwhelming. The trick is to concentrate on keeping abreast of business and technology trends at a high level, and go deep in a just-in-time learning manner. That is educate yourself on areas of interest at the time when you need to apply them to your current endeavors.

The EBA thinks holistically about the business, the ecosystem surrounding the business, and about the technology supporting the business. The EBA understands where the industry is headed globally, and how that will impact their organization. In addition, effective EBAs understand the current technology infrastructure, and trends that are emerging. Some of the contemporary areas of focus include:

Collaboration and productivity
Customer & operations support
Cyber Security
Digital, wireless, and mobile spheres
Software
Open technology
Internet of things
Compute
Networks
Social media

Leader, not Manager

In performing all of these roles, the EBA becomes a value-driven strategic resource for the organization. The EBA has mature influence skills, collaborating with project managers and other key change agents. The EBA understands how to build and sustain high-performing teams. In a given week, the EBA might serve as:

Strategy and Competitive Analyst
Strategy Executor
Value/Benefits Manager
Creativity and Innovation Enabler
Transformational Designer
Cultural Change Manager
Team Leader

Lead through Connections

The world is hyper-connected. EBAs leverage the collective intelligence that resides in the untapped knowledge of their network. EBAs can embrace the dynamic tension between creative disruption and operational efficiency. EBAs cultivate organizational creativity in an age of complexity.

TRANSFORMATIONAL PROJECT SUCCESS MODEL

The traditional measures of project success have been on time, cost, and scope. Even with advances in technology and the project management and business analysis professions, superior project performance remains elusive. The CHAOS Manifesto 2013 reveals that 61% of IT-enabled business projects continue to fail to meet project cost, schedule, and scope goals.

In the 21st century we need to achieve 90% of projects on time, cost and scope through smaller, incremental development of solutions. And at the same time, our focus needs to be on innovation and value. Companies that fail to innovate will get lost in the dust of agile, fast-moving competitors. So, our new project success model needs to look something like this:

Clearly, the business analysis profession needs to step up to the plate to close the gap in project performance, and the EBA is emerging as that transformational role. EBAs are drastically changing the way we manage projects. EBAs adopt a more holistic view of change initiatives so that we:

Focus on delivery of business value and innovation vs. requirements management,
View change initiatives holistically, understanding that critical projects will likely impact the entire business ecosystem of people, process, organizations, rules, data, applications, and technology
Embrace architecture and design to help temper complexity and uncertainty, and
Strike a balance between analysis and intuition, order, and disruptive change.

Look for us at the Building Business Capability Conference in Las Vegas in November.

ⁱ Leading Through Connections, Insights from the 2012 IBM Global CEO Study (www.ibm.com/services/us/en/c-suite/ceostudy2012/‎
ⁱⁱ THE STANDISH GROUP, “CHAOS MANIFESTO: THINK BIG, ACT SMALL,” 2013. ONLINE AT versionone.com/assets/img/files/ChaosManifesto2013.pdf‎ (accessed January 2014).

Getting the Project Client to Focus on Requirements

Written by Brad Egeland on September 21, 2015. Posted in Articles. 1 Comment on Getting the Project Client to Focus on Requirements

Having trouble extracting project requirements from your customer? Does your project client think they have already handed you all of their requirements and is asking why you aren’t starting to design the solution yet? Are they worried about eating up the project budget with useless planning when you could be starting the “real” work on the project?

I know starting the real work on the project is tempting. It may even be possible – if it’s a two day or two-week project. But if your project is of any length and dollar amount to speak of, then you must – repeat MUST – have genuine project requirements. These requirements must be detailed enough to design and build a solution, and complete and complex enough for you to avoid making wrong assumptions that result in expensive and time-consuming rework later on in the engagement.

You can’t please everyone all of the time

For me, it’s about asking the right questions. For the business analyst who is likely leading much of the requirements definition effort and functional design document work, it has to be about asking the right questions as well. What the customer thinks are the requirements usually aren’t the real requirements. Often, as many have found, and the rest will soon discover, what the customer thinks is the problem is probably only a symptom of the real issue. The actual project may be a few layers down – and that’s the problem, need or issue you need to address. Otherwise, you’ll end up delivering something that doesn’t solve the end users’ real needs.

You may have followed the customer’s perceived requirements perfectly and gotten paid handsomely at the end of the engagement (and during). But 30 days later you find out that your customer is not very happy because what you delivered – while spot on with requirements – is not what they needed. And you now have a dissatisfied client and one who will likely point the finger at you while going somewhere else to get it fixed, and their overlooking you for their next project. Ouch. No, let’s get it right the first time. Here’s how you get there.

The key questions for the client

Related Article: Process Approach to Requirements Gathering

What are you current business processes as they pertain to this project?

The key here is to understand how the business operates now. It will help you understand their need or the perceived need. It will help you see the layers you may need to dig through to get to the “real” need if it isn’t the one the customer is currently presenting. It will help you see who else you may need to include in the discussion. What other key areas of the business are tied into this process? You should find that out here.

What do you want the new solution to be?

This one goes hand in hand with the question above and will give you even more insight into what the customer is thinking and if the real need is the one they have identified. Knowing the “as is” and the “to be” environment is critical to connecting the dots to get the client there. The “as is” situation tells you where they are coming from, and the “to be” will tell you a lot about what they are hoping to accomplish. It may help you better define the questioning process from this point forward.

What specific problems are your end users experiencing?

This is where you find out how tied into the process the end users are or have been up to this point. Maybe they originated the project request. Or maybe they know nothing about it. You need to know the answer to this question, and you need to draw them into the process. They are key.

Do you have specific technology needs or wants in mind?

There may be some underlying desire for a specific technology. I’ve gotten to this point a couple of times only to find out that a new technology – no real urgent need – is the only reason for the project. That’s not a bad thing – just a good thing to know up front. It may (or may not) change how you manage the project or the urgency of it. Just ask, you won’t be sorry.

Is this project supported by the executives?

Finally, make sure there is support for the project by the higher ups. It may not be appropriate to ask of an outside client. But if this is an internal project, it is definitely a question to ask. Why? Because lots of project “phishing” happens before any real funding or project approval has happened when you’re dealing with projects that are internal to your own company. They tend to skirt the formal process and may end up wasting a lot of your time and PMO time when there is no project out there. And how do you approach this on an external project? Well, carefully. But a skilled PM or BA can figure out a way to ask if the customer’s leadership is behind the effort. If you see this as a “weak” project or one that may not really be necessary, it’s a good question to ask no matter how you may go about it.

Summary

There really aren’t any magic questions that will that will draw out everything you need to know to deliver the right solution. No magic question that will make everyone happy and make all those potentially costly change orders completely unnecessary. Stuff happens, change orders happen, requirements change and sometimes they are foggy no matter how hard you try. They key is to try hard up front – put the effort into it. Good PM and good BA oversight and investigative questioning of the project client will get you 90% of the way there. The other 10% will be experience, skill, interpretation and a little luck.

How about our readers? What do you “ask” or “demand” to get you through the muck to the real customer need and true customer requirements? Please share your thoughts and expertise (and failures if you don’t mind).

Avoid These Phrases – Or Your Project Will Fail!

Written by Abbie Cockburn on September 7, 2015. Posted in Articles.

Everyone recognises the importance of good requirements writing. Good requirements must be written in such a way as to be clear and unambiguous to all readers. Explicit requirements require fewer review cycles to achieve approval.

Requirements that are vague are open to interpretation by stakeholders. It’s easy for such phrases to creep in when defining requirements but they are risky and will inevitably lead to confusion, wasted effort and rework. For Example:

“Flexible”. The business’s definition of flexible and the developer’s definition of flexible might not be compatible so be SPECIFIC about the actual variables. Requirements must say exactly what is needed by the business. Specific requirements must be clear, simple, consistent and at an appropriate level of detail.

“Some”, “Several” or “Many”. State a specific value, or provide the minimum and maximum limits, this will help to clarify exactly what you want in terms that everyone can understand. Requirements must be MEASURABLE, it must be possible once the system has been developed, to verify that the requirement has been met.

“Better”, “Faster”. In the context of your requirements, quantify how much better or faster constitutes a satisfactory improvement, this will help you ensure the requirement can be ACHIEVABLE within the constraints of the project and existing systems. If you can, sound out your requirements with a developer to ensure feasibility.

“Etc.”, “Such as” or “So on”. Be explicit about what happens next. Don’t let people guess the next steps as this could lead to various incorrect outcomes for your requirements. Requirements must always stay RELEVANT, you must be able to connect a requirement back to the overall business objective.

“Acceptable”,” Adequate”. Define the acceptance criteria, ensure that there is a statement or statements that can be used to determine a pass or fail result for each requirement. In other words it must be possible to design a TEST or come up with a means to determine if a solution has met the requirement.

Such ambiguous phrases should signal that requirements are incomplete and need further clarification with the stakeholders.

At Be Positive we use the SMART (Specific, Measurable, Achievable, Relevant and Testable) acronym to help avoid some of these troublesome phrases.

If you stick to writing SMART requirements you should find that you avoid ambiguous phrases naturally. But just to be safe, an effective check for ambiguous phrases is to consider your requirements from the perspective of a Tester. If you can’t envision a test that would determine whether or not a requirement has been met, you need to be more specific.

Ambiguous phrases must be corrected at the earliest point in the solution delivery lifecycle (defect avoidance costs much less to resolve than defects identified in subsequent phases of the solution delivery lifecycle).

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.