BAs – Being an Agent of Change


Today’s pace of business and how quickly we are delivering solutions serve as a reminder for how easy it is to forget about the change agent aspect of the Business Analyst role.  It seems like in a rush to deliver the solution on time, within budget, value delivery, and of course meeting the needs of the customer, we forget all about the “Change Needs” of the customer and stakeholders.

Stakeholder Analysis is an activity that is often performed in a 15 minute discussion and not given the time it deserves.  After all, like other requirements these are not needs that the business will come out and state explicitly. Could you imagine a business user telling the BA in a requirements workshop:

“I need you to hold my hand, tell me more, tell me 22 times about the way this impacts my world. I know you may have told me before, but I was still thinking about the thing you said before and how that changes my world, so I guess I missed it when you said it before. Let me digest this, and digest some more, let me give you ideas how to make my life easier, and then allow me to change my mind as I understand it better and become more comfortable with the new world. Realize that I do not think about how to improve my process and technology all day so it takes me time to get out of the box I work in and follow where you are coming from. Help me understand the big picture, why are we doing this again? How does this help the organization overall?  It feels like a bunch of people got together and decided on the solution without talking to those whose life it impacts the most.  I am scared that all this change is really about cutting costs to then cut my job. ”

Maybe we should start drawing “Change Scope Diagrams”, where instead of the arrows depicting the user goals or data (of a traditional Scope Diagram), they depict the changes the user will experience by implementing the solution?  This would of course accompany the traditional scope diagram.  A high level summary pictorial view, identifying all the ramifications of change that the solution brings to their world?

Imagine the perspective change of the project team if the project has a high level summary view of the human impact side of the project?  A document they could look at and in less than 5 minutes be aligned on stakeholder change needs.

How would you approach a user interview or requirements workshop differently if you knew the change impacts, concerns, resistance, and influence the person(s)  had before walking into the meeting?

How about the benefit of a place to capture, facilitate and share additional items related to change after that meeting, things you learned about the stakeholder attitudes, concerns, ideas, etc . . .?

 

5 Business Analysis Trends for 2010


Happy New Year!

As we enter a new year, a few thoughts on the BA Trends in 2010 will be.

1) Agile - More companies will explore Agile in practice as an IT delivery model . . . and many more organizations and individual BAs will explore using elements and concepts in Agile to make BA Practices more lean while still being effective in delivering quality business analysis.  Agile as a delivery model requires more commitment and influence than just the BA, I believe many BAs will find success in learning more about Agile and finding ways to evaluate  how to improve BA practices within their organizations by using agility to adapt traditional BA practices into more flexible and agile models and processes of working as a BA.  I am not referring to “less” documentation here, but I am referring to evaluating how much documentation is necessary to accomplish the needed goals of the project while keeping solution quality needs and risks in balance.

2) BA Practice Maturity – With many organizations working very lean in 2009 and pushing BAs to deliver more with less, quality issues have been more visible.  This is making more organizations look at quality and the causes of poor quality.  Many organizations will focus on the BA Role and how the BA can improve quality of solution delivery and requirements, this will bring a microscope on the BA Role and Practices within many organizations in 2010.

3) Process/Data/Rules Linkage – There will continue to be growing demand for documenting and integrating the requirements and integration of business process, rules, and data.  In 2010 more models and techniques will be experimented with that show the business process/rules/data linkage in a easy to understand and compact view for stakeholders.

4) Web 2.0/Cloud Computing/SaaS – As these technologies become integrated into many organizations and their business/IT strategies and  infrastructures, BAs will adapt and discover best practices, tools, and techniques for enabling integrated solutions  with social media, further Cloud solutions, and Software as a Service.  Each of these will require BAs to truly rethink how they have used their current tool-kit, and how to apply and adapt to these new norms.

5) BA Role Focus -In 2009 many BAs got pulled away from the BA role for more hours of their day.  With the economic times requiring companies to be more lean, BAs have been stretched and have been spending more time putting on many other “hats” like: PM, QA, etc . . .  Later in 2010 I believe we will see a refocus back to the BA role.

Cheers to 2010!

 

The “New” Business Analyst


Check out this article about agility and the potential future of business analysis.

http://advice.cio.com/michael_hugos/business_agility_and_the_new_role_of_the_business_analyst target=”_blank”>HTML Help


Are companies ready for this?
If not, what would help an organization get there?

 

BA Process vs. Deliverables – Where to Focus?


I keep hearing all about teams and organizations wanting to improve the deliverables BAs produce. I can’t argue with them, quality deliverables are critical. However, I will push back with the process to get the needed information to go into the deliverable is often neglected.

I like to think of BA deliverables as the culmination of the process to get the needed quality information to be put into the deliverable. Okay, that is a mouthful! Another way to express this is that a quality deliverable (aka: Requirements Document) is not merely a fill out and complete the template sort of process. Any organization focusing on only templates and deliverable to drive quality requirements will be disappointed. I like to think of templates and deliverables as a common format and framework to document the results of the requirements process. Without the process, the requirements template can be filled out with poor quality requirements.

So, what is the magical process needed? Ahhh . . . . that depends on so many factors, and another mistake I see organizations making. The same exact requirements process does not work for every project. Different project needs require the use of different requirements approaches, activities, and techniques.

 

Business Analysis Measurements


Measuring the success of Business Analysis in an organization has been on my mind for years. How do you measure the success of business analysis (as a practice) and Business Analysts individually?

This is the million dollar question with every presentation I give . . . I wish I could tell you that I have an easy answer.

In each organization BAs play different roles and the practice of business analysis is typically performed by roles other than BAs in the organization. This makes standard metrics and measurements that are industry standards extremely difficult to put to use.

Other factors that I commonly run into in organizations is the cultural appetite and acceptance of measurements. By nature measurements are subjective, even objective measurements are subjective at some level. Different organizations have different tolerance levels for subjectivity, and subjectivity means different things.

Most importantly is that leaders and organizations focus on measurements that motivate the right behaviors. Regardless of subjectivity behavior change and leadership is critical to moving the business forward.

 

Webinar – Now Avaialable!


Today I recorded the webinar today on BA Competency Tools and Strategies for Adoption.  What a fun experience!  We had a great live group of attendees and the webinar will be archived for some time on www.batimes.com

It is quite interesting to present a 2 hour webinar without the participants in the same room, I realize how much I rely on the energy in the room presenting.

Now I am thinking of some fun topics to conquer next!

 

Business Analysis Competency: Tools and Strategies for Adoption


Preparing this weekend for my upcoming  webinar!

Business Analysis Competency: Tools and Strategies for Adoption on www.batimes.com

Here is the link for full details:  http://www.batimes.com/webinars/WID00046swf/WID00046.html

The live webinar is this week Thursday, and archived/recorded copy will be available as well.

Besides the basics in competency management Bob Prentiss and I will be discussing the importance of collaboration between PMs and BAs, as well as what competencies other project stakeholders expect from Business Analysts on project teams.

 

What makes a great Business Anlayst?


What makes a great Business Analyst?

I feel like I could talk about this forever . . . and I could!

One thing I keep hearing is that hiring managers are having a challenging time finding great BAs; even in this economy. I continue to think about what it is that these hiring managers are looking for that they are not seeing in resumes or hearing in interviews. Is there a skill shortage of great BAs? or are BAs on the market not representing their skills and talents in a way that hiring managers are looking for?

Investigating and pondering further . . . the great Sr. BAs hiring managers are looking for need to:

  • Have a “toolbox” of BA techniques and have examples of when they have used various techniques
  • Have examples of their leadership skills in situations when they do not have direct authority
  • Have examples of relationship building skills and techniques with technical, business and leadership relationship examples.
  • Show that they can effectively package requirements that relate to both the business, technology, and leadership audiences.
  • Provide examples of delicately balancing flexibility, agility, risk, and Business Analysis best practices.