Project Management

How Important is it to Become an Advocate for Business Analysis?

From the Building the Foundation: The BOK on BA Blog
by , , ,
A new collaborative blog featuring the contributions from the core team members of PMI's Foundational Standard in Business Analysis. This blog will provide the community with insight into PMI's development of the standard to generate professional discussions about the content in advance of the scheduled reviews.

About this Blog

RSS

View Posts By:

Laura Paton
Joy Beatty
Cheryl Lee
Sue Burk

Recent Posts

PMI's Newest BA Standard and the PMI-PBA Credential

An Update On PMI's Consensus Based BA Standard: The Final Phase

The Link Between Business Analysis and Project Management Processes

Party Like a Business Analysis Rock Star!

PMI’s Business Analysis Standard – What You Have to Gain

Categories

BOK, Business Analysis, business analysis, business analysis BOK, business analysis BOK PMI-PBA, business analysis guide, business analysis standard, PBA, PMI-PBA

Date


Categories: Business Analysis


Very important! As Cheryl Lee said last week, “Business analysts (BAs) are sometimes seen as the annoying siblings who ask a lot of silly questions that hinder progress on projects. Organizations are sometimes unsure on how to leverage business analysis in order to deliver successful outcomes.” 

Let’s face it, business analysis is an aspect of initiatives that sometimes gets shortened or skipped. It’s not that business analysis is unimportant; some just believe other work is more important.

Finding some root causes

So why does this happen? Those of us who already know the value of business analysis do not need to be convinced. PMI’s Pulse of the Profession In-Depth Report on Requirements Management tells us that the #2 reason why projects fail is poor requirements, where most business analysis is focused. Many of us (project managers, business analysts, testers, trainers, developers, etc.) understand how important business analysis is. So, are there just too few of us? 

I recently went to a meeting on land conservation, where the very inspirational keynote speaker, Dr. M. Sanjayan, had a wonderful message from which we can learn. 

To summarize, he said, as an advocate for a cause, be careful that you’re not just talking to others who are already convinced. Instead, focus on those who do not yet care as much. Help them know why—from their perhaps skeptical perspective—it is in their best interest to care.  Dr. Sanjayan used an interesting turn of phrase—rather than “how we can save nature”, he focused on “how nature can save us”.

So I would say we also need to direct our message to those who are not yet convinced about the importance of business analysis and frame it in terms which directly impact the folks to whom we are speaking.  Promote the idea that business analysis is not just “nice to have”, but rather “something you can’t be without.”  

So what can YOU do?

Here are a few ideas, hoping that you have more to share ::-)  (No, that’s not a mistake in my smiley; mine always wear glasses ::-)).

  • Consider setting up a forum so that those who already know the value of business analysis can share ideas and experiences.Brainstorm a list of folks who need to learn more about the value of business analysis and what topics would be of interest to them and invite a wider audience to the forum.
  • Set up a fun in-person or virtual event where folks can try business analysis techniques on non-work problems to see how business analysis can clarify ideas. Visual modeling techniques are particularly appealing. For example, how about a process model for how to coordinate a trip by your hiking club? Or a little data model to structure the information kept about your book club?
  • Have a presentation or roundtable discussion at a local PMI chapter about how BA/PM collaboration can support successful project work. For ideas, check out the collaboration points in PMI’s Business Analysis for Practitioners: A Practice Guide (free for PMI members to download!).
  • Cheryl created a wonderful BA Community in her Ontario PMI Chapter.  You can do the same in your chapter and invite people inside and outside the chapter.
  • Set up an executive forum where executives can learn from a speaker to gain more top-down recognition and sponsorship for business analysis.One of the agile user groups to which I belong has a yearly executive half-day meeting where executives present to executives. One attendee recently reported that his exec immediately latched on to what the presenter provided and went on to convey the message to all of his reports.That’s powerful stuff!

Your thoughts? What topics would you suggest to advocate for business analysis to the as-yet-unconvinced? Looking forward to learning from all of you ::-).

Posted by Sue Burk on: April 22, 2016 06:27 AM | Permalink

Comments (21)

Page: 1 2 next>

Please login or join to subscribe to this item
avatar
Rolf Dieter Zschau Senior Head of Business Analysis| Volkswagen Group Charging GmbH Unterschleissheim, Germany
Thank you for sharing that view. I'm trying to advocate in the small world of my company. I started to tell everyone, it's important - that didn't reach much attention. Then I started with a colleague to go into the project and start conversations about how work was going on - and showed here and there, what RE/BA can do to help ease the pain. This was better, but very high workload for us two.
So we started to offer starter teaching lessons as "appetizers" - we got support from top level management to urge new colleagues into the classes and some other, that were interested from our second phase of promoting. This helped to start the fire, but prove is still open if that will last. Currently we merge internal PM training and our RE starter training so every new PM will get at least some initial insight. First class will start in June.

avatar
Rolf Dieter Zschau Senior Head of Business Analysis| Volkswagen Group Charging GmbH Unterschleissheim, Germany
Addition: I got one of our department managers into PBA "fire". He runs a department that works on new mobility models and business models in that area - until now with good success, but following their own trial and error methods. As he's PMP, he heard about PBA and we had a talk - he got a glance into BA Practice Guide and got fire: That's what he was looking for as a guide to work more systematically. Now he plans to go for PBA and promotes that to other people too.

avatar
RMA GOYAL PM Consultant| Self Fl, USA
Business Analysts are a blessing for the PMs. Effective requirement gathering can lead to smooth execution of the projects.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
First, thank you very much for sharing. But please, I firmly believe that we need to make reference to "project" when we talk about business analysis. Business analysis exists before a project exists and ends after a project ends. I know we are inside the project management framework but if the PMI wants to add value to business analysis we need to avoid the reference to business analysis framed to project management. (continues...)

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Second, English is not my first language. So, I went to the english dictionary. I took Collins dictionary (sorry if it is not the best one) and I found the definition of "advocated". I found "proponent, supporter or defender". If that is right then I fully disagree with that. You do not need to propose, support or defend business analysis. Business analysis is performed from the very begining when the organization needs to solve a business problem that emerges when needs of change emerges because a change into the organizational environment (external and internal). What we need is to make that visible. In my humble opinion one of the reasons because lot of organizations does not use project management is because of that. Lot of people try to be an "advocated" or project management (for lot of reasons) and the only thing they get is to increment the resistence. We need to avoid the same with business analysis. It is nothing to support or defend. It is a matter to make it visible and valuable.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Sorry, in my first post, I made a mistake. I´d like to say that I firmly believe that we need to stop to make reference to "project" when we talk about business analysis.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
On the other side, and with all my due respect, we need to understand that business analysis is not about requirements. Business analysis is about solutions. And here comes the Conte´s equation (hehehehe): Solution is EQUAL "the thing" (product/service/result) to be created PLUS "the process" (project/program) to create it. Because of that, business analysis focus is to find business needs, to transform them into requirements to help subject matter experts to define the solution, create the solution and put it in place, and to continue monitoring if expected and stated results and benefits are reached.

avatar
Liz Thackeray Schenectady, Ny, USA
Originally, my business 'Title' was 'Liaison'. It was my function at the time to ensure that the stakeholders involved (whether PM, Business Management, SMEs, Technical leads and developers, Customers, or Consultants) shared the same picture of whatever solution was to be developed or implemented. I actually devoted a considerable portion of my working years to gaining technical boots-on-the-ground experience to enhance my technical knowledge to the point where I am able to communicate effectively with technical stakeholders.



I have had some very unsettling experiences working with today's BA perspectives. There is a lot of confusion generated because the common ground that I believe BAs need to establish is generally ignored by those BAs that I have worked with. Sometimes this can be written off to 'Politics'. Sometimes the BA sincerely believes that it is their responsibility to dictate what the solution Should be and/or How that solution should be designed or developed. Many times the issues that arise because of the involvement of BAs is due to the fact that BAs generally do not have either the operational expertise or technical expertise to dictate a solution.



I believe that the BA role is one of an analyst and subsequent advisor to those who need to make a commitment to the outcome. My approach to Business Analysis consists of gathering information to properly define requirements and ensure that the entire stakeholder group involved is on board with that definition. I have not, since taking the 'Title' of 'Business Analyst' 10 years ago, ever worked with a single BA that actually captures, communicates, or uses 'properly formed' requirements (as outlined by international standards organizations like the IEEE) effectively. And I have observed that the processes of defining requirements, gaining consensus, and using them throughout an application's lifecycle become an exercise in futility to the stakeholders involved (their perception, not mine).



I try to advocate for Business Analysis by practicing what I preach and have found that when an operational or technical stakeholder group is interested in accomplishing their goals, they request my participation. Firstly, I am an 'Analyst' - while other titles may concentrate on Financial or Security analysis, my domain is the Business as a whole. Secondly, I am a non-biased participant who will support the team's efforts and lead those efforts when needed. Finally, I am able to gain respect for my work by clearly communicating the impacts, risks, and expected outcomes that are solidly based on the results of my analysis so that the decision-makers can make the Best decisions to accomplish their goals. I do not dictate to anyone what they have a much higher knowledge regarding in their respective roles.



This is an approach that requires team-building, trust, respect, and communications skills - skills that appear to me to be sidelines to generally accepted BA practices. In what has been a painfully slow process, the organizations where I now work are nearing their Ah-Ha moment that (hopefully) will enable them to define the role and employ BAs in a manner that will effectively add value to projects within the Business and IT realms.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Great to read you,comments Liz. What you,describe is business analisys. No matter the title (in the organization where we are implementing it the name is bussines engagement leader). I hope PMI takes this path to define the role (I believe that after participating in the practitioners guide). Thank you very much for make me feel that not everithing is lost in business analysis diacipline.

avatar
Pravin Kumar Shrivastava Associate Vice President| Aithent Technologies Pvt Ltd Gurgaon, Haryana, India
When it comes to tight dead lines, people start ignoring Business analysts role. There is no time left so the each and every piece of work can be reviewed by BA. We need to plan these activities and add sufficient time for BA activities. BA should take the ownership of product delivered Or going to be delivered. The process should be started both ways.

avatar
Heng Tan Mannaging Consultant / Owner| Technometrics Consultancy Services Singapore
One should examine whether BA or lack of it is an issue in its own organization. Usually this should be a responsibility of the PMO, if it exists in your organization.

One things that an organization (or its PMO) should do is to apply business analytics to project management. For example, using your own project management information system to gain insights on the following:
1) Relationship of quality of requirements document and project success
2) % of effort on BA vs Project success

If insights such as the above are acquired, it becomes a natural act to adopt BA as part of organisational management decision, for more effective project management.


avatar
Rolf Dieter Zschau Senior Head of Business Analysis| Volkswagen Group Charging GmbH Unterschleissheim, Germany
Hi Sergio, I fully agree with your first Point. See my linked-in Profile...
But I don't agree with your BA vs. requirements statement. BA is much more than requirements elicitation, documentation and management but it includes that. In my opinion, the first rough requirements are the ideas which start the creation of a company or business model. Requirements are not only those that we gather/elicit when we are defining a project, process or System. Analyzing the first idea results in the very high level requirements for the company and business model. You may call it vision - but in effect it's a requirements document at very high level.

avatar
Rolf Dieter Zschau Senior Head of Business Analysis| Volkswagen Group Charging GmbH Unterschleissheim, Germany
Hi Sergio, I fully agree with your first Point. See my linked-in Profile...
But I don''t agree with your BA vs. requirements statement. BA is much more than requirements elicitation, documentation and management but it includes that. In my opinion, the first rough requirements are the ideas which start the creation of a company or business model. Requirements are not only those that we gather/elicit when we are defining a project, process or system. Analyzing the first idea results in the very high level requirements for the company and business model. You may call it vision - but in effect it''s a requirements document at very high level.

avatar
Rolf Dieter Zschau Senior Head of Business Analysis| Volkswagen Group Charging GmbH Unterschleissheim, Germany
Hi Liz, 'Liason' is a good title - my current project is formed around such work, but seen as project management by my client and my company - and not BA. But I think that's academical question. It's important work and the methods and tools I learned to be part of Requirements Engineering (IREB Terms) help to do it. BA is more than RE of IREB in that it starts earlier in the "overall process".

It's a pity that you only met BA's that try to dictate solutions. It's a temptation to do that - not only if you don't know much about the area you work in but especially if you know. To be neutral and only an advisor is difficult - and somtimes not very valued by clients ("you are the expert, you have to tell me what to do", I hear often). But I think it's essential - as you stated - to be the analyst and advisor, but not the dictator.


avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Rolf, what I tried to say is that the big mistake people do is to confuse needs/wants/desires/wishes/etc with requirements (I am not saying your statement sustain that). People do things based on that instead of transform them into requirements. Requirement is somthing well specified (it matches to quality attributes when you perform quality assurance on requirements specifications) that allows to others performing desing, contruction, implementation activities. So, we think we are in the same page. But I firmly believe that we need to talk about solutions, not requirements when we talk about business analysis. Time ago I published an article about a practical method I use that was published as best practices by the IIBA. Just in case you take a look you will see I am on line with you. Thank you for your comments
http://www.projectmanagement.com/blog/How-To-Do-Business-Analysis/15655/

avatar
Rolf Dieter Zschau Senior Head of Business Analysis| Volkswagen Group Charging GmbH Unterschleissheim, Germany
Sergio, thank you for the link. Very interesting article. I recognized that you used BA as acronym for Business Architecture in that article. Was that on purpose? For me Business Analysis and Business Architecture are different things - nevertheless interacting.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
To you Rolf. Because the space on the picture I used BA to refering to business architecture. Perhaps I do not understand the second part on your statement but the business analyst is accountable for all related to bussiness architecture. In fact, when the business analyst performs the former enterprise architecture activity (now "strategy analysis" according to the IIBA and "needs assessment" according to the PMI) the business analyst have to perform a gap analysis between actual and future business architecture. We use for years the Zachman framework (when we need to work with more detail) to describe and maintain enterprise architecture and the business analysis focus is rows 1 and 2 that describe the business architecture.

avatar
Rolf Dieter Zschau Senior Head of Business Analysis| Volkswagen Group Charging GmbH Unterschleissheim, Germany
@Sergio: Thanks for the explanation. Understood. So I have the same picture in mind. I planned to have a look on Zachman Framework - but didn't make it yet.

avatar
Mary Gorman Other| EBG Consulting Greenville, Sc, USA
Sergio, You have provided a number of interesting perspectives. Thank you.

I agree that many people are confused about needs/wants/desires/wishes/requirements!
My co-author, Ellen Gottesdiener and I use the following definitions:
"Wants" - generalized, high-level product options wanted to realize the product vision over time (possibly 2-4 years).
"Needs" - product options needed for the next release (possibly 1-4 months out).
"Requirements" - product options required, with sufficient detail to develop (in agile development, 1-3 weeks timeframe).
The options, and the related plans and estimates are increasingly detailed.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Thank you very much Mary. Please let me say, I do not find useful to give a definition to needs or wants (plese, take this as my personal opinion based on my experience and research). And perhaps because my original background (I earn a PH.D in software engineering from SEI at CMU) I fully adhere to IEEE standards and definitions or seminal works from Mr Karl Wiegers, Mr Alan Davis or Gauss and Weinberg that belongs to software but I used and adapted to any type of products.. The world of requirements is simple when you talk about what a requirement is or how you will be sure that you have a requirement on hand. I firmly believe that each person that works in business analysis need to read and to understand the IEEE Std 1233 in order to get a well formed requirement as the result or transforming all obtainable from stakeholders during elicitation to requirements. That´s all somebody needs to know, in my humble opinion.

Page: 1 2 next>

Please Login/Register to leave a comment.

ADVERTISEMENTS

"One of the symptoms of approaching nervous breakdown is the belief that one's work is terribly important."

- Bertrand Russell

ADVERTISEMENT

Sponsors