Google



1










What Is Business Analysis? to Business Analysts

What is Business Analysis?

What is business analysis?

In very basic terms, business analysis could be said to be the application of a range of disciplines, to determine business needs and develop solutions to business problems. Of course, in practice this short description becomes entirely inadequate, a far more exhaustive explanation is required to explain exactly what business analysis actually is.


Business Analysis Basics


Business Analysis is a term which refers to the process of firstly identifying the needs of the business and then developing and implementing the solutions to meet them. Business analysis techniques are applied to develop an appropriate plan and then put it in to action. Business Analysts are an important asset to every business, they apply their skills to take the big picture and break it into smaller parts, making it easier to ensure that company resources are being utilized in the most efficient manner.



Business Analysis is Goal Orientated


Business analysis always focuses upon goals, but in a bi-directional fashion. Business analysis can be implemented to both set goals, and to achieve them. These goals will cover strategic business practices encompassing IT, business processes, corporate policies, structure and trading strategies across the entire enterprise.





Business Analysis Is Comprised of
Three Core Elements


The term business analysis is a broad term given to the process of analyzing and influencing three distinctly different aspects of the business, which combined, effect the enterprise at every level, these are:


Business Analysis Techniques


Depending upon the market sector the enterprise sits within, different business analysis techniques will be applied. Different techniques may also be applied at project level. Some of the most common of these techniques are:


These are just a handful of the mainstream techniques which make up the toolset of the modern business analyst. These are very succinct descriptions, each of these techniques is worthy of several pages of description in their own right.


The Three Phases of Business Analysis


Every time that business analysis techniques are applied, there is a natural three phase progression, which can be explained thus:



Why is Business Analysis Important?


Business analysis is important for many reasons, although the main one should be quite apparent; business analysis allows a company to take carefully iterated steps towards achieving greater profitability by working


Every enterprise is the sum of its stock value, working capital, tangible assets, customers, staff and goodwill. By employing modern business analysis techniques, the value of each of these core aspects. Hopefully this has answered the question of what is business analysis.




© 2015 Stellar Force

Business Analyst Community & Resources | Modern Analyst
RSS feeds for Business Analyst Community & Resources | Modern Analyst

5 Business Problems You Can Solve Using SQL Temporal Tables
by Bert Wagner
11 Jul 2017 at 6:08am

It’s 4:30 pm on Friday and Mr. Manager comes along to tell you that he needs you to run some important ad-hoc analysis for him.

Previously this meant having to stay late at the office, writing cumbersome queries to extract business information from transactional data.

Lucky for you, you’ve recently started using Temporal Tables in SQL Server ensuring that you’ll be able to answer your boss’s questions and still make it to happy hour for $3 margaritas.

Sound like a plan? Keep reading below!

The Data

For these demos, we’ll be using my imaginary car rental business data. It consists of our temporal table dbo.CarInventory and our history table dbo.CarInventoryHistory:

I’ve upgraded my business — we now have FOUR Chevy Malibus available for you to rent Business Problem #1 — “Get me current inventory!”

To get our current inventory of rental cars, all we have to do is query the temporal table:

SELECT * FROM dbo.CarInventory

That’s it.

I know this query seems lame — it’s just a SELECT FROM statement. There are no FOR SYSTEM TIME clauses, WHERE statements, and no other interesting T-SQL features.

But that’s the point! Have you ever had to get the “current” rows out of a table that is keeping track of all transactions? I’m sure it involved some GROUP BY statements, some window functions, and more than a few cups of coffee.

Temporal tables automatically manage your transaction history, providing the most current records in one table (dbo.CarInventory) and all of the historical transactions in another (dbo.CarInventoryHistory). No need for complicated queries.

Business Problem #2 — “How many miles on average do our customers drive each of our cars?”

In this example, we use FOR SYSTEM_TIME ALL and a plain old GROUP BY to get the data we need:

SELECT
CarId, AVG(Mileage) AS AverageMileage
FROM
dbo.CarInventory FOR SYSTEM_TIME ALL
WHERE
InLot = 1 -- The car has been successfully returned to our lot
AND SysStartTime > '2017-05-13 08:00:00.0000000' -- Ignore our initial car purchase
GROUP BY
CarId Some cars get driven a lot more. Causation or correlation?

FOR SYSTEM_TIME ALL returns all rows from both the temporal and history table. It’s equivalent to:

SELECT * FROM dbo.CarInventory
UNION ALL
SELECT * FROM dbo.CarInventoryHistory

Once again, there isn’t anything too fancy going on here — but that’s the point. With temporal tables, your data is organized to make analysis easier.

Business Problem #3 — “How many cars do we rent out week over week?”

Here at Wagner Car Rentals we want to figure out how often our cars are being rented and see how those numbers change from week to week.

SELECT
CurrentWeek.CarId,
CurrentWeek.RentalCount AS CurrentRentalCount,
PreviousWeek.RentalCount AS PreviousRentalCount
FROM
(
SELECT
CarId,
COUNT(*) AS RentalCount
FROM
dbo.CarInventory FOR SYSTEM_TIME FROM '2017-06-05' TO '2017-06-12'
WHERE
InLot = 0 -- Car is out with the customer
GROUP BY
CarId
) CurrentWeek
FULL JOIN
(
SELECT
CarId,
COUNT(*) AS RentalCount
FROM
dbo.CarInventory FOR SYSTEM_TIME FROM '2017-05-29' TO '2017-06-05'
WHERE
InLot = 0 -- Car is out with the customer
GROUP BY
CarId
) PreviousWeek
ON CurrentWeek.CarId = PreviousWeek.CarId

In this query, we are using FOR SYSTEM_TIME FOR/TO on our temporal table to specify what data we want in our “CurrentWeek” and “PreviousWeek” subqueries.

FOR/TO returns any records that were active during the specified range(BETWEEN/AND does the same thing, but its upper bound datetime2 value is inclusive instead of exclusive).

Business Problem #4 — “What color cars are rented most often?”

We’re thinking of expanding our fleet of rental vehicles and want to purchase cars in the most popular colors so we can keep customers happy (and get more of their business!). How can we tell which color cars get rented most often?

SELECT
CarId,
Color,
COUNT(*)/2 AS RentalCount -- Divide by 2 because transactions are double counted (rental and return dates)
FROM
dbo.CarInventory FOR SYSTEM_TIME CONTAINED IN ('2017-05-15','2017-06-15')
GROUP BY
CarId,
Color

Here we use CONTAINED IN because we want to get precise counts of how many cars were rented and returned in a specific date range (if a car wasn’t returned — stolen, wrecked and totaled, etc… — we don’t want to purchase more of those colors in the future).

Business Problem #5 — “Jerry broke it. FIX IT!”

The computer systems that we use at Wagner Car Rentals are a little…dated.

Instead of scanning a bar code to return a car back into our system, our employees need to manually type in the car details. The problem here is that some employees (like Jerry) can’t type, and often makes typos:

SELECT * FROM dbo.CarInventory FOR SYSTEM_TIME ALL WHERE CarId = 4

Having inconsistent data makes our reporting much more difficult, but fortunately since we have our temporal table tracking row-level history, we can easily correct Jerry’s typos by pulling the correct values from a previous record:

;WITH InventoryHistory
AS
(
SELECT ROW_NUMBER () OVER (PARTITION BY CarId ORDER BY SysStartTime DESC) AS RN, *
FROM dbo.CarInventory FOR SYSTEM_TIME ALL WHERE CarId = 4
)
--SELECT * FROM InventoryHistory
/*Update current row by using N-th row version from history (default is 1 - i.e. last version)*/
UPDATE dbo.CarInventory
SET Color = h.Color
FROM
dbo.CarInventory i
INNER JOIN InventoryHistory h
ON i.CarId = h.CarId
AND RN = 2 Typos fixed!

Although we could have fixed this issue without using a temporal table, it shows how having all of the row-level transaction history makes it possible to repair incorrect data in more difficult scenarios. For even hairier situations, you can even roll-back your temporal table data.

Conclusion

Temporal tables are easy to setup and make writing analytical queries a cinch.

Hopefully writing queries against temporal tables will prevent you from having to stay late in the office the next time your manager asks you to run some ad-hoc analysis.

-----

Bert Wagner

https://blog.bertwagner.com


A New Metaphor for Business Analysis
by Ronak Sanghavi
25 Jun 2017 at 12:29pm
Current State

For many years now, the most commonly used metaphor on Business Analysis has been the “Bridge”. However, in recent past, some in the BA community have started revisiting the metaphor resulting in a debate on how relevant it is. Of course, the value business analysis can provide for an organization does not depend on how it is described. So does that mean we should ignore this debate? I don’t think so. A metaphor is a powerful tool to develop useful mental models, and efficiently create possibilities for value-creation.

My take on this debate is that both sides are right. This is so, because the state of business analysis is not uniformly mature across countries and work cultures. For instance, BAs in North America are more likely to find the “Bridge” metaphor limiting/restrictive because of how the role has matured in the past decades. On the other side, for most BAs in emerging economies the “Bridge” metaphor still provides aspirational value.

So, what is behind my ambivalence? Most common interpretation of the metaphor is that it connects business and IT stakeholders. My take is that it is a bridge between the problem domain (current state) and the solution domain (future state). This take on the “Bridge” metaphor is not limiting, because it includes all levels of business analysis maturity - from strategy analysis to solution evaluation, and everything in between.

A New Metaphor

Not that there is anything wrong with a debate, but it is time for a new metaphor. I would like to share with the BA community a metaphor which has shaped my business analysis journey, especially in the past 5 years since I co-founded a business analysis startup. I look at business analysis as a “GPS” to move from the current state to the desired state. In other words, it guides stakeholders to achieve project success and organization goals. This metaphor is more inclusive (represents all flavors of BA role) and accurate (represents full potential of the discipline).

Let us look at the elements (features) of the conventional GPS system, which make it so useful; and how business analysis aligns with them.


#

GPS Feature

How Business Analysis aligns with GPS Feature in Projects

0

MAP – a useful representation of the landscape

· Build a representation of the business and IT landscape through research and analysis of industry; market forces, including competition; organization; operations; and current IT systems

1

CURRENT LOCATION – ability to determine current location in the context of the MAP

· Provide appropriate context for a project by customizing and sharing with stakeholders the relevant business and IT landscape

· Define current state of the problem domain, and frame the problem statement

2

DESTINATION – assistance to select destination, e.g. a highly rated Point of Interest

· Help organizations prioritize IT investments through business cases

· Facilitate definition of the desired state through solution scope and requirements specifications

3

NAVIGATION – real-time navigation to help reach destination most efficiently

· Facilitate selection of the best solution to meet requirements

· Facilitate shared understanding of requirements through requirements transition, continuous communication, traceability and change management

· Identify, engage, collaborate and coordinate with stakeholders; and support them to achieve desired solution

 

Any single feature, from the list above, is useful by itself. The “GPS” metaphor on business analysis is inclusive and aspirational enough regardless of the maturity of the BA role in a country, work culture, organization, or even an individual project. Furthermore, by symbolizing the positive global impact GPS has had on humanity, this metaphor helps us quickly and robustly communicate the power and value of the business analysis discipline.

My Experiments with this Metaphor

The “GPS” metaphor is not just a concept, which I made up for the purpose of writing this article. This mental model has fueled my passion, and shaped how I have approached business analysis in the latter part of my career. In fact, all service and solution offerings of my company are built on this mental model. I have received favorable and instant acceptance of this metaphor every time I have pitched my company’s solution portfolio to potential clients. I have also received positive feedback in training and coaching interactions from individuals when I have used this metaphor to provide more clarity about business analysis.

Your turn

I would love to hear your views on this. I hope that your active and constructive participation in this dialogue will not only help me crystallize my thoughts on this topic, but also give the BA community a new metaphor to actuate and communicate the potential of our profession.



What is Pega Process Managment?
by SarikaA
29 May 2017 at 3:50am

Pega systems(Software Company) is the leading provider of business process management (BPM) and customer relationship management (CRM) software solutions. Pega systems motto is “Build For Change” and their goal is to “eliminate software coding” and “automate manual work”.

Pega systems has been at the forefront of rules-based business automation systems since the early 1980s, a natural outgrowth of our founder’s pioneering work in computerized chess play. In recent years, as more and more businesses have concluded that business process management suites are a “must-have” technology, our BPM business has grown at twice the rate of the overall BPM market. At the same time, major analysts like Forrester and Gartner have consistently rated Pega systems as the leader in the dynamic BPM sector.

Pegasystems knows that what it all comes down to is delivering real-world business benefits, efficiently and quickly:

More so than any other process management suite, Pega BPM puts business users in control of process design and creation, while automating most of the code development and minimizing reliance on technologists.

Pega BPM patented inheritance technology enables a multi-layered process model in which a base of enterprise-wide rules and procedures are dynamically merged with an overlay of context-specific refinements suitable to particular regions, product lines, channels, or customers. This model enables you to capture in your BPM services a real-world reflecting mix of the universal and the particular.

To speed your time-to-benefits, Pega BPM offers a full range of industry-specific solution frameworks, based on best practices in financial services, insurance, health care, telecommunications, government, and others. For business process outsourcers, we also offer tailored BPO software and BPO solutions.

The perfect platform for enterprise-scale business performance management or business process integration initiatives as well as for more narrowly targeted pilot programs, the Pega business process management suite empowers business users, accommodates real-world variety, and pays rapid dividends.

End-to-End Business Process Management Services

Pegasystems delivers expert business process management services to support all phases and facets of your BPM project:

-Design review — Pegasystems’ business process management services team can help you get your BPM project off on the right foot with a thorough review of your application design. Working side-by-side with your project team and leveraging best-practice design principles, Pega BPM services staff will provide valuable feedback on both your design and your design process.

-Usability review — No matter how well-designed an application is internally, and no matter how powerful the underlying business process management system, the application won’t live up to its potential if your user interfaces are not meeting the needs of end users. The Pega business process management services team will review your UIs from the user perspective and help you identify ways to improve the user experience and increase user productivity.

-Transition readiness — Before you launch, Pega business process management services professionals will help you test your application, tune it, and prepare it for deployment. We’ll also work with you to assess your organization’s readiness to utilize the application.

-Performance check-up — Once your BPM application has been up and running for six months to a year, Pega professional services can evaluate your application’s performance to see whether you’re getting your maximum possible return. Detailed analysis and feedback from Pega business process management services -personnel can help you to fine tune your application and to optimize future applications as well.

-BPM methodology coaching — Pegasystems veteran BPM experts can coach your team on all the nuances of implementing an iterative and agile BPM methodology that best leverages the robust capabilities of your Pega BPM platform.

-Centers of excellence creation — Many leading companies are creating BPM-focused Centers of Excellence to drive BPM implementations across the enterprise. Pega professional services can help you with all aspects of launching a BPM Center of Excellence, including strategy development, infrastructure creation, and building of a BPM knowledge base.


Identifying requirements, the right way
by Surbhi Mahnot
10 Apr 2017 at 1:10am

Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.

Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:

Business Requirements Stakeholder Requirements Solution Requirements - Functional and Non-Functional Requirements Transition Requirements

With so many requirements to identify it is very easy to get confused with how to identify these requirements?

A simple approach is to visualize the complete process and start step by step

To do that, let’s look at cooking for an example:

When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).

Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.

Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.

Example: There shall be a Login screen through which Users will log into the system.

Tip to identify:

Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.

Example:

As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).

As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder -  Administrator).

Tip to identify:

Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:

a.      Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:

The features the system will support (Functional capabilities) Data validation rules and how they will be managed (Business Rules) Interaction between different stakeholders (users) within the system (Use cases)

These include a complete description of ‘how’ the system will be built.

Example:

Registered users shall be able to login with valid username and password On successful login, user shall be redirected to a landing page in the system On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials" New users shall be able to register with the system by clicking on the "Sign-Up" link Users shall be able to recover password by clicking on "Forgot Password" link

b.     Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.

Example:

Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max) Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click Platform: The login functionality shall behave same on different platforms (Windows/Linux)

Tip to identify:

To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.

Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.

Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented

Tip to identify:

Look for temporary requirements such as “migrate from old system to new system”.

There are many other types of requirements that are used across diverse types of systems based on the scope such as:

Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.

Example:

Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera Requires browser to have JavaScript enabled

Tip to identify:

Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.

User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.

Example:

Textboxes for username and password shall be placed below the respective labels for Username and Password Login and Cancel buttons shall be present in center of the screen Sign-Up link shall be present below the Login button Forgot password link shall be present above the Login button

Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.

#requirements


Challenges in Implementation
by Sanjay Yadav
20 Mar 2017 at 7:34am
 Challenges in Implementation:
 

 

I’m a strong believer of putting finishing touch to any initiative. Project Initiation is always tough and complex and need lots of research but if BA is unable to give the finishing touch then he is not done yet. So, I thought to put few of my views, challenges and observations during Implementation phase that I have faced. BABOK does a great job in explaining the Strategy Analysis and Solution Evaluation however real time challenges are most of time unspoken. As a Product based Business Analyst I often face few challenges which are altogether different than the last one.

 Stakeholder involvement and Governance: This is one of the challenging and critical step to find out the exact governance of stakeholders. Each stakeholder interest towards the product implementation do impact the final stage of the product. Lack of interest do hamper the product implementation. So if any stakeholder has less interest so its critical to know the reasons. Sometimes its better too to know why if any stakeholder shows more than needed interest. Maintaining correct and verified Project Charter does help in this.

 Over Expectation: Customers are always demanding and they should be as they are the one who are paying for all these, however as a Business Analyst you must be very smart to distinguish the expectation and over expectation of client because over expectation often makes your system more complex to use by the end-user and customer which ends with spending more bucks and gaining less.

 Deadline and Release Planning: As a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully even if you don’t meet the original deadline. The art of prioritizing the solution requirement helps you to pass through. You should keep some time in buffer so that you have availability of resources to fix the unwanted issues or the deadlock condition in approval or implementation.

 The Acceptance: Most of the time I have found more involvement of people in acceptance compared to when you do the brainstorming or focus group. Sometimes customer say that they aren’t looking for this altogether. So, providing a view of your product before acceptance saves you. Do not ever try to give more than requirement (without information), customer will treat it as a bug because they haven’t requested it. Though sometimes over-explanation saves.

 Training: Sometimes it happens that everything is as per the client request and you are at a better stage to close the project but you end with hearing that there is no such benefit by the new implementation. I have observed that sometimes the user is not aware of the new feature or do not know how to use the new feature at all. So, Training to right people is very important. Sometimes you should move desk by desk to see if customer the using it fully.

 Getting feedback: Learning from your mistake is very important however knowing what went perfect is important too. Feedback from customers is very important to learn and grow as a business Analyst.

There are number of other challenges that do a Business Analyst phase. I would love to hear. 

 


Defining Requirements
by Surbhi Mahnot
16 Mar 2017 at 7:47am

All professionals talk about identifying business needs, identifying requirements to create tools so that they can help businesses take better decisions. In your career as an IT professional, I am sure at some point you must have heard terms such as “Requirements”, “Business Requirements”, “Software Requirements”, “Project Requirements”, “Technical Requirements” and the list goes on.

So, what are these requirements?

“Ours is a world where people don’t know what they want and are willing to go through hell to get it.” — Don Marquis

Well, to most of the people, this appears to be a simple question. But, this is the most complex question to answer (for the professional responsible to gather requirements, primarily a Business Analyst) as it takes forever to ask and understand “What are the requirements”.

Different people have different ideas of requirements. For a product owner, requirement is as simple as the ability to use/sell the product that helps with the business and revenues. For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company. For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly. For a developer, requirements are to develop the assigned feature or make changes in the software as requested.

Requirements, at first glance are really needs (end objective), wants, suggestions or ideas. Derived from those needs, we set an objective and take a decision about what things should be done or not to be done to achieve that objective.

Requirements are a set of prioritized needs from all the involved stakeholders that form the base for the functionalities or features to be included as a part of the solution.

Per BABOK guide, official definition of requirement is:

1. “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” In simpler words, a decision-making process to derive requirements from needs.

2. “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.”It is a step where business requirements are drafted as solutions requirements to get started with developing the solution.

3. “A documented representation of a condition or capability as in 1 or 2.” The documentation is itself a requirement as it helps all the stakeholders and consumers in understanding the requirements for the solution.

Where do these requirements come from?

All the requirements arise from a need. We need to understand those Business Needs or the Business Problem Statement. Unless there is a problem, we can’t think of providing a solution. A lot of analysis and research is carried on before requirement analysis to understand the problem. These involve feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy etc.

A Business Analyst (BA) starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, solution requirements, technical requirements and transition requirements primarily.

Talking about stakeholders, it’s important to know about who they are and how critical is their involvement in the project.

Who are stakeholders?

A stakeholder is a generic term for a person or group of people who are involved with the project (directly or indirectly) and have a say in decision making process of the project. They can be:

Executive Sponsor — Mostly concerned about funding of the project and high-level information Product Manager — Make important decisions for the project and review & approve requirements Project Manager — Prepares project plan, resource allocation plan, manages the execution of the project and works very closely with the BA (Business Analyst Subject Matter Experts — Assists in defining project scope, works with the BA to define business rules, processes and user interface

There is a whole set of other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators and others who can be important stakeholders in a project, depending upon the needs.

How stakeholders help with requirements?

Since each stakeholder plays a different role in the project, they have different requirements too. Sometimes, what emerges as the biggest challenge for a BA is to extract useful information from all these stakeholders that matches the preferences best with the client’s business. This is because each of them view the project from their own perspective!

To create best requirements for a project, identifying responsible stakeholders is important. There are many techniques available such as RACI matrix. Not all stakeholders are important for every project. It is primary task to identify the right stakeholders and their say in the decisions to keep things smooth in long run. (When all speak, it becomes real hard to reach to any conclusion).

How are requirements identified? “The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.” — Steve McConnell

The process to identify requirements from the needs or conditions is termed as Requirements Analysis. A detailed analysis is critical to solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, documenting and managing the changing requirements. There are different standards set in different organizations for the requirement analysis though the primary steps could be identified as:

Identify stakeholders Requirements Elicitation — capture stakeholder requirements through various techniques such as interviews, questionnaire, joint group discussions, prototypes or use cases Identify requirement categories — categorize all the gathered requirements into functional, non-functional, business, technical or transitional requirements Analyze requirements — analyze the requirements whether they are clear, complete, unambiguous, consistent and testable Requirements documentation — requirements are documented in various forms such as Business Requirements Document (BRD) to describe business requirements, Software Requirements Specification (SRS) to describe functional and non-functional requirements, Use cases and User stories (in agile context)

These recorded requirements documents are then collaborated upon to receive feedback from all involved stakeholders. Once the requirements match the needs for the project, it is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages.

Why are requirements important?

Per new research,

Success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their project Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization

Requirements serve as the basis for the project plan and if there are inadequate or incorrect requirements, entire project will suffer at the end.

They are used as inputs into the design stages of product development They are important input for verification process for the product developed They represent what functionalities are necessary for the product Excellent requirements leave no room for interpretation, confusion or omission of critical details and is easily understandable by everyone involved in the project.

Next time when you start with your project, make sure you have all your #requirements…clear and loud!

Stay tuned for more with requirement types, characteristics and more coming up!

This article was originally published by me on LinkedIn


Experience Age - a new era
by Edward
14 Dec 2016 at 12:03pm

A few weeks ago, one of my colleagues surprised me with a statement he made during our team meeting that the information technology age is coming to an end. I looked at him in complete disbelief. How can the advances that have brought so much convenience to our lives be said to be coming to an end.  I thought he must be mistaken, and just like a student who has just been given a topic for an assignment, my curious nature of always wanting to know kicked in and I set out on my little research – not to pass this time, but to prove him wrong.  I asked myself how can we live without information technology, and how can life be better without information technology, which has brought with it globalization – a concept that shrunk the world into a small village.

However, after reading a few articles on this topic, I realized that just like there were other ages before – for instance, during the 17th century human beings lived off the land, and were mainly agrarian. During the 18th century – the Industrial revolution happened – ushering in a new era in the history of mankind – the Industrial age, and continued to evolve through to the 19th century. That too subsided in the 20th century and gave way to the new kid on the block – technology, which revolutionized communication by introducing telephone, radio and television. And we have come a long way since then.

Needless to say, the advances that have been made in the technology space have been in leaps and bounds since the invention of the telephone line, and created what has come to be known as the ‘information technology’ or ‘information economy’ age. It is the world as we currently know it, and as we currently expect to operate.   However, the earth has never stopped moving….it continuously orbits the sun 365 days a year.  This means that, as much as we have felt comfortable with what we have come to know - the ‘information economy’ age – this period was also never here to stay either. At some stage, just like the earth is consistently in motion – this age would have to come to pass, and make way for a new order of things.

At the centre of the information technology age is the focus of acquiring, storing and processing data to meaningful information and insights to better organisations’ economic progress.  And as we in the first quarter of the 21st century, the non-stopping advances in technology are preparing us for a new era – the experience age. It is reported that by 2025, which is a mere 7 years away, the virtual reality experience will be almost close to the new reality – such that conscious efforts will have to be made to make people to be able distinguish between the real ‘reality’ and the ‘virtual reality’.  This age will bring with it a complete paradigm shift – from how data is collected, stored and processed to become meaning and useful information in the form of business intelligence to how consumers will experience products and services offered by organizations.

The significance of data collection and/or data mining to gain customer insights will no longer be of primary focus. The experience age will necessitate the creation of virtual reality for the consumers to experience a product and/or a service even without buying it. For example, they will feel like they are ‘physically’ at the stadium watching a soccer or rugby match, while sitting in the comfort of their homes.

 

The experience age will extend the use of technology even further. It will allow for the use of technology to enable the consumers to experience a product or a service in that moment as if it were real or as if they were already consuming it, even though they were still trying it out. Some of this might sound far-fetched and just a fantasy. However, who would have thought that the demand for voice calls on mobile devices would be replaced by the demand for data services like WhatsApp – a move that has just happened over the past 5 – 10 years? And to push the envelope even further, the demand for data services for chatting and sharing of pictures or videos will soon be replaced by demand for data services for video calls – something that Facebook has realized and now introduced video calling on WhatsApp. Consumers will demand the experience of seeing each other as they are talking to each other. Yes, this is already happened in some parts of the world, but not at the ubiquitous level at the moment.  This is the experience age shaping up right before our eyes.

The experience age will also be of great benefit to the services market. At the moment, consumers can only experience the quality of the service offered by a hotel by physically staying at the hotel. However, with the advances in the experience age, the consumer will be able to take advantage of the virtual reality and experience the stay at the hotel before actually staying at a particular hotel. At the moment, all that thought and decision making process of which hotel to choose is driven by data – either personal or impersonal, i.e. either through word of mouth from friends who have stayed over at that hotel, or through what the hotel publishes about itself on websites, brochures and other sources of information. And all of these touch points may prove, as some of you may agree with me, very deceiving and lead to a disappointing experience.

In the product market space, gamification will probably become one of the dominant form of introducing the experience age to the consumers. In this way, technology will be used to create games for customers to experience the product they are interested in even before buying it – as part of playing the game – as opposed to reading about what the product can do or see the TV ads about what a product does. 

We cannot speak about the experience age and leave out the new buzz word, the IoT – the internet of things. This concept simply means that every device with a power switch can be hooked on to the internet – the connectivity to the internet will not only be exclusive to devices such as laptops, computers, mobile telephones.  These devices include cars, televisions, fridges etc. The ability of these devices to connect to the internet will also change how we ‘experience’ the world we live in.

Cars will be able to communicate with each other, with the traffic lights, with mobile devices of the people you are having a meeting with to advise them that you are running late, to identify roads congested with traffic due to accidents or traffic lights that are out, and to decide alternative routes. Fridges will be able to contact your local supplier to order milk or whatever it is that you will be running short of. We currently see the advances made by smart TV’s which are already able to connect to the internet. Thus the IoT will be another form through which the ‘experience age’ is rendered to us by technology.

Therefore, the paradigm shift I referred to earlier on means that organizations will have to change their strategies, as the focus will no longer be on relying on big data to run analytics, but rather on using technology to provide real time experience to acquire and retain customers.  The experience age calls for a different mindset, bearing in mind that consumers are also changing. We are talking millennials now, and no longer the X’ers and the Y’ers – and they have a different view of the world – which is proving to be a challenge to both their employers and companies offering services or products to them. And I believe that this is food for thought for us in the information technology space.  In order to adapt, companies have to gear themselves and their mindsets towards IoT, robotics and experience age to remain relevant and up to date with the new era.
10 TIPS FOR A BA TO WORK EFFECTIVELY WITH A PROJECT MANAGER
by Chileshe Mulenga CBAP PMP
7 Nov 2016 at 11:44am
EXECUTIVE SUMMARY

The Business Analyst and Project Manager are team players on a project. As is common the Business Analyst and Project Manager sometimes have conflicting approaches during a project.

Having frequently taken up dual roles of a project manager and Business analyst during the course of my career, I have gained some insight on the dos and don’ts for a business analyst to work effectively with a Project Manager

The following are the 10 recommended Tips:

TIP 1 – Collaborative Stakeholder Analysis

Key to your success as a Business Analyst on any project is identifying your key stakeholders and having a good understanding of their interests and levels of influence. From my experience this is a task best done in collaboration with your Project Manager to ensure you speak the same language when it comes to managing your stakeholders. Imagine a situation where you haven’t captured the requirements a highly influential stakeholder already identified by your Project Manager. This could in turn result in unwanted reworks on the project, increased costs and project delays.

TIP 2 – Synchronization of your Business Analysis Plan with the Project Schedule

It is good to ensure that the activity dates of your Business Analysis Plan are incorporated or synchronized with the Project Manager’s Project Schedule. Nothing is worse than discovering that the period of time the project manager has allocated for your Business Analysis Activities is insufficient.

TIP 3 – Usually not all requirements can be captured up front.

Many Business Analysts discover that as much as the intention may be to capture all requirements up front before the execution phase, there are actually few cases where this is possible. During execution it is common that stakeholders bring up forgotten requirements.  The good news is that usually the Project Manager will define the Acceptance criteria with the client. The acceptance criteria is an agreement of what the product or service should constitute for it to be accepted by the client. The Acceptance criteria are usually part of the signed off project charter.  Other Project Managers may use the agile approach where prioritized requirements are implemented in phases. In summary A BA must accept the fact that in most cases not all requirements will be captured up front.

TIP 4 – Non Functional Requirements vs. Project Scope

As Business Analysts we also capture non-functional requirements i.e. the expected efficiency level of a system. It is good to liaise with your Project Manager on what is out of scope for the Project. It is common that non-functional requirements requested by stakeholders are sometimes not feasible due to budget and time constraints. In summary you need to be on the same page with your project manager on what is out of scope. This is to avoid complicating the management of your stakeholder expectations

 

TIP 5 – Help to minimize Scope Creep

As business analysts we know that stakeholders may request additional requirements during the course of the project. As Business analysts a new requirement is accepted or rejected depending on whether it can be directly linked to the Business Need. However Business Analysts need to remember that project manager aims to minimize new additions to the project scope (Scope Creep) that will require the adjustment of the Project budget and Schedule.  In most cases stakeholders are not willing to incur the increased cost or time required for inclusion of new requirements.

 

TIP 6 – All changes to requirements undergo impact analysis

Whilst carrying out the Requirements Management & Communications process the business analyst must ensure that changes to requirements go through the Impact Analysis process managed by the Project Manager. This is to ensure that the Impact that a change in requirement will have on the Project Schedule, Project Cost or product quality is assessed before the requirement change is formally approved.

 

TIP 7 – Collaborative Prioritization of Requirements

Prioritization of requirements is a standard task that we carry out as Business Analysts under Requirements Analysis. However it is common to reach a road block where stakeholders wish to classify all their requirements as high priority. This is usually due to the fear that non high priority requirements will be excluded in the project scope. With this in minded it is recommend that prioritization of requirements is done with the involvement of the project manager to assist in management of your stakeholders.

 

TIP 8 – Synchronize the list of prioritized requirements with the vendor selection criteria

Selection of vendors is procurement management task that critically requires the input of the Business Analyst. Selection of vendors is usually based on each vendor being evaluated against the vendor selection criteria defined by the project manager. It is crucial that Business Analyst ensures that the vendor selection criteria is synchronized with the list prioritized requirements.

 

TIP 9 – Transition Requirements can sometimes be implemented as post GO LIVE tasks

Business analysts also capture transition requirements i.e. the required training of users.  For a Business Analyst a project is complete when all the categories of requirements i.e. transition requirements have been implemented.  However what is sometimes experienced is the Project Manager wishes to separate the implementation of transition requirements from the Project Scope and treat transition requirements as post GO Live tasks. This is usually the case when Project has a non-negotiable constraint on the GO Live Date.

TIP 10 –Factor in Project Manager’s constraints and assumptions when the defining the solution scope.

The Business Analysts defines the solution scope under the process of enterprise analysis. It is critical that the Business Analysts gains the input of the project manager on constraints and assumptions before defining the solution scope.

 

CONCLUSION

To work effectively with Project Manager a Business Analyst has to be able to understand aspects of stakeholder analysis , Project Schedule , Project Scope ,  Managing scope change , vendor selection criteria and project constraints from the eyes of a project manager.


9 Traits of an Incredible Awesome Leader
by Paul Crosby
7 Sep 2016 at 9:34am

There are hundreds of traits that make up a good manager, but here are the top 9 skills we recommend for a business analysis leader - or any leader in general.

1. See Design as a Differentiator

Anyone can design but not everyone designs well.  Who cares?  Frustrated users care.  Seeing design as important sets you apart from all other business analysts that don’t’ give it a second thought.  Build interfaces that are practical and good looking.  Don’t see design as something someone else does – it something you as a business analyst can do.

2. Build the Vision – Be Adaptable to the Approach

Build consensus and a strong vision for the outcome.  Share the vision of the outcome for the project far and wide to gain a common understanding within your organization on the vision.  Share frequently and share often.  Implementing the vision can take a thousand paths.  Be adaptable.  The way to realize your vision isn’t going to be on a clear cut path – there will be many forks in the road.  Understand that planning is important in elicitation of requirements and design, but it’s volatile and subject to frequent changes.  Create a planning approach the ensure your path forward is well understood, but balanced against overly complex and detailed planning.

3. Understand Your Customers & Users

At the heart of the vision lays the core user.  These are the users that interact with your applications, systems, and processes every day.  Without them everything just fades away or collapses.  Identify your core users then profile them to build meaningful interfaces and processes targeted directly at them.  Target your communications and marketing strategies for your vision and product to them very specifically.  Knowing how to turn the heads of your core users and get them to support your vision is critical to your success.  Once the core users are on board all the other types of users will fall into place.  Build a fan base.  Even an accounting application can have a fan base.  Fans support you and give you new ideas to build your vision.  Treat your fans well and they will support you through thick and thin.

4. Don’t Plan More Than 18 Months Out

Long term planning past 18 months is impossible.  Markets and organizations change too rapidly to have road maps or long term planning past 18 months.  The second you produce that 5-year plan it’s obsolete.  Keep fluid in your planning to reach your vision.  You may need to re-group or re-think your approach several times over.  It’s better to be aware that you need to change your approach and planning frequently than to forge ahead thinking it will be set in concrete. 

5. Plan, Perform, Evaluate, Adjust

We talked about planning above.  Here’s a cycle that works: 

A. Plan It Out – choose your path to reach your vision.  Keep a Requirements Work Plan (RWP).  Build the consensus and understanding on the tasks you are performing for the project. 

B. Perform the Plan – don’t let the RWP sit idle.  Work to carry out the tasks outlined and meet the dates you assigned yourself.  This builds trust.

C. Evaluate continuously – be aware your best-laid task list could change in an instant.  Be aware of other activities or projects that are pulling you away from meeting your plan.  Check your progress against the plan and know when things are going off plan.

D. Re-Plan Proactively – get yourself back on track and re-plan frequently.  Keep your team aware of the re-planning process and why re-planning was needed. Frequently re-planning is better than falling too far away from the plan and missing expected dates. There are no hard and fast dates no matter what the project manager tells you. 

6. Don’t Rely on One Method of Communication

Email is tried and true but not the only way to communicate out your status, projects success or potential changes to users.  Everyone is overloaded with email.  Find a new channel of communication to keep your project’s vision and potential organizational impacts visible.  Personal notes, open houses where anyone can swing by during a 2-hour period to ask questions, and even hallway meetings are a great way to communicate.

7. Focus on Opportunities – Destroy Problems

Only focusing on problems takes your eye away from opportunities that will bring better results.  Choose the bright side and be optimistic in your attitude.  New opportunities will present themselves. Be prepared to take advantage of them.  Find problems and get to the root cause – then destroy them.  Don’t focus on trimming a problem’s branches or cutting it down instead, kill at the roots.  Don’t let the problem linger around or give it the ability to grow back.

8. Carefully Build the Team – Build Strong Relationships

If you get the chance to choose team members, then choose carefully.  Listen to your gut feeling and don’t bring on board resources that you don’t or can’t trust – even if you can’t explain why.  It’s hard to put into words sometimes why you don’t trust.  Choosing the right members for the team will make or break the vision. Maintaining a team is equally important.  Spend time every week celebrating or gathering the team informally outside of the daily stand-ups or weekly status meetings.  Try to hold that meeting somewhere different and fun.  Even moving to a different conference room will oddly change the team’s perspective – especially if they are trapped in the same war room every day.  Always be grateful and reach out to say “Thank You”.    Remember those different communication channels?  Don’t always email – try a hand written thank you card or just ask them out for a coffee to say thanks for their help.  Building the strong relationships get you through the tough times in a project. 

9. Know Your Strengths – Outsource Your Weaknesses

You are not everything to everyone.  Figure out your strengths and what you are good at.  Personality tests give you a hint but ask around.  Listen to what your colleagues, friends, and family believe your strengths are.  Play to your strengths – you're strong at certain things for a reason.  Know your weaknesses – then outsource them or engage someone to help you overcome them.  Ask for help.  For extra credit build the project team knowing the strengths and weaknesses of everyone on the team to balance them out.

So here’s the truth.  As leaders and contributors in the Business Analysis field, these are the skills we need every day.  They are also the skills that founders of companies hold. 

Check out more great blogs at Bob the BA today!

 


Are You Being a Design Illusionist?
by Paul Crosby
7 Sep 2016 at 9:31am

As business analysts, we are often in the fray of designing.  Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems.  Our design choices impact users and other systems in a very real way.  This power can go unnoticed even in our own minds. 

Have business analysts become illusionists and pickpockets?  Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us.  If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl.  It does an excellent job of explaining how an illusionist can fool our sight and point of view.  For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.

Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces?  Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use. 

We all believe we have choices and freedom.  Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal.  You can go just anywhere and do just about anything.  But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.  

We rarely ask the questions:                                   

(1) What is NOT in the interface?  Or why are these my only choices?

(2) What is the purpose or goal of this interface?  What is it used for?

(3) Why are these options higher or lower on the interface?  More visible or less visible as other choices?

(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?

If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention.  I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one!  I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.

Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers were called mainframes.  Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat.  They required a forklift to move and had to be water cooled. 

In those ancient days of computer myths and data Gods, there was but the humble green screen.  To get to all the crap stored in that giant mainframe required you to issue the magic commands.  By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder.  In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly.  The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct.  No Google-like “Is this what you mean?” ever appeared on the screen.  Even the help key which was supposed to provide assistance rarely did.  This was the world of complete freedom from “the menu”.  All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform.  Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.

Enter the age of the personal computer.  For simplicity, the command line went away.  The mouse was born.  There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen.  “This mouse thing will never catch on” they grumbled.  Suddenly the command line was gone, and menus or buttons presented to us.  These were your options.  Your only available commands.  It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.

Over time we became to believe that only the commands we could see were the ones of importance.  We would become less and less frustrated at not seeing the things we needed.  We are restrained by choices of actions presented.  Our perception came to be that if it wasn't presented, it wasn't available.

So let’s take this into the modern smartphone age.  The other night friends and I were out at a restaurant having a great conversation.  The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night.  We asked each other the question “let’s continue this conversation – where should we go?”.  We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late.  This searching went on for 15-minutes or so.  Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these.  I quit my search letting the others wade their way through the digital data flowing around with smartphones.  Then I looked up.

A beautiful park lay right before our eyes across the street, and we didn’t even see it.  We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park?  Not one.  How about that food truck with the fabulous desserts?  Nope.  Not a single one.  Our illusion of having choices was broken.  Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”.  The menu or interface design didn’t answer our actual question at all.  It created the illusion of choice by presenting a small subset of options.  All said and done the park was bug-free which is a miracle in Minnesota some evenings.  Dessert and conversation continued for hours in the street lamp lit park.

As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path.  But does that answer their question?  How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”.  The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.

There are a thousand paths to getting or achieving something.  No matter how hard you try to make it simple, it just winds up being even more complicated.  Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button.  Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface.  As a business analyst and designer, we need to give our users or community a rich experience with our application.  Are we the illusionist – forcing users down only one path?  Our accounting system has several ways in which to generate an invoice.  From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface.  As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important.  Not everyone went about taking the same path. 

Sales people always went to look at the customer inquiry screen first before generating an invoice.  Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice.  Customer service created invoices from the order screens as they were more focused on shipping products.  Finance folks just clicked on the main menu option. 

Know your users.  They each have a story and a way of performing tasks that make sense to them.  Think about their “persona” and what they need to accomplish.  There is no single path to creating an invoice.  Develop a list of capabilities and make sure they are not “hidden” from view.  If it all doesn’t fit on a screen, find ways to expand the options for display when requested.  Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users.  It is more about clarity for your users then consistency in terms.

What has a dinner in the park taught me?  Smartphones are not as smart as we think they are.  Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand.  Question the choices presented and determine if they are the only choices.

Yes, I still miss my green screen terminal.  CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone.  And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

 


Pablo Picasso and Scope Visualization
by Paul Crosby
7 Sep 2016 at 9:28am

Scope – the last frontier.  We are on a mission where no business analyst has gone before.  To explore strange new diagrams and to have the project scope clearly understood.  Extra credit to those who remember which TV show that was from!  Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality.  Projects today are more complicated.  In this integrated and connected world of systems long gone are the days of the quick and easy change.  Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs.  Symbols and shapes connected by lines that fill the wall of an entire room.  Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people.  Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all.  Stakeholders are flung across the globe speaking many different languages.  Top it off with organization’s taking on hundreds of projects at the same time.  Keeping track of each project’s scope and impacts to the organization are difficult to comprehend.  It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value.  They lose sight of the project's vision and goals in our complex systems and processes.  Everyone is one a different page.  We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope. 

So it’s no wonder that scope and context are the number one reasons projects fail.  How can you get an entire project team moving in the right direction?  Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project. 

So how do we get everyone on the same page?  By that, I mean the same page in the same book!

It’s time to visualize scope.  Scope places the boundaries around where the entire project team will work.  Bust out that context diagram.  Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value.  Is that user story a complete representation of the project boundaries or scope?  Maybe not.  The EPIC or a bunch of user stories combined would be closer to the bulls-eye.  A picture is worth a thousand words.  Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram.  That’s certainly a great tool, and I blogged about it previously.  Don’t get me wrong – I love my context diagrams.  Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams.  In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers.  Sticking 1,300 servers on a diagram was an exercise in futility.  There just isn’t a big enough piece of paper to display them all.  So I pictured things at a higher level.  I presented each server farm as a farm – yup cows and red barn with Farmer Joe.  The size of the farm was based on the number of servers on that farm.  Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily.  All of this was based on estimates from doing a high-level scan.  Remember context is high level.

In each barn was an icon that represented a group of servers.  There were three groups:  leave it alone, upgrade it and consolidate then retire it.  I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders.  Servers were put into groups based on our best guess. 

In the kickoff meeting, this was a great tool.  Sponsor and stakeholders understood in the scope of the project.  Yes, they wanted to know more.  Everyone wants to know the details, but we were just starting out.  Everyone walked out of the room with a pretty good understanding of the scope and estimated size.  Many were surprised at the volume of servers in each farm.  Overall the infographic did an excellent job of setting the stage for the project visually.  All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people.  That’s no easy task.  Taking the complex and making it simple is powerful.  It creates a better shared understanding of the project. 

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project.  It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram.   You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project.  They show the scope of a project outcome. 

Building on a good thing, I like to build a context diagram of the current environment at a high level.  Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state.  It’s a great tool to get everyone on the same page for the starting point.  Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination.  Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state.  Not many projects look at the desire of the stakeholders and sponsors.  The desire is stated in the project request form or project charter.  The sponsor and stakeholders put together a vision of the expected outcomes in these documents.  A context diagram of the project charter or request which elaborates the vision is a powerful thing.  It ensures what is being asked for is understood.

Don’t re-invent the wheel.  Many times I take the current state diagram and just highlight the areas that are changing.  Use color to highlight the add, modify or removes based on the context diagram for the current state.  Color visually explains where the changes are visualized to occur. 

Now you may think I completely lost my mind at this point.  Fear not I’m taking a step even further.  I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible.  Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet.  Reality always steps in and dictates what is feasible.  Taking the context diagram I will highlight the areas that are NOT feasible.  It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen?  Ideally, it should happen before the project starts at a very high level.  Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome?  You can bet it would save a lot of time running around trying to get everyone on the same page.  Typically, the context is set at the start of the project. 

As you move through the project, more and more understanding is acquired.  Details need hammering out and there is ALWAYS change to the project.  Has anyone ever worked on a project with absolutely zero change?  If you have, you are leading a very charmed existence.  I’m jealous.   Context diagrams can help evaluate how a change would impact the project.  So forget about laminating them and hanging them on the wall.  They are living breathing documents that will change throughout the life cycle of the project. 

The pitfall is that architects and others might expect diagrams that show the smallest of components.  Don’t fall into that pit.  Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out.  Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information.  Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative.  Find a way to display context or scope in a visually appealing manner.  Color can help bring greater clarity.  Highlight areas in different colors to bring focus to them.  If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk.  Black & White isn’t your friend.  Studies have shown that color diagrams – even with a small amount of color – are more memorable.  

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today.  Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

 


8 Ways to Be a Badass Business Analyst Employee
by Paul Crosby
7 Sep 2016 at 9:23am

Being a badass isn’t about intimidation or trying to be something you simply are not.  It’s about knowing who you are and using your strengths to drive forward.  So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass.  A badass isn’t afraid to learn something new about their craft.  Always be willing to step up to the plate and show what they are good at performing.  Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.  

A few years ago I was managing several projects.  Things were not going all that well on these projects, and I knew something needed to be done to get them on track.  Holding up the schedule and pointing at it wasn’t solving the problems we were facing.  I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects.  I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project.  My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft.  By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure. 

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining.  Keep a “we can do this” mentality even in the toughest of times.  The measure of a badass is in being able to be calm, think clearly and project positive possibilities.  When the whole world is crashing down, don’t be the one saying “Well that figures.”  Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.”  See the good in situations where others cannot.  Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”  

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place.  The team quickly got very negative at all the challenges that we were having in development.  Everyone’s attitude soured and nothing was getting accomplished.  The project was on its way to failure.  So I threw a pizza party.  My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up.  Pizza does wonders for putting a team in a better mood.  I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets.  I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?). 

This was no easy task.  I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative.  I was direct in telling them “Nobody wants to work on a negative team – it sucks.  What can we do right now to make this team more fun and productive?”.  After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project.   I kept telling myself that no matter what happens I will remain positive.  The team’s attitude evolved over time.  Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems. 

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools.  They are constantly expanding their toolset and keep current about their craft.  It’s too easy to get comfortable and begin to feel there is nothing more to learn.  A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed.  I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different.  Damn, I was bored out of my mind because every day was the same thing over and over.  Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas.  So I forced the issue a bit and shoehorned my way into a call center application.  It made sense for me to pursue it because that new system would be feeding the data warehouse.  I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application.  It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes.  After the project had been finished, I was seen as being useful in business process as well as data warehousing.  The door opened, and I got the chance to work on a whole new set of projects.  Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important.  Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems.  Process improvement is powerful.  A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles.  A badass looks for ways to improve the working conditions and tasks their team performs.  It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier.  Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes. 

5. Know Thyself Well

Know thy strengths and know thy weaknesses.  A badass is aware of their strengths, and they know their weaknesses and limits.  In today’s corporate culture, we focus on weakness.  By focusing entirely on weaknesses, performance appraisals have become more like firing squads.  A badass knows to play to their strengths and to engage others to help them out with their weaknesses.  

There are certain things I have discovered I’m genuinely bad at.  Anything that involves molding clay into an object is bound for disaster.  Both of my skiing trips ended in an uncomfortable tree hugging.  In business I know I’m a driver – be quick, be bright and be gone.  It wasn’t until half way through my career that I realized how that impacts others who are not drivers.  By understanding how I lead and act, I was able to soften my approach and be more collaborative with others.  My driver mentality is a strength that others recognize.  I can snow plow through massive amounts of data to give clear direction.  I communicate quickly and concisely on projects. 

Play to your strengths at all times.  If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out.  If you get the chance to put teams together, look at each others strengths and weakness to balance them all out.  Forget about finding that perfect all around team member without weaknesses.  They don’t exist. 

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass.  If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them.  A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk.  If there is an elephant in the room, then say there is an elephant in the room.  A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power.  Address it quickly and directly.  Forcing the issue is a one-way ticket out the door.  Follow the “Toot, Toot and Salute” rule.  Bring it up once and if there is no response or disagreement then re-group your thoughts.  Bring it up again and if there is still no response or disagreement, then accept it and move forward. 

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged.  It puts them on the defensive right away.  A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning.  A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully. 

Nobody likes to feel they are being interrogated.  Be fearless but considerate in digging deep.  Verify your thinking and dig deeper with “Help me understand” questions.  Share what you have learned to validate it.   Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly.  The most significant problems I created for myself was making assumptions and never validating those assumptions.  You may not be able to validate or challenge at that specific moment.  Write it down, reflect on it and determine if you need to challenge it.  Challenge appropriately and thoughtfully.  Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role.  They had the initiative and don’t shy away from leading in their craft.  They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them. 

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit.  I’m probably more comfortable with that then other business analysts in that I have been a project manager.   My favorite is when I’m told how long it will take to gather requirements.  You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design.  When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design.  I review it with my stakeholders, project team and sponsors.  This runs face first into the project managers desire to create and control the schedule.  By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget.  Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done.  Step up to leading the task and schedule you will be expected to adhere to for the project. 

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

 



Newsfeed display by CaRP
Share this page


Follow Business Analysts