Skip to main content

Tag: Business Analysis

Thinking Like a Business Analyst

Written by Steve Blais on . Posted in Articles. 1 Comment on Thinking Like a Business Analyst

blais Nov26I was flattered recently during a meeting about a proposed merger when I was waxing eloquent, or perhaps ineloquent, about a review of the business processes and seeing how the business processes matched in each organization. I was suggesting a ‘pick of the litter’ approach. One of the directors at the meeting said that I was “thinking like a business analyst”. I doubt he was thinking about requirements or projects. The business analysts he probably was referring to were those who analyzed the businesses of organizations the company was contemplating merging with or acquiring. He may also have been accusing me of some negative attribute he associated with business analysts, but I took it as a complement, nonetheless. Regardless, it got me to thinking about thinking.

Thinking Fluently

The thing is that we don’t think in words, we think in pictures, images, concepts, and so forth and then translate them into words in order to communicate them. Perhaps fluency, or “thinking like…” is a matter of seeing and understanding the pictures or concepts instead of or in addition to the words. For example when you learn a second language you spend lots of time translating the words. To understand a word in the second language, you translate it first into a corresponding word in your native language which produces an image in your mind. An English speaker learning Spanish would translate “el vaso de agua sobre la mesa” into “the glass of water on the table” and then see the image of the glass on the table in her mind. A Spanish speaker would see the image in her mind immediately. When you are fluent in the second language, you are able to do the same as the native speaker: see the image without exchanging the words in your frontal cortex. Of course each of us has a different image in our heads of what a glass of water on the table looks like, but that’s fodder for another article later.

So we might conclude that if we are “thinking like” some role, or profession that we find ourselves fluent in that role, or profession, or in other words, we see the concepts and images instead of just the words. There may be other phrases or descriptions for the same thing, such as someone “getting it”, whatever “it” is, or to borrow a phrase from the current discussions of agile, “you don’t do agile, you are agile”.

Thinking like…

I think we all have roles or positions or times in our life when we can say we were or are fluent in something, other than a language. For example, at times in my life, I have felt myself fluent in several roles.

In my early years I thought like a programmer. When presented a problem. I could see the code that would be written that would solve that problem. Unfortunately, I probably suffered from what Gerry Weinberg calls the “No Problem Syndrome” in which case I was probably mentally seeing a solution in code before the problem was fully explained. Too many jumping to solutions in that way is another definition of “thinking like a programmer”.

There was also a time that I felt as though I thought like a system analyst or designer. I could see the software programs interconnecting, accessing data, and even the hardware devices on which they would reside. As an analyst I could see the pieces of a larger problem, sometimes with an inability to see the larger problem itself. As a data modeler, for example, I would think in terms of entities, relationships, foreign and primary keys, even when conducting the initial interviews with the users and business stakeholders. This, as you can imagine, resulted in some rather interesting miscommunications during the elicitation phase.

On the other hand, I was never much good at thinking like a project manager. While I had my successes in project management, there were those of my peers who could see a Gantt chart in their heads when presented with the project charter. They could mentally break down the scope into a work breakdown structure and could see the precedence network in their heads with all resources arranged and delegated amongst the tasks. I needed to go through the routine of decomposing and organizing the project with the team. I tended to think technically rather than managerially. It wasn’t ‘instinctive’ to me until I had spent many years managing, at least not as instinctive as writing code or designing systems.

Not a success guarantee, but certainly an indicator

Fluency, or “thinking like..”, is not a guarantee of success in any given profession or role. In other words, you can certainly be a success in a given role without becoming so invested in that role that your thinking is consumed by it. There is certainly evidence and cognitive behavior studies that indicate that we have predilections for fluency in certain areas. Some people have a natural ability to learn languages and the intonations and inflections that make their recitation in that language seem natural, even to a native speaker. Others struggle just to learn enough vocabulary to understand, much less speak. Similarly, some people will find it much easier to be fluent in a programming language than others. However, fluent or not, a person may be a highly successful programmer, designer, project manager, speaker of a second language, or business analyst without necessarily being fluent.

On the other hand, there is also evidence that indicates with focus, attention, practice, and intent, one can master a role, and become fluent in it, even without a predilection toward it. In the book outliers, Malcolm Gladwell suggests that one can become an expert, be fully fluent, in a role or profession by practicing that role or profession for 10,000 hours.

Regardless of whether you have a penchant for it or not or whether you are fluent in business analysis or not, you will be more successful as a business analyst when you think as a business analyst. So what does it mean to ‘think like a business analyst’?

Thinking like a business analyst

The problem with ‘thinking like a business analyst’ is that the role of business analyst is so vague. A programmer programs, she writes code that makes computers do things. A system analyst or designer analyzes problems and creates computer-based systems to solve those problems. What is the specific activity that the business analyst thinks about?

  • Requirements? Can you imagine thinking about everything in terms of requirements, as in “It is dinner time, what are my requirements for dinner?”
  • Documentation? Yes, the business analyst seems to do a lot of documentation such that sometimes his entire role seems to be about documentation, but thinking in documentation, as in “let me write down what I am going to wear to work today” doesn’t seem to be applicable.
  • Liaison or translator between the business and IT? Your thinking might run like this: “let me explain to you what is going on with this television show, dear”. No, that doesn’t quite get it either.

Since all business analysts regardless of assignment or interpretation of the position or role are problem solvers, (the business analyst’s mission: Business, the final frontier. This is the mission of the business analyst: to go identify business problems, to seek out new solutions, to boldly go where no business analyst has gone before. [1]) perhaps thinking like a business analyst is thinking as a problem solver. Sherlock Holmes comes to mind as an example. Mr. Spock is another.

We are all born with the capacity to solve problems. Many of us let that capacity atrophy as we get older for a variety of reasons, mostly cultural and social. After all, Holmes and Spock are not the most lovable of characters. If you look at problem solving thinking, you see a number of different modes of thinking that may go into solving problems.

Critical thinking is a form of reasoning that challenges thinking and beliefs to determine what is true, partially true, or false. For example, a business analyst thinking critically would question the problem statement to make sure that it is the real problem statement and not the description of a symptom before proceeding with the analysis. Critical thinking underlies the other business analyst problem solving thinking modes. Sherlock Holmes is an example of a critical thinker, constantly challenging LeStrade’s and others’ assumptions of guilt or innocence as not being based on facts.

System thinking is the process of viewing problems as parts of whole systems rather than individual occurrences. The business analyst needs to view the organization and its business processes as a system or systems within systems to truly understand the impacts of the changes to the organization that the business analyst is bringing about. There have been a number of discussions on LinkedIn business analyst discussion groups lately about the application of system thinking to business analysis masterfully led by Duane Banks and Julian Sammy.

Strategic thinking as applied by an individual involves the generation and application of insights and opportunities that extend beyond the present timeframe. While system thinking provides the business analyst the larger view in terms of breadth, depth and context, strategic thinking provides the business analyst a larger view in terms of time. While strategic thinking is not usually associated with the business analyst who typically works on projects which are tactical in nature, the business analyst, being in the center of business and IT is usually in a prime position to understand the strategic implications of the projects and products on the organization.

Analytical thinking is essential to problem solving and goes hand in hand with critical thinking. Critical thinking and analytical thinking are sometimes considered synonymous. Critical thinking is specifically focused on thinking while analytical thinking is focused on everything else. Since it is often difficult to see the complete problem or the entire situation in which the problem exists given the complexities of business and technology today, the business analyst breaks the larger picture into smaller more manageable images to make examination and understanding easier. Again, Sherlock Holmes broke crime scenes down to pieces of evidence that, when put all together, assembled a complete picture of the crime and the perpetrator. This reassembly of the evidence or the pieces back into a complete whole to determine the ‘crime’ is what allows business analysts to be both system thinkers and analytical thinkers successfully. The two modes of thinking are not diametrically opposed or mutually exclusive.

Visual thinking is perhaps the only mode that might require a bit of predilection in that some people are more visual than others. But this thinking mode brings us all the way back to the initial premise that we don’t think in words, but in images and concepts: visions. To the degree that we as business analysts can visualize the problem and solution and describe that vision or render the vision into graphical form is the degree that we will be understood in our efforts to communicate.

Now that I think about it…

Thinking like a business analyst might be simply thinking first:

Thinking before reacting,
Questioning before accepting,
Verifying before assuming,
Understanding before judging,
Viewing the whole process before focusing in on the detail issue,
Analyzing before concluding,
Visualizing before writing.

While we as business analysts value the activities on the right hand side we value the activities on the left side more (to paraphrase the Agile Manifesto). Thinking like a business analyst may simply be a matter of reasoning about problems, visualizing solutions, and asking more questions.

Don’t forget to leave your comments below.

Get Support from the Grumpy Old Man

Written by Angela Wick on . Posted in Articles. 1 Comment on Get Support from the Grumpy Old Man

wick Nov12How would you “caricaturize” your organization?

We’ve all been to a fair or festival and watched caricature artists draw distorted people with giant cartoon-like heads and exaggerated features.
If you made a caricature of your organization, what would it look like?

Here are two extreme organizational caricatures:

Grumpy Old Man

  • Picture Andy Rooney’s bushy eyebrows, a cigar, a scowl and an iron fist.
  • This organization is set in its ways, not open to change, fixed in routine, dictatorial, risk averse, backward-thinking—what worked in the past will continue to work.
  • BAs in this environment might have strict procedures, many required templates, limited flexibility and a clearly-defined hierarchy.

Fearless Toddler

  • Picture a wide-eyed, smiling and wobbly 12-month old, touching and tasting everything without concern for consequences. Each day is a series of experiments with repeating cycles of attempts, failures, learning and trying again.
  • This organization values experimentation, rewards risk, and is forward-thinking—what’s next and what’s new.
  • BAs in this environment might be required to define their own roles and procedures, with few internal rules and minimal structure. Priorities might change frequently.

Which caricature describes your organization?

How does that impact your ability to get the support you need to try new tools and techniques?

The Fearless Toddler would welcome your experimentation, but how do you get support from the Grumpy Old Man?

Here are a few ways to help your Grumpy Old Man open up to new ideas:

  1. Cross-Team Training

    In many organizations, stakeholders don’t really understand the BA role. The right team workshop can help everyone appreciate possibilities and benefits of effective elicitation, analysis, issue resolution and prioritization processes

    This strategy exponentially increases the value of training because resistance is minimized and BAs have the support they need to help their organization move forward.

    Something magical happens when BAs, PMs, QAs and SMEs learn new skills together. At one of my client sites, BAs were happily overwhelmed when their business managers pushed them to try four new techniques just days after they all took BA training together.

  2. Take Baby Steps

    Start small. Figure out a way to apply new ideas in phases. Find a way to fit new techniques into current procedures. Start with techniques that are a simple expansion of current practices.

    If you have a new facilitation technique you want to try, practice it in a low risk meeting with a small group of friendly stakeholders. Ask for honest feedback.

  3. Ask permission

    Many people will tell you “it’s better to ask forgiveness later than ask permission now.” However, in some organizations it is not appropriate to try new techniques and tools without approval from a leadership team. In this case, you may need to follow a formal process to introduce new ideas.

    Even in less-structured organizations, a simple request process might maximize cooperation:

    1. Choose a new tool or technique.
    2. Submit a brief proposal to key members of your organization.
    3. Describe the benefits of the technique, your implementation plan and how you will report the results.
    4. Make sure you include any benefits that save time, reduce cost or minimize risk.
  4. Just do it! Take the risk and try something new.
    1. Prepare well, be confident and be willing to fail.
    2. Set expectations. Let people know that you plan to try something new.
    3. Use time wisely and give stakeholders a way to provide feedback.

    Whether you succeed or fail, you’ll learn something valuable about yourself and about your organization. Maybe you’ll learn that your organization is not as grumpy and old as you thought or you’ll learn the old process worked better. You might find support and flexibility or you might find a brick wall. Use your findings to inform future choices and experiments.

  5. Share expert opinions

    Sometimes you need a third party to help you advocate for change. You could hire a team of consultants. But if your budget is limited, find expert resources online. Find articles, videos, and other resources.
  6. Build your base

    Float new ideas, one person at a time, during lunch, after meetings, at happy hour, in the elevator and by the coffee pot. You will find support.

How do you get your stakeholders wide-eyed and smiling? How do you build support for new tools and techniques in your organization? Please leave your comments below.

Don’t forget to leave your comments below.

The Innovative Business Analyst

Written by Tim Coventry on . Posted in Articles. 1 Comment on The Innovative Business Analyst

Many people talk about the importance of business processes without identifying the true value to an organisation. We hear often about Business Process Management (BPM) however I see that many of these initiatives forget about the business need and get carried away with the mapping of business processes or focus on the notation correctness. Instead I often talk about “service/product and business process driven requirements.” What do I mean? Well this is when a Business Analyst (BA) starts with understanding the business process for a service or product in order to elicit the business requirements. Why is this important you ask? Well correctly structured business process driven requirements focus on the business need, as all organisations, for profit, government or even a “not for profit,” exist to deliver services or products or both to customers. These services and products are inevitably delivered through business processes, people and technology. Therefore it is critical that the BA always considers business process within their analysis to discover the business need, related to the delivery of services/products.

Often it is said that a BA should concentrate on the “why” not the “how,” which is true initially however, at a more detailed stage it is necessary to solve the how to deliver the outcome. Instead of saying a BA should focus on the “why” I prefer to say a BA should focus on what is the “service or product” we are delivering within the scope. Inevitably the discussion will soon include the processes and business functions required to deliver the service or product, which is the why.

I have experienced that stakeholders often have the “how” already in mind, “I went to a conference last week and received a demo of xyz software and I’m sure it will solve all our problems” this probably sounds familiar! I call this the “butterfly syndrome” where stakeholders focus on the pretty butterflies flying around the room rather than the service or product delivery. In this situation I quickly acknowledge that xyz software could be the answer but suggest we perform our due diligence to confirm so we don’t waste time and money. How about we start with the services and products where the problems exist? That way we can solve the problems and identify opportunities for improvements while we look at xyz software. This can be done irrespective of our choice of SDLC methodology (e.g. Waterfall, Agile, Iterative).

The first question I ask is “what is the service or product we are delivering within the scope?” Normally I already know the answer to this question through the usage of the BABOK technique Document Analysis that allows me to determine the answer before I engage the stakeholders. Great sources of this information are company websites and glossy brochures as these hopefully clearly outline the services or products offered by the organisation. Next I like to understand the services and products within the scope of the initiative or project, and determine whether these are supportive activities (necessary but non-value adding) or direct value chain activities (value adding).

 
coventry nov12

Typically I use a value chain similar to the Porter’s generic value chain to focus my understanding of how the scope fits into value adding and non-value adding activities. If the activities are value adding it is easy to link them to the services and product delivery. Non-value adding but necessary supportive activities are more challenging to identify the linkages to the services and products however connecting the dots can be exhilarating.

I learnt the usefulness of this technique when working in a healthcare environment when I was asked to work on a project that had identified the need for a new Human Resource IT system. When I started to analyse further I discovered the organisation had a problem with recruiting enough nurses, as frontline and regional patient services (value-adding service) were under resourced to produce a suitable customer service. Around the world Human Resource business units (non-value adding but necessary supportive business function) perform five business process patterns; Strategic Human Resource Planning, Recruitment, Retention (includes learning and development), Redeployment/Retirement and Employee Management (includes payroll etc) so typically a new Human Resource IT system would cover all of these five processes. However in this instance the problem was only in one area “Recruitment” and so I suggested that we focus our attention (scope) to fixing the problem affecting the value adding service hence reducing delivery time and costs. My initial suggestion of analysing the cost/benefits of employing temporary staff to handle the recruitment peaks using existing processes and technology did not resonate well with the stakeholders. So the project team concentrated on delivering a technology solution to improve the recruitment process. In the end, the recruitment workflow technology solution provided better business value than a “butterfly syndrome” new Human Resource IT system.

Innovation – businessdictionary.com: The process of translating an idea or invention into a good or service that creates value or for which customers will pay. I think the BA role provides the greatest opportunity to lead and influence stakeholders to make more informed business decisions, assisting organisations to become more strategic, flexible, customer focused and innovative in delivering services and products.

Don’t forget to leave your comments below.

It’s Time to View Your Role as a Communication Expert

Written by Kupe Kupersmith on . Posted in Articles. 2 Comments on It’s Time to View Your Role as a Communication Expert

kupe Oct29I teach a class on applying improvisation skills that focuses on how to be a better team player, collaborator and communicator. I start the class off by asking people what skills they need to be effective in their role. In this session people generally say communication skills, problem solving, negotiation skills, influence, teamwork, etc. Many of the underlying competencies in the BABOK. They also bring up the multitude of techniques familiar in our community like use cases, user stories, impact mapping, context diagrams, workflow diagrams, etc. In my last blog post I argued that decision making was not an underlying competency it was what a business analysis professional does. In my classes and here in this post I argue that the same applies for communication skills.

As I was formulating my thoughts for this post I attended a Greater Atlanta IIBA chapter meeting where a panel discussed communicating to executive level employees. My friend and BA thought leader Jonathan Babcock made a statement that resonated with me. He said, in so many words, BA’s need to be great communication experts. I was so moved I almost gave him a standing ovation.

You need to view your role as communication expert. Your goal is not to complete a template, your goal is not to document Use Cases, your goal is not to help groom a backlog. You goal is to have the necessary stakeholders involved in your initiative gain a shared understanding of the problem and how to go about solving that problem. It’s that simple. The tools and techniques are there to help you communicate. They are not what you do.
Other professions, not yours, have communication as an underlying competency. For example, a plumber. Their main competency is plumbing services. Their goal is to get water from point A to point B without any leaks (over simplified, but you understand where I am going). Their main role is not communication. Yes, they have to communicate with other team members and a homeowner, but it is truly a secondary competency.

Communication challenges are at the core of why in our profession best practices are not always the best practice. Being a communication expert means you are communicating with individuals. Every individual is different. Everyone has their preferred communication style, their own information needs. So when someone says I have a requirements best practice you can’t assume it will work for you and your team. That practice was the best for their team. You need to understand what works for your team and your situation. Now don’t stop learning from others. Just use other people’s experiences to help come up with your approach.

In our community waterfall vs agile is a big topic. This comparison and these conversations are masking the real issue. If you have the mindset of communication first, nothing else matters. Regardless of methodology used you add value to your team by helping gain that shared understanding. Do what is necessary to gain that. New techniques or new uses for existing techniques surface all the time. Use them to help you communicate.
When you view your role as a communication expert you will start to see how to identify when you have done enough analysis. Knowing when you have done just enough analysis is not when a technique is complete to a certain level of quality. You know it when you have communicated clearly and there is a shared understanding. When that goal is reached you are done. There is no silver bullet here. If everyone on the team is very familiar with the business area and problem to be solved it may happen faster. If the problem and solution are complex and there are new team members it will take longer.

Without being able to see your faces or ask you directly I am going to assume we all have a shared understanding. If not, let’s continue the conversation in comments below.

All the best,
Kupe

Don’t forget to leave your comments below.

The Business Analysis Profession has no Principles!

Written by Steve Blais on . Posted in Articles. 1 Comment on The Business Analysis Profession has no Principles!

We business analysts often complain and wring our hands over the lack of respect we get as a profession. We debate what we are and what our profession is and does. Why don’t we have the respect that the medical profession has, or architecture, or even software development? Why don’t we get the same respect as lawyers and politicians…well, maybe we don’t want to go that far.

What have they got that we don’t have?

Recall the end of The Wizard of Oz. The Wizard granted everyone’s wishes, but in a way that was not the magic that was expected. He gave the Lion courage by vesting him with a medal. And he gave the scarecrow brains by giving him a piece of paper bestowing a degree. Upon receiving the “degree” the scare crow immediately spouted some brilliant equation showing that he suddenly had brains. The Tin Woodman was given a “heart”.

Suppose what makes a profession is simply a series of accoutrements such as a Manifesto or a Bill of Rights or a set of Principles? After all, doctors have the Hippocratic Oath. Politicians have the words that they agree to when they are sworn in (defend and uphold…). Lawyers have…well, they have something. Agile software developers have the Programmer’s Bill of Rights written by Ron Jeffries.

So I propose that we have some statements of purpose and goal and principles that will govern and guide our profession. 

Since a Manifesto seems to be the rage nowadays, let’s start with a Business Analyst Manifesto. This Manifesto was created by Laura Brandenburg 

Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve. [1]

Doug Engelbart a computer pioneer and inventor of the mouse among other innovations, may contribute our statement of purpose (paraphrased):

The business analyst increases the capability of the organization to approach a complex problem situation, to gain comprehension to suit the organization’s particular needs, and to derive solutions to problems.

I might add a Bill of Rights and Empowerments that I posted several years ago: [2]

As a business analyst you have the right to:

  • Ask questions
  • Understand the problem and problem domain first
  • Make sure you are solving the right problem
  • Challenge the business
  • Challenge the solution team (to explain why they are choosing to solve the problem in a certain way)
  • Come up with solutions
  • Define the problem domain
  • Solve the problem

As a business analyst, you are empowered to:

  • Ask questions
  • Challenge the norms, the “way things are done” both on the business side and on the development side
  • Try new techniques, methods, and processes to perform your job
  • Suggest new methods or ways of executing business processes in the organization
  • Analyze instead of accept
  • Get and understand information first before committing to a solution
  • Ask more questions
  • Do the good quality job for the organization as a whole instead of only individual organizational entities
  • Define and solve the business problem

While these are three years old, they still apply to today’s challenging environment, and are perfectly applicable to an agile development approach as well.

Finally, we should have some principles or guidelines to follow, some large scale best practices which unify and coalesce what we do. I submit that we can collectively perhaps assemble applicable principles amongst us. I will humbly step into the gap with some principles that might be adopted:

Principle 1 – Focus on the Product

The business analyst focuses on the product not on the project

Understand what a solution is worth to the business

While the project manager focuses on the project to make sure that the project is on time, within budget and delivers everything required, the business analyst focuses on what is to be delivered to make sure the real problem is solved and there is a discernible benefit to the organization when the project is complete. 

Principle 2 – First Define the Problem and Then the Solution

Paraphrasing Davy Crockett: Be sure you know what the real business problem is and then go ahead.

Too many times business analysts assume that a statement given to them by the business is a problem when in reality, the business provides a solution. That solution may not be the most efficient or effective solution; in fact that solution may not even be right. And when the business complains that their problem is not solved even though you implemented their solution, you will likely be blamed for the failure. Spend the extra time up front to make sure that you are dealing with the real problem that needs solving. 

Principle 3 – Users Do Not Have Requirements

Users do not have requirements; stakeholders do not have requirements – they just have information The business analyst seeks that information and analyzes it to produce the solution document containing the requirements.

Starting with the assumption that the requirements only exist when the business analyst analyzes them into existence is a good starting point for solution development. Taking the opposite assumption – the users know exactly what they want and what the technology can do to solve their problem – is a recipe for long meetings, continuous turmoil and change, and consistent conflict resolution. 

Principle 4 – Focus on Information Not Individuals

The problem in elicitation is not finding the right individuals to talk to; it is finding the right information regardless of source. 

Too many times the business analyst is told to go get the requirements from certain individuals. Those individuals may not be available or may not know they are supposed to be the repository for all answers. Sometimes Subject Matter Experts aren’t. The best approach for the business analyst is to determine what information the business analyst needs so that the business analyst understands the problem and can create a solution, and only then determine where that information is located. If some individuals cannot be accessed, most likely the information still can be acquired through other sources.

Principle 5 – Separate Elicitation from Analysis

When eliciting information, do not analyze; when in analysis, do not create information.

When you analyze while gathering information the responders interpret the analysis as judgment on the information provided or on themselves. This stems the flow of information. To keep the information flowing, keep the judgment and analysis out of the interchange. 
Similarly when you are analyzing the information, and you add new information not obtained through elicitation, you are making assumptions about that information. You are weakening your analytic conclusion. Turn any supposed information not based on elicitation or deductive conclusions into questions that require further elicitation.

Principle 6 – Improve the Process First then Add Technology

Evaluate non-IT solutions first before resorting to computers and software to solve the business problem. Focus on the business, and how IT can be used to improve and enhance the business’s status quo

Constantly review and appraise the organization’s processes and operations to determine where changes can be made that will add value to the organization

Our job, as business analysts, is to add value to the organization by solving business problems. Suzanne Robertson puts it this way, “The job of a business analyst is to identify what people need so that they can improve the way that they do their work and to communicate those needs to people who can implement solutions”” [3] In other words, determine what will make things better for the business then determine what the technical solution might be, if any.

Principle 7 – Do not let documentation substitute for communication and collaboration

Requirements describe the solution to a defined, understood and approved business problem

Over the years the emphasis in the requirements process of software development has been on the production of a requirements document. Whole business analyst teams have been organized around the creation of said document. It becomes a project is and of itself. And while it may well be a good idea to treat the definition of the solution as a project, it is not a good idea to replace solid communication with a document. Remember that the document should be the recording of all the communication that has occurred beforehand, not the communication itself.

Principle 8 – Gain Acceptance before you gain Approval

Acceptability of a solution is not the same as approval of a solution. There are different dynamics at play.

All sorts of problems occur when the person who has the authority to approve is in the same meeting as those who need to confirm that the solution will work for them. Separate the confirmation or verification process from the approval process. Get the solution definition confirmed by those who are eventually going to use the solution in real life: “Yes this will solve our problem!” and accepted by those who are going to implement the solution: “yes, we can do this within the project constraints!” before passing the solution to those who need to authorize the funds or resources to implement the solution.

Principle 9 – Make Sure the Business Community is Ready for the Product / Solution 

The business problem is not solved until the solution is being used in the business environment. 

You can have the best solution, a Nobel Prize winning solution, and have it never used because the business people who have to use it don’t use it for whatever reason. Perhaps they are not ready for it. Perhaps they really like their work-around. Perhaps they have had too many changes in the recent past to be able to assimilate this one. The business analyst needs to lead the Transition from the current process to the new, improved process. Not only does the business analyst need to make sure that the new process and / or system is ready for the users, but that the users are ready for the new process and / or system. 

Principle 10 – Communicate, Cooperate, Collaborate

Keep communications flowing in all directions

Live on the Feedback

Above all, communicate. Never let a day go by without an interesting discussion or provocative dialog. Turn conflict into cooperation. Turn contention into collaboration. Eliminate uncertainty and risk by the exposure of new information.. Never be a bottleneck of information. Learn. Teach. Spread the information and expand it. Know more today than you did yesterday

So there are ten principles to start our Principles of the Profession. I am sure there are more that you can think of to add to our list.

Don’t forget to leave your comments below.

[1] Brandenburg, “The Business analyst Manifesto”, Bridging the Gap, 12/17/2009

[2] Blais, “Business Analyst Rights and Empowerment”, Bridging the Gap, 4/29/1020

[3] Pullman & Archer (ed), Business Analysis and Leadership: Influencing Change, Kogan Page, Ltd, London, 2013