Skip to main content

Tag: Competencies

Project Managers: 7 Things They Want Their Business Analysts to Excel At

I decided to perform a bit of a survey or experiment or whatever you want to call it.

I decided to ask several career project managers I’ve personally worked with and a few that I’ve connected with online as to their thoughts on what they wished, wanted or were grateful that their business analysts excelled at on the projects they managed with them. After rummaging through their wishful and rambling responses, I’ve come up with these 7 general themes…

Customer interaction.

The project manager is the key customer facing individual on the project. No question. The PM leads the initial project activities with the customer including kickoff, weekly status calls, and ongoing – potentially daily and sometimes hourly – communication with that project client. But having a business analyst who knows their way around the customer is a huge benefit to the project manager, the team and the project in general. When I’ve had business analysts who felt comfortable conducting meetings and requirements definition sessions with the client on their own, it’s freed up my time and mind to handle other activities on the project, charge less to the given project thus keeping the budget in good health for when issues need to be addressed (and there will be issues!), and perform other work on other projects.

Being technical.

This could also read “being familiar with whatever processes necessary given the industry the project pertains to.” I said “technical” because I’ve really only ever led technical projects. Having the right industry and technology knowledge will smooth the communication process with the project team that the BA really needs to have in order to be properly effective.

Tech documentation.

When the project manager has a business analyst who knows their way around a good project document deliverable, it is truly a great thing. I realize experienced PM’s and good BA’s probably take this skill for granted, but it is not a given. Nor is attention to detail which can lead to error-prone deliverable documents. I know, I’ve had it happen. It resulted in me and my team going to peer reviews on every deliverable going forward due to one business analyst producing three consecutive error-prone versions of the same documentation deliverable.

Being organized.

The organized business analyst contributes greatly to the project engagement without needing close supervision and oversight that a less experienced and less organized business analyst otherwise would. When the PM has confidence in the BA’s ability to just take the ball and run with it on decision-making, project team communication, and customer interaction, the freeing affect for both is incredibly productive.

Handling project budget issues.

I think most business analysts are pretty smart when it comes to expenses on the project. They think more like PM’s who are accountable for such things than tech team members who expend the hours that are in the budget and need to show 100% (or close to it) utilization. In other words, most business analysts – unless they are tech leads dually acting in the business analyst role – know they are considered more “management” than not. I’ve always said that keeping the project budget within 10% of target makes it much easier to stay on track in terms of dollars and budget. Staying in the 0-10% range means you’re always in the zone of “acceptability” and it isn’t likely to go crazy and leave you with a 50% budget overrun to try to fix…which you won’t likely ever be able to do. Having the business analyst who can understand that and help manage that budget and keep it on track is win-win.

Leading meetings.

This one is more than just customer interaction, of course. The business analyst, in many cases, is like the team lead. Interacting very, very closely with the tech lead on the technical projects in the requirements definition process and translation of those requirements into functional design documentation and a technical design document from which a viable project solution can be built. The BA must be, then, a trusted and accurate and effective project communicator. One who knows how to plan for, facilitate and followup on meetings with the team – and the customer, of course. Knowing how to run a status meeting, take notes, put together a meaningful agenda and project status meeting goal and how to follow up afterward with participants to ensure everyone has landed on the same page. Also, as important, is knowing how to put the right people in the seats at every meeting they conduct. It doesn’t do any good to call the right meeting to discuss the right topic if no one shows up. if you can run a good meeting that makes people want to attend and participate in rather than avoid, then you are golden. Someone who can get 100% attendance and participation is critical to project success.

Understanding PM processes, practices and tools.

Finally, yes…they may not be dually acting in the role of the project manager, but knowing how good project management executes and delivers is very helpful. That way they understand what the project manager is doing, is responsible for and probably will need help with. The more the PM and BA know about each other’s roles, the easier and more productive that relationship will be. And that’s a good thing. Think Batman and Robin. And the PM is not always Batman – it depends on what the responsibility is at the moment. They work well together and help each other out. Not quite like completing each other’s sentences…that would be weird. But close. BAM! POW!

Summary / call for input

The project manager and business analyst should work hand in hand together in a perfect world. Nothing is perfect, but my most successful projects have certainly been spent working with a business analyst who could take the ball and run with it. And most I’ve ever worked with have been able to do that – it seems to be in their nature and work ethic and it certainly makes the project run more smoothly and has always resulted in a more confident and satisfactory delivery team to project sponsor relationship.

Readers – what’s your take on this list? If you weren’t included in my small survey…and yes it was a very small pool…then now is your chance to share your thoughts and experiences. Do you agree with this list? What would you change about it? Please share and discuss.

In the Age of Cloud Computing Business Analysts Are More Essential Than Ever

Almost everywhere you go in IT these days, the talk of the town is about cloud: what it is, why it matters, how to get there.

This comes at a time where the market is ruthlessly driving down costs concurrently with increasing demand for delivery of information.

Cloud is emerging as a way of making a business organization more agile, nimble, and efficient so that it can quickly meet business needs.

In this rapidly changing environment, business analysts are becoming vitally important in helping to guide the transformation that is underway. Their role as agents of business change places them in the eye of the storm when it comes to cloud initiatives.

Related Article: Software Solutions: Should I Outsource, Buy, or Develop In-House?

So how does a Business Analyst prepare for cloud computing? First, it is crucial to understand precisely what cloud is. Second, it is important to understand what the challenges and pain-points caused by a transition to cloud. Only then does it become clear how important a business analyst is for addressing the important issues raised by cloud.

So what is cloud?

Cloud computing is often simply (and wrongly) defined as a way by which a 3rd party vendor hosts IT infrastructure that runs applications, instead of having the IT infrastructure owned and hosted by the company or organization using it. While sometimes true, this definition is overly simplistic and not always accurate (for example, a company could own a “private cloud” itself rather than using a 3rd party.)

For a more complete definition, we can look to the National Institute of Standards and Technology (NIST) Special Publication 800-145. According to the NIST definition, “cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” (Notice there is no mention of 3rd party providers.)

Let’s parse what that means. The NIST definition calls for five essential characteristics for cloud computing:

  1. Cloud provides ubiquitous, convenient, on-demand access. This means that cloud computing is self-service and available all of the time.
  2. Cloud provides for broadly available network access. Computing capabilities are accessible via the network rather than through hard cables, and can be accessed by any relevant client (PC, mobile phone, tablet, etc.).
  3. Cloud computing allows for resource pooling. When an organization doesn’t own computing resources exclusively for the use of specific applications, those resources become available for use by other organizations and applications. Resources can be dynamically allocated and re-assigned based on changing consumer demands. (This contrasts with the traditional model of computing resources that sit in a data center, which collect dust when not being actively utilized.)
  4. Cloud provides rapid provisioning and release of resources with minimal effort or provider interaction. When there is a sudden spike in the volume of demand for an application, it should continue to run quickly and smoothly through rapid allocation of resources behind the scenes without the need for human intervention.
  5. Cloud involves a metered paying model. Implicit in the definition of cloud is that someone has to pay for all of this. Rather than payment being for the purchase of equipment for a data center, the payment is for actual usage–usage for a number of servers, processor cores, terabytes of data, the amount of bandwidth used, or whatever else is relevant to the service.

Another thing to know about cloud computing is how it can be deployed. There are essentially three models:

  • Software as a Service (SaaS): provides functionality for end users, often with a per-license structure and with relatively minimal customization of the front end. The vendor runs everything. Gmail and Microsoft Office 365 are examples of SaaS.
  • Platform as a Service (PaaS): provides a platform upon which applications can be written and used. The vendor runs infrastructure, middleware, and operating system and you manage your own applications. Google App Engine is an example of PaaS.
  • Infrastructure as a Service (IaaS): provides core infrastructure as a utility service. The vendor runs infrastructure only; you manage everything else. Amazon Web Services is an example of IaaS.

A simple way of keeping the deployment model straight is to think of a railroad. The rails are the infrastructure, the train cars are the platform, and the products being carried are the “software” service.

Why is everyone moving to the cloud?

Cloud is often touted as the answer to reducing costs because it offers a number of benefits. The shared nature of resources means there is greater utilization and use of the computing resources you actually consume without having to pay for or maintain what you don’t use. It also offers advantages in terms of requiring less space along with the electricity and cooling necessary. It forces a simpler, more centralized management approach of computing resources. It also outsources the maintenance of commodity services not part of an organization’s core mission for things such as websites or email service. It also places responsibility for maintaining computing resources and their continuity of operations in the hands of experts who provide that service for many customers.

What does all this mean for a Business Analyst?

Consider some of the business problems that arise when we move away from a model where the applications supporting an organization’s processes reside on traditional, fully owned, dedicated computing resources.

  • How do you identify which business services and processes should be moved to the cloud?
  • Does a business really want its redundant, inefficient, or bloated processes and applications to be moved to the cloud where usage is strictly metered? If not, how do you make the identified services and processes cloud-ready?
  • What requirements, policies and governance should be implemented to guarantee performance, privacy, security, and quality of business data?
  • How will performance be measured and monitored, and by whom?
  • What kind of agreements (called Service Level Agreements or SLA’s) must be negotiated and monitored with cloud providers to ensure that the service does what it promised to do?
  • What kind of cultural challenges will arise from moving to the cloud, such as resistance to change or concern over lost jobs?
  • How will cloud applications and supported business processes integrate and interoperate with the rest of the organization’s processes that may remain on traditional computing?
  • How will legacy assets be decommissioned once their corresponding functions are moved to the cloud?

Business analysts will play a key role in addressing each of these problems and more, since nobody is better situated to pave this new path between business needs and IT implementation. It is therefore crucial that Business Analysts begin developing a cloud competency whether or not these issues have already arisen in their organizations.

There are five key things Business Analysts can do now to help prepare them and their departments for cloud.

  1. Educate yourself. There is additional NIST guidance about cloud and a lot more to know than what can be covered by this article. Learn about the different deployment models and cloud computing environments to begin understanding the possible options you could leverage for your organization.
  2. Take a holistic view of the enterprise. Now more than ever, a business analyst must take a 360-degree view of the enterprise when analyzing business process re-engineering. With cloud metering of usage, business processes must be aligned and made efficient wherever possible to eliminate duplication and waste. This happens best when the needs of the entire business are kept in mind rather than just the needs of a local business unit.
  3. Be prepared to address the issue of control in your requirements. The most burning issues for cloud revolve around control: ensuring performance of the infrastructure, continuity of operations should there be a need for disaster recovery, and security of data and application assets. Giving up the control provided by owning infrastructure assets is bound to be culturally difficult, but be prepared to explain how there are ways of mitigating these concerns to the level of acceptable business risks.
  4. Know how to measure. In a metered environment, everything about cloud comes down to measurement of performance. How much uptime was there? How fast is the application running? How much bandwidth was consumed? What is the Return on Investment of a new cloud platform? Your organization better be ready to choose, track, and report on all essential Key Performance Indicators. Many business organizations are not all that great about measuring their own performance. That needs to change before cloud computing can truly shine.
  5. Provide natural leadership. As you learn about cloud, you will become a thought leader on how best to acquire and manage it. Whether it’s implementation of SLA’s, development of cloud policies, making business processes cloud-ready, or writing cloud-specific requirements, you can be in the driver’s seat in making choices to maximize your organization’s success.

For current business analysts, the next few years will provide many opportunities for career advancement as long as skills are kept current to be valuable in the age of cloud computing. For new business analysts seeking to enter the field, there will also be more opportunities than ever to help fill increasingly critical roles in business organizations capitalizing on the advantages provided by cloud.

From The Archives: What Is An AGILE Business Analyst?

There is a lot of talk among business analysts nowadays about something called an agile business analyst. This appellation is generally applied to business analysts who work in an agile software development environment. This is a topic of discussion among business analysts throughout the industry. Courses are being written and delivered about how to be an “agile business analyst.” There is a discussion group on LinkedIn, with the title “Agile Business Analyst”. One thread on that discussion group was started by Leslie Monday, August 29, 2011, titled “What Is An Agile Business Analyst” and it is still going strong. There are at least a dozen other threads in other business analysis oriented discussion groups on LinkedIn, attempting to answer the same question, and I’m sure there are similar discussions being carried on in other communities around the Internet, and most likely in local IIBA and other business analyst organization meetings.


In some cases the discussions have a certain desperation to them because the agile community itself has in the past, eliminated the business analyst role from the agile software development process. The anti-business business analyst vitriol has been quite strong over the years. The claim has been that the developers can do their own business analysis and an extra person in the position of business analyst simply gets in the way.

In these discussions, there are those, myself included, who claim that a business analyst is, and really always has been agile. (A discussion started by Louise McDonnell that lasted several months challenged discussion members to come up with a clear differentiation between a business analyst and an “agile” business analyst.) The profession of analyzing the business requires flexibility, responsiveness, creativity, innovative thinking, acceptance of change, and a dependence on individuals and interactions. Such qualities are desired, if not required, regardless of whether the business analyst is involved with agile software development, traditional software development, or no software development at all.

So are agile business analysts “agile” because they work on an agile software development team? And if so, does that imply that those not working on an agile software development team are not agile?  I contend that in business analysis, agility is a mindset having nothing to do with the framework in which the practitioner of business analysis works. In other words, an agile business analyst is agile whether he works on a scrum team, any other agile team, or no agile team.

Let me illustrate my point by differentiating between a business analyst working on an agile team, or a developer playing the role of the business analyst, on an agile team, and an agile business analyst. Before the agilists start screaming, I am not suggesting that this is a binary or exclusive differentiation. In the annals of agile, there is a constant reference to the difference between “doing agile” and “being agile”. I am trying to demonstrate the difference between “doing agile” and “being agile” as it relates to the business analyst.

Related Article: The Agile Business Analyst: For an Agile Team, You Complete Me

We can look at an agile business analyst manifesto of sorts to describe what an AGILE BA is. You may find that the tenets of this “manifesto” apply to you even if you are not associated with anything remotely resembling agile software development. If so then you can call yourself agile for no other reason than the acronym associated with AGILE BA.

The Characteristics Of An AGILE Business Analyst


Clearly everyone associated with agile must be adaptable, since that is the essence of agility, according to the manifesto and those who promote it. However, the adaptability inherent in the agile software development approaches is focused on the flexibility required as a natural part of software development. The AGILE BA is not solely focused on software development or defining requirements for development teams. The AGILE BA defines improvements to business processes, assists decision-makers in gathering information to make decisions, helps quality assurance test solutions and products, designs user interfaces and even steps in as a product owner, scrum master, or project manager as the occasion calls for. The AGILE BA may define a set of requirements as a standalone document to outline what must be done by the organization to move to new facilities and then prepare the user stories in a just in time approach for an agile development team. The AGILE BA is not committed or bound by any specific process (software development or other). The AGILE BA is committed to solving business problems wherever they occur in the business however they may be solved. Therefore, the AGILE BA must be able to adapt to the business process, the software development process, or even a lack of process, and to any and all management directives, and not be focused on a single process or framework.

Goal Orientation

The AGILE BA’s goal is to add value to the organization by solving business problems. While the developers are focusing on producing new pieces of working software every two weeks, the AGILE BA has a focus on the overall problem that will be solved when the entire project is completed. The AGILE BA is also the weathervane indicating when a project has outlived its usefulness and is becoming a zombie project. The AGILE BA, always having the goal or the solution in front of her, is able to determine whether the project is still on track, the problem can be solved, or the problem has already been solved. This goal orientation is the result of the AGILE BA’s system thinking capabilities and the business analyst’s ability to see the big picture in addition to the detailed tasks necessary to complete the next Sprint.


While the solution development team is focusing on completing the items on the backlog in a reactionary mode to be sure that software is developed every two weeks, the AGILE BA is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists. The solution development team must follow the dictates of the product owner as reflected by the prioritized product backlog. The AGILE BA challenges the business manager, sponsor, problem owner and users to define the real business problem behind the expressed “needs” to ensure that the solution team is solving the right problem, and not providing the right solution to the wrong problem. Innovation requires a modicum of critical thinking that may generate conflict and change, moving people out of comfort zones, and taking risks. Such risks are not commonly undertaken when the driving force is producing releasable software every two weeks and the whole idea of the fixed timebox approach to agile software development is to create a comfortable rhythm for the development team to produce software. Breaking out of this comfort zone is not a desirable activity.


The AGILE BA is a leader providing solutions to business problems and continuous improvement to the organization. This leadership factor is not achieved through authority, but through influence and through facilitation and communication. A recent book edited by Penny Pullan, titled “Business Analysis And Leadership: Influencing Change”, written for “all who practice business analysis, whatever their job title.” Suggests that “business analyst lead through their work with stakeholders as they build an understanding of what’s needed and look to the future.” The leadership of the business analyst on the agile team is usually focused on the team and the project and the emphasis in agile approaches is on teamwork rather than individual leadership. To again quote from Penny Pullan: “while many business analysts see no need to look beyond their immediate project, outstanding ones will always have one eye on the organization they work within. They realize that, in order to make change stick, they need to understand and engage widely across their whole organization. This requires an understanding of the entire system, the ability to deal with power and politics, skills and working across boundaries of culture, and an understanding of both strategy and commercial realities.” And this defines the AGILE BA.


Throughout all the AGILE BA dealings with the business sponsor, customers, process worker’s, users, solution team, technical personnel and upper-level management, the AGILE BA exhibits empathy and understanding and provides an intermediary who is a mediator, a calming center in the midst of the storm of controversy and confrontation that usually accompanies organizational change. A certain amount of empathy is needed on an agile team in order for it to function as a high-performing team. That empathy does not have to extend much beyond the team since, as defined by the agile frameworks, there is only one business person to talk to who represents the entire business organization. The AGILE BA is thinking relationship across organizational boundaries, and indeed outside the organization, empathizing with customers, both internal and external, which includes a wide range of personalities and attitudes.

Business Orientation

Let’s face it; the agile software development team is focused on the technological issues of producing working software every two weeks. Granted, this working software must be oriented toward the business because it must produce value to the business, but many agile teams depend on the Product Owner or similar role to provide the business justification so they can focus on the production of software. The AGILE BA is unashamedly business oriented, thinking continuously about what can be done to improve the business and the business processes which drive the business. The AGILE BA is thinking about what the business needs to do to solve the business problems in addition to what the solution team needs to do. The AGILE BA is as comfortable talking to senior executives about business matters, the marketplace, and competition, as to the development team about user stories.


In a timebox driven, delivery focused agile process, the general guideline is to not plan more than one or two iterations ahead. As Jim Highsmith advises,” The agile approach assumes that the project plan is fundamentally irresolvable past a very simple approximation. There is no amount of information that will provide the resolution to the project issues beyond that point”. And that point is generally two – four weeks and within the somewhat narrow focus of the project itself: the system and the features or functions being developed. The AGILE BA is completely familiar with the problem domain, the business area in which the problem exists and is able to anticipate positive and negative impacts to other areas of the organization. However, the solution should be the best for the whole organization, and not just a particular business area. Therefore, the AGILE BA has to retain enough independence to evaluate potential solutions based on the overall impact to the organization rather than the influence of the particular business area and its managers. Solving a business problem solely for the business unit might have immediate benefits; solving a business problem from the perspective of the whole organization brings much more lasting value.

So there you have it, a clever acronym to distinguish what an agile BA is. And, as mentioned earlier, to many business analysts following the tenets stated above, the words “AGILE BA” could be replaced by “business analyst” because the tenets define the job of analyzing the business, or being a business analyst, whether agile or not.

Don’t forget to leave your comments below.


Pullan, Penny and Archer, James, “Business Analysis and Leadership: Influencing Change”, Kogan-Page Limited, 2013

Highsmith, James, “Agile Software Development Ecosystems”, Addison-Wesley Publishers, 2002

Requirements Inspiration From a Surprising Source

Last year, while studying for the certification exam, I started to see everything in CBAP terms. Cookbook? Requirements document. IKEA assembly instructions?

Functional requirements with process diagrams and mock-ups. 10 Commandments? High level requirements. And so on.

In my spare time, when I wasn’t trying to learn the 34 commonly used requirements techniques or all the task inputs and outputs, I would relax by knitting. I am a serious knitter who takes classes to improve my skills when time permits. A few years ago, attended a 2-day workshop titled Japanese Pattern Boot Camp (really!) to learn how to read those intricate and innovative Japanese knitting patterns that are rarely translated into English.

I wasn’t sure how the workshop could teach me how to read a pattern written in the logographic system of kanji, but I was utterly delighted to learn that Japanese patterns are among the most ingenious and concisely written requirements documents imaginable.


Here is a sample Japanese sweater pattern from Pierrot Yarns which has kindly permitted the use of their pattern in this article.

Requirements as a knitting pattern

Since most of you are most likely neither knitters nor literate in Japanese, let me point out the many admirable characteristics of this requirements document.

HIGHLY VISUAL. As you can see, a Japanese pattern is short on words but long on graphics, unlike English language patterns which tend to be just the opposite. This single page contains the entire pattern. In contrast, this pattern could easily take 3 or even more pages if written in the older style of , English pattern writing.

{module ad 300×100 Large mobile}

So, what do these graphics represent? Anyone who has ever made a garment would recognize that the top 3 diagrams represent the back of the sweater, 1 side of each front, and a sleeve. The bottom 2 charts show the pattern stitches used when actually knitting the garment.

UNIVERSAL MODELING LANGUAGE. How in the world is anyone to know what the squiggles in those charts mean? There is a standard set of symbols (a knitters alphabet, if you will) that are universally understood. Furthermore, there is a common understanding of how to follow a chart. While in English, we read from left to right and then top to bottom, knitting charts are meant to be read bottom to top and tracing from right to left and then back again. That may seem bizarre to you, but this is the standard way that knitters read charts the world over.

Related Article: A Process Approach to Requirements Gathering

IMMEDIATE TRACEABILITY. On the diagrams of the pattern pieces (top row), you’ll see that there are (a) numerical notations, (b) arrows, (c) the letters “A” and “B” and (d) vertical and horizontal bars with lines through them. The arrows indicate whether the section is to be knitted from the top down (↓) or the bottom up (↑). The “A” indicates that the stitches in the chart labelled A (i.e., the one on the left) should be used in that section. The sections with a “B” in them should be knitted with chart B.

The bars at the top and side show the finished measurements in centimeters of each specific section of the garment. The beauty is that the since the requirements are noted next to the relevant area, there’s immediate traceability between the requirement and the relevant portion of the diagram. No need for a traceability matrix!

CONSISTENT USE OF STANDARD NOMENCLATURE. It’s possible to figure almost everything out without tackling the Japanese characters, but they’re not completely avoidable. Fortunately, there is a very well-defined, limited vocabulary of knitting terms that are used consistently across all patterns. Using the single page of terms in this Japanese-English Knitting Dictionary, one can decipher just about everything on a pattern.

STANDARD COMPONENTS OF REQUIREMENTS. Even using the dictionary linked above, it would still require an enormous effort to search through the page for every character on the pattern. Happily, that is not necessary since there are standard components of information presented in a standardized layout. At the beginning of every pattern, there’s always

  • a list of required materials (i.e., inputs): yarn amounts and fiber, needles of a specific size, possibly buttons or trims
  • the gauge of the stitches. Gauge is the number of stitches and rows per inch you should achieve
  • measurements of the finished garment (key indices, so to speak): chest circumference, sleeve length, body length, etc.

Knowing what to look for limits the vocabulary to be searched, and just helps one get oriented

“JUST ENOUGH” DETAIL. Japanese patterns do not provide any more detail than is absolutely necessary, and assume you have a certain base of knowledge with which you can fill in the blanks. All that is provided are the key requirements needed to produce the final product.


Probably only a few of you are knitters who will be inspired to start using Japanese patterns. However, I think that there are several principles that can adapted to improve our requirements documents.

  1. Use visual models to facilitate understanding . Process flows, context diagrams, data diagrams, and other models can effectively and concisely convey requirements more succinctly than pages of text. This is particularly valuable when working with team members who are not native English speakers. I highly recommend Visual Models for Software Requirements by Joy Beatty and Anthony Chen to learn about different models, how to construct them and where each type of model is most appropriate.
  2. Define your terminology and use it consistently. Do not alternatively refer to a business unit as a “group”, a “team” and a “department.” Those terms may be synonyms to you, but they may mean very different things to your audience. Ideally, maintain a glossary used by different areas, so everyone starts adopting the same nomenclature.
  3. If possible, annotate your diagrams with helpful information or links to the relevant enumerated requirements elsewhere in your document.
  4. Consistently use a standardized format. Many organizations already have a standard template, and that’s because it enables readers to find readily what they need to know
  5. Provide “just enough” requirements at the appropriate level of detail for your audience. You may have to go through several iterations to ensure that everyone has the information they need.


1. “98-3 Lace Cardigan,” © Pierrot Yarns (Gosyo Co., Ltd), accessed 23 March 2016,
2. “Japanese-English Knitting Dictionary”, accessed 23 March 2016,
3. Joy Beatty and Anthony Chen, Visual Models for Software Requirements (Redmond: Microsoft Press, 2012).

The A in BA

According to IIBA, business analysis is defined as “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders”. This is what a BA is and should be. However, in most places the role of a business analyst is confined to just two words in the definition – “defining needs”.

The others are given a short shrift. Whether this is by choice or due to a lack of confidence in the skills of a BA is unknown. Probably we as BA’s are to be blamed partly for this. Many of the candidates I interview for positions in my organization also have a narrow view of what a BA must and should do, and this is confined to eliciting and documenting requirements. Many do not address the most important job of a BA – the “A” in BA. A thorough analysis of a problem statement leads to identification and recommendation of the best solution for an organization, deliver value to stakeholders and thus provide complete justice to the definition of business analysis.

It is extremely difficult to explain analysis in its entirety in this article but let me attempt a synopsis.

{module ad 300×100 Large mobile}

So what is analysis? According to Merriam-Webster dictionary, analysis is “a careful study of something to learn about its parts, what they do, and how they are related to each other”. More importantly the plural of analysis, analyses, is defined as the “separation of a whole into its component parts”.

Now, that looks familiar. As applied to business analysis, it is the separation of requirements into their functional component parts aka functional decomposition. Besides being part of a BA’s job, why is it necessary for us to analyze? Why is it necessary for a BA to break down the requirements into their components?

As the saying goes “the devil is in the details”. Not focusing on the details or focusing too much on narrow details without considering the impact on upstream and downstream systems is a sure-fire recipe for disaster. Many projects fail for one or both reasons. Once the time for analysis has passed it is difficult, nay impossible, to analyze at later stages of the project when the focus must be on DDT – Design, Development, and Testing (not dichlorodiphenyltrichloroethane, it is banned). During such crunch situations, people resort to the ‘next best thing’ – assumptions – and it is downhill from there.

Projects typically require large financial investments, and it is important that we do not miss on the material details that could boomerang in the testing phase and blow up in the face. Whether it is waterfall or agile, analyzing requirements is very important, i.e., breaking down the requirements into their components so that the scope is well defined early on in the project lifecycle. This ultimately reduces the need for (often incorrect) assumptions later. The process of breaking down requirements into functional details is called Functional Decomposition.

As with every other thing in this world, there are people who swear by Functional Decomposition (FD) and there are detractors who feel its value is greatly overstated. To each his opinion. I fall in the first category where I believe that functional decomposition, as applied to business analysis, is a fundamental technique that every analyst must not only be aware of but should also use to varying degrees. It provides a logical sequence and a natural flow from the big picture requirement down to its components.
How to decompose requirements into its functional components?

Related Article: Cooking Up Business Analysis Success

This is a standard interview question. Two important things are required to get FD right – visualization and clarity of thought. This must be followed by validation by the business users. The level of visualization needed is a function of the maturity of the business process – the greater the maturity level of the process, the lesser the need for visualization and vice versa. Why? A matured process defines the minutest of tasks very clearly and unless there is a strong need to change it, visualization plays a minor role. The point to be noted here is that even when the processes are well-defined certain amount of visualization is necessary to identify the impact on other upstream, downstream, and peripheral systems.

What is Visualization?

It is the formation of visual mental images. You may have read about visualization in Wallace Wattle’s book “The Science of Getting Rich.” This is slightly different, at least the goals are. Given a requirement you role-play, mentally, the various tasks that a user can perform. Imagine what the end-system must look like.

Further, imagine that you are the user who will be using the system. It is called Receptive Visualization and is akin to watching a movie in your head. Here is a beautiful article on visualization in Huffington Post. The second type of visualization this article mentions, Process Visualization, is similar to Receptive Visualization. Visualization can also be seen as internal brainstorming. You can visualize jointly with others too – external brainstorming. Visualization requires business, process knowledge, and a lot of creativity. Along with visualization, you need clarity of thought.

What is “clarity of thought”?

Clarity of thought is the ability to perceive, understand, and follow a train of thought. Why is this important? Clarity crystallizes the goals that we wish to achieve. It is like writing the script or dialog for a movie. You don’t want to omit sentences that make the dialog non-sensical.

Lack of clarity often results in re-work, increased cost, delayed project delivery and, if you really make a mess of it, making it to the Gartner and Forrester’s survey of failed projects.

How to achieve clarity?

While visualizing adopt a step-by-step approach. At each step try answering the 4W’s (Who, What, When and Why) and the 1H (How). There are 2 H’s – Business and Technical. Focus on the Business How. ‘Who’ defines the actors, ‘What’ is the outcome expected of the step, ‘When’ refers to the timing and ‘Why’ provides the raison d’etre of the step. ‘How’ is used, for example, as in a calculation or formula. Ask, in your mind, the questions and put it down on paper. Revisit the steps as documented (as in the dialog above) and see if it makes sense. Now, this may seem like a lot of hard work. Initially it is, but as you gain experience it becomes second nature, and you should be able to visualize with clarity, edit mentally, and put it on paper all in one go. As you can see visualization and clarity go hand-in-hand.

In a later article I will explain this in detail.

Is it worth the effort to visualize and come up with all those innovative things? I firmly believe so, as otherwise you end up with a system that will probably be antiquated within a year or two. Of course, visualization and clarity do not come easy, and it takes plenty of experience. It is a skill that can be developed.