A long time ago, back when I first started working with Laura and Bridging the Gap, I sat for the CBAP exam and failed. In December of this last year, I finally sat down to try again and have achieved my certification. There were so MANY convenient and juicy excuses to put off the inevitable along the way, but I finally ran out of them. This is the last chapter in my story about seeking the certification and picks up when I was coming away from the first try on the exam.

(By the way, if you are interested in pursuing the CBAP, you’ll want to be sure you check out our overview article: 8 Steps to Becoming a CBAP.)

I learned many lessons in my first attempt and have shared them here previously. A couple really stand out through the time that has passed.

First, one must really sacrifice a period of time to properly study not just the BABOK, but also the ancillary materials that have fed the creation of that document and the practice of business analysis. One document cannot provide justice to all we need to really understand. Second, get over yourself. I had this thought process that had me convinced that I knew it all in a practical sense and simply didn’t memorize the content properly. In all honesty, I do have a lot of practical experience, but that mindset brings arrogance to the table and stands in the way of being fully open-minded about new ways to perform my craft. I was not able to learn and absorb and focus until this occurred.

Additionally, the BABOK has a lot of little tiny pieces of information that I never picked up the first fourteen times I read through it because my mind was closed off. There are small portions of sentences and direction that tie various aspects of the content in the BABOK together in order to provide the links to proper practicing of iterative business analysis. Remember, there are often multiple places to start our work, and this is highly dependent on the situations that are presented to us, and our actions are often altered as a result. Therefore, the BABOK cannot address a front-to-back approach in the written content, but it DOES hold little gems that will guide the reader toward a holistic approach IF you are open to seeing it.

Finally, I truly don’t memorize things well or test well. Only in removing my own misconception about knowing more than I did was I able to really push into the detail over and over again to pick up information.

So these are the mechanical lessons learned that I bring back from the edge of the ledge with me. Let’s delve into the other side…the emotional stuff.

When I failed the first time in trying, I really took a confidence hit. Not because I failed, but because I thought I knew more than I really did. It took me a long time to bounce back emotionally to realize that the knowledge was there all along, but it wasn’t there robustly enough to be useful for personal improvement in exam testing or even in practice. Once I had a big slice of “humble pie” and got out of my own way, I began the journey of understanding my walls and then breaking them down.

Mission accomplished. Test taken. Certification achieved. Woohoo!

Now, it’s time to tackle the final question, “Is it worth it?”

Yes and no is my response. The CBAP designation is still young and gaining influence; I notice more and more roles are requiring the certification in candidates. My own firm, Avanade, Inc., is a very strong proponent of the certification and so am I…just not for the reasons most would think.

The completion of any certification shows only one tangible thing, and that is that the student can pass a test. Nice piece of paper. I still hold this view after passing, because a test score does not make the master. What I find extremely valuable is the insight gained through learning the material in the first place, and if that insight is then put into practice there is a very powerful gain. If the new paper-holder continues with incompetent practices, then shame on the wasted opportunity to grow. Each person who takes and achieves certification must be evaluated individually for what he or she does with it.

Come to think of it, there is much we can do for ourselves even if we don’t pass. For me, I am able to bring insight from the way I studied, not to mention the volume of studying, into the workplace and immediately implement some of the learned practices. I also now have something for those who do not know me or my BA work history to make an initial evaluation that I MIGHT know what I’m doing; I can build on that first impression very rapidly. That is FAR more than I had before.

So yes, it’s worth it FOR ME. In short, if the exam is taken for the right reasons and used with good intention of improvement to the individual and profession, there is great value. If you are looking for letters or dollars as a result, find something more enjoyable to do with your time.

Thanks for joining me on the road to success.

>>Kick-Start Your Own Road to CBAP Success

We’ve broken the road to the CBAP down into 8 steps, each own getting you closer to your CBAP certification goal.

Click here to read about 8 Steps to the CBAP

In my travels away from Bridging the Gap, I think that I’ve learned something new about what might be the second most important ingredient for an analyst. Analytical thinking. In reality, I combine this with critical thinking, even though they are two distinct things.

It’s been difficult for me to spot this trait in people; one cannot necessarily notice good thinking like a nice tie or bad body odor. It’s there, but just under the surface. One really has to observe people working in order to spot good thinking.

So what am I talking about? Let’s look at some definitions first.

analytical thinking

noun
the abstract separation of a whole into its constituent parts in order to study the parts and their relations

and

critical thinking 
noun
disciplined thinking that is clear, rational, open-minded, and informed by evidence

It’s almost like I’ve found some old friends in discovering these definitions. For me, these are the missing pieces that I haven’t been able to put my finger on when I’ve seen something missing in an analyst’s ability. Conversely, these are also the things that I cannot identify as distinguishing factors when I see an analyst who has “got it”. I know we have all been talking about these skills for years as a collective, but I’m bringing them up now again because I’ve seen the light.

Analytical Thinking

The “…abstract separation of a whole into its constituent parts…” Yes! What could be more clear? When analysts engage on a project, this is the step, or series of steps, that are critical to taking a problem domain and deconstructing it for analysis and reconstruction. Without this, one cannot see all the many facets of a problem or opportunity nor be able to explore it on all sides.

Why? Because without deconstruction, one can only see the four sides and the top of the box. Deconstruction allows us to pick the box up, open it, take out its “stuff” and look at all the sides of said “stuff”. This is where the questions start to get asked and where thought begins to roam and wander into the “what-if” zone. This is where we test our theories and spitball about possibilities both positive and negative. This is where we separate what is critical to a project and begin the reassembly process that results in a viable solution.

Critical Thinking

The key piece for me here in the above definition is “…informed by evidence…”  This falls right in line with a thought I often express as, “Prove it!” Without the existence of evidence, analysts who employ critical thinking will be compelled to start asking questions about the validity of what is being told or shown to them. They might not understand why they believe whatever it is that they believe, but there is a gut instinct that makes them ask questions that others might not. Something is missing that prevents satisfaction of their curiosity for the truth in whole.

Critical thinking, for me, is similar to the checks-and-balances system we learned in school about government. It is just that — a governance mechanism over analytical thinking that seeks enforcement of thorough thought. When analysis has not been performed nor resulted in the “proper” answers, then critical thinking gets triggered to ensure that the analysis is completed. For an analyst with these two capabilities, it’s almost a compulsion that kicks into place to drive answers home.

Where Can I Buy that?

You can stay up as late as you like after the cheesy movies are over and wait on the infomercials to sell you analytical thinking promos with a bonus of critical thinking, but all you’re going to come away with is a set of Ginzu knives and a SHAMWOW! moisture suckerupperthing. These two characteristics are inherent in many people, but they can be taught. Those seeking to develop these skills don’t have to live a life of misery without them, but attaining them might require learning and practicing some thought exercises that get the brain to engage in new ways. There are many, many resources available in books and on the internet, as well as seminars and courses that teach both qualities of thought.

Fortunately, this is great news for the analyst community, because once we each learn these capabilities, we are able to encounter new challenges and conquer them without as much blood, sweat and tears. So the question is really about how we learn these skills. It starts very simply, and that is the good news.

Start the practice of asking questions that you would not normally ask about things. My favorite questions is, “Why?”  That is because in order to answer it I have to think about the question in different ways, so I can answer it the best way. For instance, if I’m looking at a box on the ground in bright sunlight, I might ask myself why the shadow on one side of the cardboard is obviously darker than that on another side. Only through discovery and inquiry will I find out that the brighter side of the box is picking up reflected light of the ground. This is analytical deconstruction in which I break down the problem into smaller bits or questions.

PROVE IT!…comes next. The critical thinking part. How can I prove that my answer or hypothesis is THE ANSWER? Hmmm…what if I took some non-reflective cloth and laid it on the ground to block the light? Would the shadow still appear brighter? Again, I am asking questions about what I had previously taken for granted or assumed.

To continue your education, there are some REALLY good courses online and at local universities in critical thinking, less so in analytical thinking. However, combine a critical thinking class with some business analysis discipline, and you just might be on your way.

There are a number of blogs about critical thinking. (You can check out a list of my favorite critical thinking blogs.) Most have nothing to do with business analysis in any way, but in every way they do. Read a few posts on each one and pay attention to the line of questioning and the drivers for answers that these people bring forward. It’s the same when you apply critical thinking in another domain, just a different subject.

I wish you all well…

I read an article today from our respected colleague, Yaaqub Mohamed about the importance of data analysis as part of a good analyst’s tool belt. Well that is not exactly how he put it, but you get the gist.

Anyhow, it got me to thinking about another type of data that often goes unnoticed until it is far too late to even say, “Oops!” Yes, yes I’m speaking of nomenclature and that involves the identification of terminology and the definitions and aliases used to capture meaning.

It doesn’t seem all that important, but it can be as dangerous as a missed stakeholder with a bad attitude and political agenda if not properly handled. Allow me to paint you a scenario to consider.

I work for an organization that started with one division and it ended up buying three more along the way. We all do the same thing, but we do it in different states under different legal guidelines and the like. Each division had been in business for a number of years prior to being merged with the others. So, it stands to reason that each division’s employees does things a little differently while achieving the same goal. Along with that, each division refers to the same entities by a different name. Imagine trying to build an enterprise application with this standing in the way. I cannot begin to tell you how interesting the JADs are before we realize that there are either four names for the same thing or one definition applied to four disparate terms.

It would seem that a glossary would cover the issue and we could move on with our lives, but that requires people to read it. When was the last time you took the time to look up a word that you didn’t understand? The real issue rears up with usage, context and general comprehension during conversation. Most of the time we can figure out context while holding conversations and can even pick up an accurate meaning periodically.

However, when there are 30-40 people arguing about things while using often very similar, yet still completely different terms, the last thing that people seem to do is whip out their trusty glossary. Most of us go with the flow, so we don’t appear stupid, and that is about the stupidest thing we could do. If terminology is not clearly and consistently understood, there is a huge margin for error in the solutions that you as analyst recommend to your audience. If there is more than one audience and they aren’t on the same page, then guess what happens? Yup! Think about the error conditions of implementing business rules if there is not clear terminology for governing the entities of the organization. Migrate those problems into code and you have real issues.

The analyst has a grandstand seat to watch these struggles in order to understand trends between stakeholders, and plays an important role in bringing people together to talk and listen to one another in order to find common ground in terminology. Failure to do so can lead to costly, yet surprisingly simple errors. Here are a few things you can do…

• Identify your terms. As you take notes and write documentation, pick out the domain terms that are repeated or singled out as words that have meaning to your stakeholders….especially those that can have multiple meanings.
• Make a simple glossary a mandatory part of your documentation. Even if everyone speaks the same language (meaning dialect) and calls an orange an orange….your writing will capture that fact. Eventually, someone will be hired who refers to an orange as a lemon and you will have the baseline established.
• Ask if you don’t know what something means! If anyone is going to ask stupid questions, it better be you functioning as an analyst. That is why you are there…and don’t forget that! We ask the questions that people having been avoiding for years while they were trying to look smart. Why do you think they need analysts now?
• Validate your terms and definitions against the business rules, whether in text or code.
• Validate your terms and definitions with ALL stakeholders.
• Define all known aliases to bring mindsets and conversation together.

In summary, take a little time to make your life and that of your stakeholders and developers by calling out variations in the words you hear used to describe the domain that you are working in. Take ownership of controlling this knowledge, and put it to use as a part of your project. You will not believe all the use a good set of terms can have, not the number of times others tell you how great it would have been if they had it previously.

My past 25 years of work experience has been in the not-for-profit sector, in both program work as well as various IT roles. A part of this work that I have enjoyed very much is when I have had the opportunity to help the organization I was working for to improve its processes to better meet its goals. At times this has involved helping the organization select an appropriate software product, and working with consultants to customize the software to best meet the needs of the organization.

I would like to focus more on this type of work, and am even thinking of taking some formal training in business analysis, but I don’t know if business analysis principles and processes are suited to the not-for-profit sector. Initially I would hope to apply the skills I learn at my current organization, but I would also like to volunteer helping other not-for-profits, and maybe even some day earn a living by doing business analysis with not-for-profits.

Could you tell me if my aspirations are realistic? Are there any BAs out there who do this very thing? Are there any real opportunities available? Thanks.

Doug’s Answer:

Why yes! Yes there are. I can’t tell you strongly enough that you are doing exactly what you should be doing to advance your career. Offering your services to non-profits or small business that cannot afford to hire extra resources will help you work through your growing pains while providing valuable assistance to organizations that are typically desperate for help.

When I speak to working through growing pains, you will have to realize that you are highly likely to make mistakes in judgment and execution as you work on projects. This is absolutely normal and you should look at mistakes and even failures as learning opportunities. The really great thing is that you are able to work through these events without the pressure of getting fired, demoted or having your reputation tarnished. Due to this fact, your confidence grows as you try things again and finesse your techniques along the way. FINALLY, you are less likely to suffer the wrath of your boss due to a mistake, because you are volunteering. This is THE best way to learn a craft, but by combining it with your academic ventures, you are melding book knowledge with life experience and this will yield great results and rewards.

OK, so congratulations on your insight into the things that you need to do. To your comment about whether BA principles are applicable to not-for-profit organizations…..absolutely. Actually, BA principles are applicable in any environment in which there are problems to solve, not just in the business world. Sticking to business, though, ANY business in any industry employs resources in both human and material form, utilizes process to accomplish a task and has inputs and outputs to and from points in the process. Business analysts are skilled in viewing all these components, looking for efficiencies (and deficiencies) and recommending solutions that provide value. From a lemonade stand to a high-tech software company, the analysis is essentially the same at the core.

All the best to you. You’ve got a great start going. Let us know how you progress.

>> Learn More About Business Analysis

What Skills Are Important for a New Business Analyst?

The Business Analyst Career Roadmap

How to Write a Business Analyst Job Description

I was a project manager for 25 years, but for the past 4 years I have been involved in software QA and Process Improvement as a consultant for CMMI and other standards. I’ve been giving serious thought to moving towards a BA emphasis in my career, returning to earlier roots as a systems analyst. However, I’m no longer a ‘spring chicken’ and am wondering if makes sense for a post-60’s skilled/experienced individual to begin contemplating a career in BA? Be honest!

Doug’s Answer:

Pondering a career change at any stage in life is a hefty undertaking, and while I cannot speak directly to the complexities of those past my own age, I can make the attempt to give some general advice. What I see in the poster’s question is a great degree of experience that does not jump right out and say “business analysis”. However, everything this person has done involves a large degree of analysis technique and skill in order to be successful in the above respective roles.

As a PM, this person would have encountered organizational skills and potentially the rigor involved in CMMI-based methodology that typically requires detailed check points and documentation, as well as phase gate approvals. If this person has been in an industry that is under regulation and has the potential for audits, there is even greater emphasis on knowing what must be accomplished besides the actual project work. This brings a high degree of discipline.

As a Process Improvement consultant, this person would have been involved in many efforts that involve changes to organizational structure. This must include a large analysis effort revolving around business unit impact, application impact, infrastructure assets, resource requirements, and even simulated exercises to test potential new processes. Many of the analysis techniques described in the BABOK are used in this area of expertise, such as root cause analysis, decision analysis, interviewing, observation, etc. So, the poster would have gained exceptional experience as an analyst even if that is not what his or her title indicated.

So, to the question then. To me, it would make more sense to not necessarily switch careers but to re-brand your capabilities in a different way that emphasizes your ability to analyze…because that is what this person has been doing essentially. A career switch can be a huge, lengthy and often frustrating undertaking if positions are not forthcoming for the job seeker. My sense is that this poster has a ton of capability to bring to bear and would be better recognized and utilized as a senior consultant that has expertise in guiding analysis efforts for many types of projects. I also think that the job search results might be better than if he/she is marketing himself/herself as a fledgling, yet elder analyst. I don’t believe in job discrimination based on age, but the reality is that it occurs. I would offer the advice that this person should be presented as an experienced mentor who is brought in to resolve issues, so that should be the focus of self-marketing efforts.

Then how does one really get one’s head around how to make that happen, especially if there is no recognition that perhaps analyst skills are already present? Start reading and taking some classes. Read through the IIBA BABOK to recognize skills you already have. Read business analysis articles, blogs and books to recognize how analysts perform their duties formally, in order to understand that much of the current skills really do translate into formal analysis skills.

Finally, you’ll want to sign-up for Laura’s free step-by-step BA career planning course, download Laura’s eBook on How to Start a Business Analyst Career and keep your eyes posted for enrollment into future business analyst training courses.

Hi, My manager asked me to define KPI for the business analyst job. I’ve tried do to some research but everybody seems to have a bit of a problem around this. Do you have any ideas from where to start?

Finding a Meaningful KPI for a Business Analyst

Trying to measure what appears to be an intangible item (BA Performance) is truly difficult. It takes some imagination and thought to figure out whether there are actually tangible objects that can be measured. If the conversation was about development performance, we could measure defects per lines of code. For project management, we could track cost overruns or schedule slips.

For business analysis, what exactly is there available to measure?

We have to start with our products that we deliver – and look at the value of business analysis. Since most of what we actually deliver is a service, what could be considered an actual product that is created? The only thing that comes to mind is the requirement itself, which is either captured in BRD for Waterfall, or as an individual or small set of requirements grouped together for Iterative/Agile. Either way, since it is produced, it should be able to be measured for quality, right? Kind of.

Measuring Business Analysis Performance Through Peer Reviews

I’ve found that it’s not a simple comparison, but rather a multi-step process that offers an illustration of quality over time. What I do is mandate for my projects that documentation is exposed to the peer review process .

A peer review comprises of a review of the documentation against pre-defined acceptance criteria of quality characteristics. The BABOK 2.0 discusses these criterion at length starting on page 115. The review process should capture a percentage of overall requirements (maybe 2% of the total number of requirements) and should result in feedback that highlights flaws in requirements.

For instance, if I request a review of a BRD from five peer analysts with direction to review a random set of say 20 requirements each, I would receive feedback on 100 +/- reqs and indication of what is wrong with each. The initial review provides a picture of how well the analyst is writing requirements and the feedback can be used for rolling improvements. I then keep that feedback even after I correct the flaws.

Measuring Business Analysis Performance Through Evaluating Defects

The second piece is to run a report of defects for the release during the UAT cycle and perform some analysis to try to determine if any of the defects map directly back to requirements (or missed requirements). The number of requirement related defects can then be compared against the number of peer review requirements flaws for an overall percentage that can be applied toward a performance KPI.

The kicker here is the time it takes to perform all this comparison analysis and usually results in this second piece not getting done. Simple cost/benefit analysis usually indicates that the first part is fairly adequate and adds in the needed quality where it has the most impact.

How do you measure your business analysis performance? Have you found a truly valuable KPI to evaluate a business analyst?

Learn How to Measure BA Performance

Adriana Beal has address this challenging topic in Measuring the Performance of Business Analysts, a practical guide to finding meaningful KPIs that can be measured without unnecessary overhead.

Click here to learn more about Measuring the Performance of Business Analysts

The story with me has been that if I am hired to create documentation and other deliverables for either my development or business audiences, they have an obligation to read what I’ve done for the sake of the project and organization. While I do still believe that is true, I have also spent the better part of a year observing my working environment and reading the posts of respected peers and experts regarding documentation, methodologies, bridging the gaps of communication, etc. Why? Because something has been gnawing at me about this scenario. Why is it that people are not using or reading what I deliver?

Well, the fact is that there is not much value in the physical or perceived weight of my deliverable. Think about it. There is a line of diminishing return as the page turns in a massive BRD; I’m sure one that steeply drops into the abyss somewhere around page 319. So the more people are reading, the less they are absorbing and processing for use in their real work.

I’ve been failing. Period. My audiences are diverse and very busy; they simply don’t have the time they need to do things the way they should. Also, as the business world has become more competitive due to many factors, there is less money to produce documents that no one reads. So, I’ve found myself in the middle of a metamorphosis that I’m sure will have Scott Ambler ringing my doorbell any moment. Alas, this is not Agile requirements that I’m talking about (yet). It’s figuring out how I can adapt to serve my customers (Business and Technical) and deliver to them what they need in smaller volumes, without ambiguity yet with enhanced clarity.

See if you can respond with exceedingly good ways to deliver quality requirements WITHOUT mentioning any methodologies or best practices.

>>Let Go of Your Big Thick Requirements Document

Check out the Business Analyst Template Toolkit – the set of requirements templates host Laura Brandenburg has been using to replace 50+ page requirements specifications with a sequence of shorter, actionable documents, most of which are less than 3 pages long.

Click the link below to learn more:

http://www.bridging-the-gap.com/business-analyst-template-toolkit/

When regarding which stakeholders should participate in requirements discovery on a project, it’s easy to invite the masses to the meetings. However it’s more important to get the right stakeholders actively involved and the right time. Having more stakeholders than necessary can bog the meetings down in argumentation, conflicting dialog and detail. But overlooking an important stakeholder can result in missed requirements.

By the way, if you want to learn Laura’s top tips to getting stakeholders more actively involved on projects, Click Here to Download a Free Guide – 10 Tips to Improving Stakeholder Engagement.

Who are the Right Stakeholders?

Deciding who should be involved, how, and when in doing stakeholder analyses[sic] is a key strategic choice. In general, people should be involved if they have information that cannot be gained otherwise, or if their participation is necessary to assure successful implementation of initiatives built on the analyses.

— Thomas, J. C. (1993). Public Involvement and Governmental Effectiveness: A Decision-Making Model for Public Managers. Administration and Society, 24(4), 444 -469.

Getting the key stakeholders to participate in a project should not be anoff-the-cuff decision, but rather one that is a result of careful analysis and selection. Stakeholder Analysis is a much written about activity, but the general definition involves the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. (IIBA’s BABOK(R)  Guide, 2009)

This all sounds pretty simple in essence, but there is actually a lot that goes into identifying the correct participants. Also, skimming over the tasks related to this analysis can put the entire project at risk by not have the proper people involved or not having influencers associated with the project to help guide the project in moments of indecision.

Start with a Formal Stakeholder Analysis Exercise

There are many techniques for performing stakeholder analysis, but the overall goal is to determine who are the persons impacted by a proposed change and to assess their attitudes and influences on various project factors. These attitudes and influences are the drivers behind decision making and project progress in and of itself, as well as against the entire suite of active projects.

There is one critical element to stakeholder identification that often eludes a project’s members. Once formal stakeholder analysis is completed at the beginning of the project, it SHOULD continue throughout the life of the rest of the project. The identification of stakeholders early in the project will often result in the names or persons with manager and sponsorship powers, as well as line managers tied to the business units. These are definitively key stakeholders that have to make decisions about the project’s scope and direction.

Include Subject Matter Experts as the Project Unfolds

However, as the project team delves deeper into the requirement elicitation and modeling of the system, it is possible that the key stakeholder becomes someone more intimate with the inner workings of a department, system or team. Failure to identify additional stakeholder, often referred to as subject matter experts, as the drill-down continues can often lead to products or services that are not deemed usable by the very people that the project is designed to serve.

It’s important for the analyst to not replace the original key stakeholders with yet another set. Rather, the analyst is in a position to re-evaluate throughout the course of discussions whether the correct people are included. This doesn’t require another full stakeholder analysis exercise, because the analyst is not trying to, again, replace anyone. The goal is to get additional impacted persons to the table, perhaps through a subject matter expert interview. Where the focus of the original stakeholder analysis exercise was the entire project, a subsequent evaluation of proper stakeholder inclusion could focus on a granular sub-component of the project, such as an operational unit, system component or the like.

It’s also important to remember that as projects continue through to completion, the political aspects of the organization and its stakeholders are alive and well. Careful consideration to the inclusion of particular stakeholders must be given in relation to the attitudes of existing high-level key stakeholders.

Project failure has as its root cause many possible reasons. Delivery of a requirement set that has input from many potentially impacted stakeholders with thorough discussion and analysis helps to remove from consideration the possibility that the requirements didn’t meet the stated needs because the wrong people were involved in their definition.

Download Your Free Guide – 10 Tips to Improve Stakeholder Engagement

And  if you are looking for even more tips to manage difficult stakeholders, download this free guide. You’ll

• Save time and effort by clarifying the requirements more quickly.
• Build stronger relationships that elevate your reputation and career.

• Improve project outcomes by communicating more effectively.

Another aspect of this, though on a grander scale, is the need for cohesion between Business and IT on projects that involve  process development or improvement efforts. Process work is only one facet of a business analyst’s skill set, but these projects often span multiple organizational units, disciplines, political boundaries, technologies, and personnel resources. So, no matter where in the process a failure occurs, the feeding or consuming portion of the process that surrounds the failure is impacted. To make matters worse, a single failure can have multiple downstream consequences due to dependencies that are sometimes not viewed as direct consumers of an upstream activity.

When I think of process work, I generally think of a business process that starts and ends on either the business or IT side. In other words, the boundaries that currently separate an IT department from an organizational business unit generally contain the processes within each. Recently I came across one that DID cross over (and, no….I didn’t get to speak with my deceased grandmother). I work for an organization that has multiple divisions in different states and multiple business units inside each division. When requests for change to their common application suite come in to IT (which services all divisions), it has not been uncommon to see duplicate or conflicting requests. Moreover, our IT development capacity is limited and the various tidal waves of changes, defects, and project work orders was overwhelming us. To make matters worse, once a change arrived in IT’s hands, the original process no longer was able to handle the request efficiently, thereby double-dipping IT resources.

At some point, I began to look at the process that was governing all this and realized it was very broken. Immediately, I identified the largest siphon to our capacity, and that was the fact that we were spending huge amounts of time facilitating conversation between business partners who had previously not discussed among themselves what their wishes were. Some of these conversations went on for weeks as meetings were adjourned and decisions were delayed. Additionally, we had no method for funneling all work of this nature down a single path to realistically define impacts to capacity. The obvious choice was to push all of this back onto the “business side” to let them fight their own battles.

When I first began to broach this subject, there was considerable consternation, defiance, avoidance and other push back. Much of that was simply because there was no visibility as the consequences of this issue.  Eventually, when a negative dollar value was attached to it, the light went on. What’s a negative dollar value? For this scenario, I showed them step-by-step where business was paying for IT to participate in core business functions (like decision-making meetings) yet were providing no deliverable to business and were also not providing value worth the time we in IT were spending doing it.  I had to come up with a way to communicate that we did need to place some activities on the business side, and I did that by doing two things.

First, I dug deeper into the problem and was able to identify the productivity failures that IT was having due to the high volume of non-productive work when engaging with business on the change process requests. Each one of those was mapped to a function that if taken over by business, would better serve them in the end, because IT would be able to deliver more code when not working through business issues.

The second thing that really helped was two-fold. We created the new process that governed both business and IT when handling change, but each activity was created or modified during a partnership between the two entities. Each improvement in the process also included a value statement for both Business and IT, so there was clear understanding of the goals. All participants were as much a part of the solution as they were the initial problem. I also created a full set of checklists that governed all the major decision making, set expectations for deliverables up front, and assisted in making determinations for when to bypass portions of the process due to emergency needs. The checklists were delivered as aides to business to help them function, and each would start getting used very early in the business-only portion of the process and follow the request through as it is turned over to IT. These set the expectations for business from IT and helped to define areas that business could understand what the expectations were before they started to work on a change (read: less rework).

To wrap this up, I could have reworked everything on my own and presented it as an IT solution. People don’t really like change though, and having them be a valuable part of the solution creation process allowed us to change together for the good of the whole. We are currently in the middle of implementation and are working through small portions of the flow in each phase together. The creation, adjustments, measurements, decisions and successes are all a result of this collaboration….and all of a sudden people are geared up to change. “Their” problem is now “our” problem and we’re fixing it together.

The analyst needs to manage the communication that MUST occur between the two operational entities. There are techniques in place to help the BA that are tried and true. As with the attitude issues and resolutions I wrote about in my previous post, technique is only the vehicle to achieve the goal. Willingness, knowing when it is appropriate and being able to cross boundaries to assist who is often considered “the enemy” is the critical skill. Unfortunately, there are times that even though the desire to assist a project partner is evident, the organizational boundaries of ownership prevent that from occurring.

Executive Management, responsible for resource allocation expenditures, may view this as dollars wasted, while not realizing that by helping “the enemy”, the analyst is providing huge value their own team. Very often the psychology and rules of corporate management strictly govern what a manager can or should do with a resource. Briefly to this point, there may be tight guidelines that prevent the formal sharing of resources or a resistance to allow resources to spread their wings for the good of the department. The more they spread, the greater the loss of control. These are ownership constraints that prevent collaboration on projects. It takes a confident manager to overcome these types of obstacles.

A recent project I worked on as an IT analyst is one that comes around twice each year to address market conditions. It’s a revenue producer and is highly visible, cannot fail and is very fast-paced. The last round had a business stakeholder who wasn’t new to the organization, but was new to the project. Things started off fine, but as the complexity and speed of the project grew, this person began to struggle. So here’s the dilemma…do I take time that I don’t have away from my primary duties to help this person out? I bet you’re familiar with a few of these:

• “They’re business. We’re IT. Their own people can figure it out.”
• “That’s their problem, not ours.”
• “If that’s the best they can do, it’s not our problem.”
• “So? We have enough of our own problems. What would you like me to do about it?”

Well, enough of that. Let’s step back here and look at what is going on.

We are seeing the initial arc of the circular relationship between Business and IT. The customer has project (problem/opportunity) that they have funded and IT is working on it for money (getting paid). Continuing this path will maintain the current relationship, but it does nothing to make it a successful one when issues arise and one side or the other cannot fulfill its part of the equation. The second arc brings both sides together in collaboration in which the two rely on each other for success as a whole. Situations like the above are looked at as problems for the “other side” to worry about, but aren’t they REALLY opportunities in disguise to come together?

To continue, the customer and I began to work very closely together. There was much back and forth collaboration, many conversations, lots of hand holding, and paired testing. When this person didn’t know who to contact to answer a question, I provided information. When pieces and parts of requirements were disjointed or missing, I described why it couldn’t be delivered like it was, how to fix it and provided templates and guidance to help.

I spent maybe 15-20 hours in small increments over the life of the project with this person one-on-one. Little stuff like making myself available, answering a few questions, calling to see if I could assist, and providing education made big differences in our working relationship and the deliverables coming over to IT. This isn’t superhero stuff that many teams seem to gobble up; it’s just good customer service. What happened out of all this was a gracious, more confident stakeholder, better deliverables that arrived on time, and a stronger working relationship.

What did NOT occur was that my manager didn’t berate me for “wasting” my time, because there’s a prior proven understanding of the value of this exercise. When IT receives better quality deliverables from a customer or stakeholder, IT struggles less to define what is really needed and is able to meet its own deadlines and produces less defects that require additional defects. That’s important to IT’s bottom line; we’re more productive and more efficient. Customer dollars that may have been spent fixing defects now appear as profit.

If a resource can identify opportunities for improvement, there must be flexibility and autonomy to take advantage of it. There must be management that believes in the value of reaching out to the partner, because the monetary and non-monetary benefits far out weigh the cost. Financial frugality and accountability are important aspects of running a solid business, but ownership has its place. Getting the job done is an activity that any level of manager would defer to, no matter who signs the check.

….and those arcs I spoke above….they’re much stronger when they form a circle.

>> Learn How to Build Stronger Stakeholder Relationships

5 Ways to Earn More Trust

53 Tips for Discovering All the Requirements

How to Give Positive Feedback to Your Business Stakeholders

Today, teams of resources attempt to work together in high-pressure environments, and project teams must find ways around obstacles that deal with political agendas, communication, collaboration and attitudes toward one another caused by issues in these areas. Failure to do so can produce poor attitudes, incorrect results, frustration, decreases in productivity and increases in wasted time, money and human resources. Experienced IT or business analysts, by thinking and acting across boundaries, can help enhance team cohesion and results.

There are several reasons why attitude becomes an issue that needs resolution. As a business partner that interacts with IT and funds projects, that person is trying to conduct business operations and is reliant on support from IT. Immediately, the psychology of that relationship has the potential to place the business partner into defensive mode, due to a simple inferred trust relationship.

The first encounter between the two teams is where defensiveness can first form. Business comes to IT with a need or problem, and IT is supposed to take it and form a solution. Often, there is a lack of thorough understanding between the two teams, even if the need has been stated. The explanation of the core business need is not understandable for IT to take action on, even though it’s clear as day for business. Why is that?

Let’s look at the opposing perspectives. Business states, “The system must accept online payments.”  That statement, in the eyes of business SMEs is plain and simple. To IT, more information is needed to resolve questions about payment format, payment options, banking options, language options, security configurations, etc… If an analyst has only documented the need and delivered that to IT, questions abound and attitude forms. Taking into account that the analyst should have done a better job, IT perceives the business to be short-sighted and business is put out by having to answer the same question again.

Communication failures breed frustration and frustration forms bad attitudes toward one another. Without a BA skilled in facilitation and elicitation, the level of anxiety for both teams can increase. Whether an IT or Business analyst, that person has an obligation to step out of his or her comfort zone to hand-hold the partner and the communication process until the message is clearly stated and understood. Sure, analysts have techniques to elicit requirements and communication, but the point is that technique may not be enough. Sometimes, the situation requires that analysts step into the shoes of their counterpart and do whatever it takes to build a trusting relationship in order to succeed together.

On a recent project as an IT analyst, I found myself receiving multiple, conflicting change requests from members of a business team regarding data, some filled with mistakes. I soon realized that the business team members were not communicating with one another and not cross-checking the quality of the data requests before they were sent to me. The resultant errors were causing huge problems for IT due to integrated systems all trying to use the faulty data. With permission from the senior business stakeholder, I was able to assemble the business team and explain the issue and the problems. Together, we crafted a better way to ensure the quality of the requests and data.

This was not an IT issue at its root cause, but by working directly with customers and avoiding finger-pointing, IT was able to build a trusting relationship, support our partners (not our enemies) and immediately improve productivity while reducing costs. Additionally, we taught our business peers not only why the issue was so important, but how to do things going forward, thus reducing the potential for future problems. More importantly, the poor attitude from IT toward business was quickly dissipated before it grew roots, because we helped the business help ourselves.

A secondary factor that contributes to attitude is the lack of visibility of what the other side has to do to function. IT has no clear line of sight into the workings of business process and management; and business doesn’t generally understand what makes the technology implementation so complex. The analyst is in a unique position to offer up some simple clarifying communication to enlighten all participants. Here are some very simple things that an analyst can do to enhance communication and collaboration:

As an IT analyst:

• Don’t just define the superficial problem; explain why it’s important that things are done a certain way.
• Introduce the technical team members to the business partners and explain what each role is responsible for.
• Include technical team members in working sessions with business and facilitate that dialog. Doing so will allow for free exchange of ideas and concerns and will allow business partners to understand why certain questions are asked.
• Actively offer customer service support to business team members and all stakeholders to let them know you want them to succeed.
• Pick up the phone and call the business team members and stakeholders to check in with them for no reason. This takes customer service to another level and let’s them know that you are sincere in assisting them.
• Contact the senior stakeholders and inquire about progress, comprehension, team collaboration and anything else that will bring the IT and Business teams together.
• Always approach every communication with a “What can I do for you?” customer service approach and attitude.
• Always remember that you may work for IT, but you are probably the ONLY person in IT to protect the interests of your CUSTOMER.
• Always remember that business dollars make your job possible.

As a Business-side Analyst:

• Insert yourself as much as possible into IT conversations about your project.
• Reach out to IT management to let them know that you desire to deliver what is needed and to call on you for help.
• Proactively inform IT of business-side problems and ask them for ideas on resolution for the benefit of both teams.
• Remember that IT is your CUSTOMER. You are delivering something that they need in order to help you, so by providing quality you are making it easy for them to do so.
• Actively seek feedback from your IT contact to ensure that he/she knows you are committed to doing a good job.
• Always remember that in today’s electronic environment of doing business, IT has the capability to make core business operations successful.

While these suggestions seem trite and corny, they can significantly change attitudes. They go a long way to building a better working relationship with peers on the other side of the fence. That relationship is what will glue both teams together and form bonds that will collectively break down communication barriers, avoid frustrations, and produce success.