In How to Wow, Frances Cole Jones covers some oldies but goodies like reminding us that 7% of your impact comes from the words you say, 38% from your tone and 55% from body language. Jones also packs in a number of invaluable strategies for helping make all meetings and social events successful.  I found one technique priceless – writing a diary entry as if it were tomorrow. If you have an important meeting or event coming up, write down details of the event as if it had already happened. This technique helps you think through potential scenarios and prepare for the meeting or event. This is similar to the Field of Dreams mantra, “If you build it they will come.” If you write it down it will happen.  

Jones’ conversational writing style makes this a fun and easy read. I felt like I was her long time friend and she was just giving me some good sound advice over coffee.  She pulls many of her thoughts from her vast library of experience working with executives preparing for TV and print interviews and large scale company meetings. Although many of her examples may not directly align with your role, you will not find it hard to bridge the gap and find ways to implement her strategies. 

Whether you facilitate meetings or just attend them, host lunch meetings or just get invited to lunch, present to large groups or just one person, you’ll find significant value in reading How to Wow.    

Happy reading,

Kupe

As a BA there are a number of elicitation steps and analysis steps I may need to go through to figure out what solution will truly create advantage. I really appreciate what the author said about designing to performance. Depending on the problem, often it is a performance issue, especially in manufacturing or engineering industries. Not always. Times are changing and new practices may be needed. For any innovation, BAs must learn and adapt.

SMEs, BAs, architects and developers are often most effective when they are housed together, all part of the same team- and guess what? Some of us have been working on those types of teams going on 30 years before the word agile was ever coined. Really understanding your customer will always be a best practice. For me, familiarity breeds success rather than over the wall contempt. Having the appropriate resource allocation (the right people who can make decisions) and a sound, light-weight process (something iterative) are what I consider a best practice for success. Having worked with many cross-discipline, cross-functional teams, I have never found a better replacement for these best practices: an agreed upon approach, clear objectives, team collaboration, trust, and enthusiasm and throw in the appropriate amount of management support are all enduring and dare I say best practices that can bring any project to a satisfying goal. Oh wow am I showing my age? OK well maybe today our team may be global and we have to do most tasks with a web cam, use collaborative software, SharePoint, wikis, texting and Twitter but the rest still endure!

Collaboratively yours,

Angie

Someone asked why the BA definition in the latest BABOK v2.0 no longer uses the metaphor of a bridge between Business and IT. Kevin Brennan of the IIBA responded that

1. the BA role may not deal with an IT component 
2. the BABOK did not want to”promote a definition that appears to limit BAs to a facilitation role”.

I still like the bridge metaphor but I applaud the motivation of the IIBA to discontinue descriptions that sound like the BA does nothing but take notes from one group and translate them back to another.

Of course a BA is a facilitator eliciting requirements from different stakeholders, working with various business and technical stakeholders to reach consensus and shared understanding about their disparate needs and intentions. A typical BA masters many other analytical and design skills, particularly critical thinking, and problem solving in addition to facilitation. I respectfully disagree that the bridge metaphor limits BA role, and I will slightly change the metaphor and say the BA is more like a bridge-builder than a bridge. After all, BAs do not want to have the masses walking or driving over us to get to the other side. Ouch! BAs construct real bridges so people can reach their destination faster and safer than they would without one.

The most important message about the bridge metaphor is that you reach the other side successfully. Along the way – as the BA is building the bridge, the BA establishes trust, promotes collaboration, demonstrates active listening skills rather than pushing their own agenda, practices good time management and organization skills, focuses on critical requirement priorities, employs rational analysis techniques to suit the situation while simultaneously communicating clearly and succinctly in the most effective style that fits each stakeholder.

In summary to be an expert bridge-builder you must master many hard and soft skills and techniques to connect with various stakeholders (conversing in their unique languages and adapting and learning their terminology and about their systems and processes). Our ultimate goal is to bring everyone along to the other side successfully and to perform this feat well enough that we are asked to build many more bridges in our career for years to come.

All the best,

Angie

• Q: I’ve always tried to teach you two things. First, never let them see you bleed.
• James Bond: And the second?
• Q: Always have an escape plan*.

*From the James Bond movie (The World is Not Enough)

In case you have never followed the Bond movies, Q was typically an elderly gentleman who would invent and demonstrate all the cool gear that Bond would use to confront and avert danger.

Imagine how great it was that 007 had the right weapon, tool or technique to keep ahead of his enemies and avert any danger. Glasses which could shoot bullets, exploding gum, ropes and parachutes that would suddenly appear in the throes of imminent doom, speed boats or cars, blasting from the water to land, allowing Bond to apprehend the bad guys in the most incredible way.

Q’s advice to 007 also works for business analysts.  A business analyst, like 007, needs to be skilled and confident. A BA must plan to be prepared for all the normal situations (never let them see you bleed) and an experienced BA must always have a well thought out “escape plan” to preempt failure even when the unpredicted occurs.

Q’s rules can help us change the negative perceptions of the BA role that some still hold. Have you ever been frustrated at complaints volleyed by the agile community against business analysts?  “A BA is an unnecessary middleman. The BA is an impediment to meeting project deadlines. BAs are often inflexible to react appropriately and efficiently when it comes to determining how much documentation is needed on each project.” Yada, yada, yada and on it goes. According to some there is no need for a business analyst on software projects. As a profession we need to collectively change this view of our value.

Never let them see you bleed
One approach is “Never to let them see you bleed”.  In other words prove the naysayers wrong on every project you work by making a difference to the final outcome and providing the highest value. Give them a reason to request you in the future because you have shown that you are prepared, confident and efficient. There are steps you can take to build an excellent reputation.
 
When assigned to a new project an experienced BA can hit the ground running by quickly sizing up the project and looking for similarities from prior projects. Considering those common threads, you can confidently plan the next steps in short order. For example, if you have previous experience with the project stakeholders, with that prior knowledge you know which elicitation methods and communication channels will work and can move ahead quickly.  As you articulate exactly what techniques or deliverables are necessary (and why) to anyone who asks you begin to change the negative attitudes about the efficiency and effectiveness of a BA.

Or take an example of a project similar in purpose, such as a complex enterprise COTS project where many different stakeholders were involved. You already know what type of documentation is necessary and how formal it needs to be. Lessons learned from the prior projects will provide a roadmap for the next.  Another key is to define deliverables necessary based on the project risk and to be secure in advocating those that need to be done to reduce the risk. You are not out to create the perfect requirements document but to ensure you have captured enough requirements clearly and correctly. You are focused on eliciting what needs to be understood and documented (communicated) for project success. Every project has some unique characteristics but many of the same characteristics that can be leveraged to the next effort. Adequate planning based on previous projects is a great way for you to stay in control of all the customary tasks that need to be done and to set proper expectations with the project team and other stakeholders.

Another timesaver is to look for repeating patterns from project to project where you can apply similar solutions. Patterns can be found and not limited to business processes, business rules, data, interfaces, stakeholders, business units, enterprise efforts, types of risks, type of defects, budgetary constraints etc. Look for the sameness in each new project so you don’t spend time reinventing the wheel on each project.

At the beginning of every project taking time to plan the BA activities, consider the project risks, review lessons learned, and pausing to think about any similarities or patterns from prior projects can improve your BA efficiency and value. When you practice repeating certain things time and time again with success you will become more confident in your recommendations and “never let them see you bleed”.

Always have an escape plan
Appropriate time set aside for planning is wonderful for identifying what needs to be done and accomplishing it efficiently for the normal course of events. On every project there is some amount of negative risk, hence we need a well thought out escape plan. One type of escape plan is that the BA is on the alert for business risks and unexpected issues. As mentioned, certain types of risks can be the same from one project to the next. Proactively managing risks on a day to day basis by prioritizing high potential and high impact risks and preparing risk response plans are a great way to have available the necessary escape plan. When negative business risks become a reality it is always better if you have already thought about what to do and have an action plan ready for how the problem will be handled. I think “Q” would be proud!

Another example of being ready for the unexpected is to always work on the most important requirements first. You should always know the priority of the requirements. This is considered a best practice. Then if the project has to all of a sudden be cut short or the analysis time is not enough to complete all requirements, the most important requirements are completed. This practices gives you an elegant escape plan.

Now in summary to mix my metaphors just a bit. I want you to imagine the Mission Impossible music, picture yourself as the BA James Bond, and think of your current project as you recite the mantra of these two rules:

1. Never let them see you bleed and
2. Always have an escape plan!

“Kevin Brennan and I just concluded our 2nd Advisory Board meeting for the joint Business Rules – Business Process – Business Analysis conference to be held in late October-early November, location to be determined.  The discussion with the Business Rules Forum and BPTrends team was quite animated and we covered a few different topics.  One critical decision was made – the name of the joint conference:

Building Business Capability 2010 -Optimizing through process, rules & analysis”

Kathleen Barret

http://community.theiiba.org/profile.htm?mode=pvb&pid=28407&blogId=21

Executives develop strategies and overall goals for success.  These strategies and goals get realized through implementing projects.  Business Analysts have the critical role and responsibility to ensure the solution implemented via the project meets the company’s goals.  Are you feeling it? 

Besides having a good grasp of the techniques available to you as a BA there are two strategies of your own you should employ to make a positive impact.

1)      Lift your head out of the details and look where you are going.  Every now and then make sure your project is still aligned with the company goal(s) it is supporting.  If it is not, raise a flag to make the PM, your manager, and the business sponsor(s) aware.  You and your team should make adjustments to get the project re-aligned or push to have it canceled.  Stopping a project that no longer supports a company goal is a success, not a failure.

2)      Use the support network around you.  In the fast paced environment we work in there is not enough time for you to come up with solutions to the challenges you will encounter on your own. You do not have to do this alone.  At your company you are surrounded by an endless number of subject matter experts, other BAs, project managers, and a wealth of technical knowledge.  That is just the beginning. Look outside of your company and join and participate in local professional organizations like the IIBA.  There is no need to stop there.  Why stay local, when you can go global?  There are so many online communities where you can connect, interact, and learn from like minded people around the world.  Communities like BA Times, Modern Analyst, and a number of LinkedIn groups are great place to get answers to the business analysis questions you need answered.  Think about how valuable you are to a company by not only bringing your knowledge and expertise, but also bringing expertise from around the world.

Being a part of the future success of your company is wonderful.  Even though there is a lot of pessimism with the current economy it is an exciting time to be a business analyst.

To our success,

Kupe

In talking with managers in many organizations, the problem is often caused because the managers have never seen good business analysis work and its value on their projects. As we all know, reading about business analysis work or listening to a lecture on it, doesn’t really give a person a true understanding. We have to experience it. Our managers need to have the experience of being involved with a project where strong analysis work is done and the project success is demonstrated.

As a BA working for a manager who doesn’t understand your value, what can you do? Remember that change happens slowly but it does happen when people see how they benefit from the change. Take any opportunity to show your manager the value of performing analysis. Schedule a meeting to talk about your project where you develop a list of probing questions and have your manager help strategize about where to find the answers. Have him or her talk with you about the business risks and response options. Use a few minutes in a team meeting to discuss stakeholder issues and brainstorm about tactics. People learn by doing, so actively involve your manager in analysis tasks whenever possible and he or she will start to understand the value.

Other suggestions?

I attended a panel discussion on The Developer’s View of the Value of the BA. Daren May from aspenware pointed out several important behaviors of BAs which improve the entire development process. As Brits often do, Daren used a couple of great phrases: BA’s maintain “solution neutrality”, making sure that the business needs are met while being open to various architecture/platform options. He also appreciates the fact that BA’s ask the difficult questions, without alienating anyone and that they are “absorbed in  the culture” of the business so they really understand the impacts of software changes to the business.

Tony Chen of Sielevel gave a great presentation on Agile which included a Lego Helicoper build exercise! He gave each group different requirements and we all saw the various results. My team got a textual description of how to build the helicoper and failed miserably!!

Afternoon sessions included BI, business case development and relationship topics. I am on my way to Day 2 so I’ll write more later . . .

Let me give you just a few of the reasons that I LOVE status reporting!

 1. BAs get the opportunity to “toot their own horn”. We all do hundreds of little tasks every week, in addition to our big projects but often only the big things are noticed. A status report is an opportunity for you to let your manager know about the other important, yet small tasks you are doing. For example, when one of your past business stakeholders calls to ask your advice and you spend a half of an hour doing some research for them you are improving your organzation’s business. Let everyone know!

2. Status reports are a great record/history of work done and time needed. I don’t know about you but I don’t remember everything that I did last year. When I want to go back to review the time needed to perform a certain task, or remind myself of what type of projects I was involved I always have a great, detailed record available. This is very useful at performance review time and when its time to recertify for your IIBA CBAP and PMP. Status reports are also a great resource if you have to update your resume.

3. Reviewing your list of assigned projects each week forces you to stay focused on your priorities. Your status report should include due dates so that you can measure your progress on large tasks. Describing the work that you did during the previous week also helps you to plan for the next week. The report reminds you to do things that had gotten pushed aside during a critical time.

4. Best of all, making notes about the work that you have accomplished gives you a good feeling. We sometimes get too focused on all of the things that we haven’t finished and forget about all of the work we completed. Pat yourself on the back at the end of the week and write a status report for yourself!