My name is Aaron Whittenberger. I have over 25 years of business and IT experience, including 13 years as a consultant. I came up the Application Software Development path on the IBM Midrange platform. Then I moved to doing cross-platform interface design and development. From there I joined the Project Management and Business Analysis arena; and have earned my Certified Business Analyst ProfessionalTM (CBAP®) certification. I will be using my blog to describe the changes I see in the IT Consulting space as it transforms from the traditional technical role to a more business and analytical role in this dynamic economy.My name is Aaron Whittenberger. I have over 25 years of business and IT experience, including 13 years as a consultant. I came up the Application Software Development path on the IBM Midrange platform. Then I moved to doing cross-platform interface design and development. From there I joined the Project Management and Business Analysis arena; and have earned my Certified Business Analyst ProfessionalTM (CBAP®) certification. I will be using my blog to describe the changes I see in the IT Consulting space as it transforms from the traditional technical role to a more business and analytical role in this dynamic economy.My esteemed colleague, Kupe Kupersmith, wrote an article for BA Times last week stating that “Agil
e is a Fad”. Now I know that will get a few of my other friends’ up in arms ready to defend their approach to IT project work. I can see the smoke coming out of their ears now. However, if you read Kupe’s article he says that “the word agile is a fad, the agile movement is definitely a trend.” I think it is safe to say that Agile is the hottest trend in IT project work these days. Many companies have switched over to Agile over these past few years and many more companies are considering the move. It has prompted many training courses by education providers. So let’s take a deep, hard look at the Agile “movement” and see if it is a fad, or is it here to stay? Is Agile really any better than Waterfall? What is the next best thing that will come down the pike?
Agile came upon the IT application development and software requirements arenas like a wave, gaining support as it moved. As education providers developed courses to teach IT application development teams to “go agile”, it gained momentum. All this happened in these past few years in very much Fad style. A fad starts very abruptly and gains momentum as it moves, forceful and overpowering; like a wave. Will Agile be here with the wave reverses course and heads back out to sea? This is where the fad loses its zest, when people realize that this is no better than what we had before, or it is swept over by the bigger and stronger wave of the next best fad to come down the pike. The wave reverses course and heads back out to see and disappears as fast as it appeared.
Is Agile better than what we had before (Waterfall)? I won’t even go there because depending on who you ask, you will get a different answer. You could ask 100 people and probably get somewhere near 50 yes’ and 50 no’s. That is built quite a bit on personal opinion. The one thing I notice with Agile as it is used today is that it is misapplied by many companies. They talk agile and think that they are using agile, but in reality they have adopted some of the components of agile, such as sprints, scrums and the daily stand-up meeting, but they miss the boat on delivering a piece of working software at the end of each sprint. When your five minute daily stand-up meeting becomes 15 or 20 minutes, all you really have accomplished is keeping your application development team from doing actual work. There are other places that say they are agile, but their sprint is six months long. According to the principles of Agile a sprint should be a couple of weeks to a couple of months long, with a preference to shorter timescale. So a six month sprint is not agile.
The biggest downfall to the Agile principles that I have seen in my experience is the need for comprehensive engagement of the Product Owner. In my experience, Business managers have a business to run and helping IT develop software is not in their job description, they don’t want to talk to the geeks. However, the smart Business managers know that if you don’t talk to the geeks, hard telling what you are going to get out of them. They need more direction than one sit down meeting saying “here is what I need”; and we will not go into the language barrier. If you can’t make IT understand what problem you are trying to solve, then you probably will not get the best IT business solution out of them.
So, is Agile just a Fad? Through all its misapplications and shortcomings, I don’t see agile going away anytime soon. It will not whisk away with the outgoing tide. Is Agile the “Be All of All”? There are some things that you just cannot develop with an agile approach. Some companies have developed a hybrid of the agile and waterfall approaches, so Agile is not the answer to all of IT’s business solutions problems. What will the next great approach be that comes down the pike? My crystal ball is not working today, but it is sure to hit the IT project management world just the way Agile did a few years back. Will IT management be ready for it? Only time will tell.
If you really think about what the Business Analyst (BA) is asked to do on a day in and day out basis, we truly are as Sanjay Dugar puts it--“A Leader Without the Title”. The Project 
Manager (PM) is asked to see that the project completes on time and on budget. The Business Analyst is asked to see that the project completes and that the solution meets the business requirements. The PM creates the project schedule and the whole team knows that they are in charge. The Lead BA may create a Business Analysis Work Breakdown Structure (WBS), if necessary, and defines the business requirements for the project. This ‘relationship’ becomes very interesting, perhaps messy would be a better word, if the PM tries to short cut tasks, such as testing or analysis, to keep a project on schedule and/or on budget. After all he/she is the “Manager”, he/she is in charge. What is the “Analyst” to do?
Quite often in their daily work the BA is placed in a position where they must influence a person or group of people without being given the proper authority to do so. So how does the BA go about doing this? This is where the BAs listening, negotiation, conflict resolution and Interpersonal Savvy skills will serve them. Remember, You don’t have to be a ‘person of influence’ to be influential.
When placed in this situation, where you must now influence a person or group of people, and you are not the “leader” of the group, or you must lead a group down a path to understanding your desired outcome, put a few tools in your toolkit that will help in this situation:
- Understand the situation, or both sides of the story
- State the facts Ma’am, just the facts
- Be flexible, adapt to change
- Don’t use office politics…first
- Create shared vision
Understand the situation, or both sides of the story. Remember that there are always two sides to the story. Before you go and try to change the story, be sure you understand both sides of the story, not only the point of the story but the reasoning behind it. A good analogy would be “don’t tear down the fence until you know what it was built to keep in, or out”. After tearing down the fence would not be a good time to find out you have a raging stampede heading for you. Not only listen to the other side of the argument, but understand the point and the reasoning behind that point. Then you can make an informed decision on the path to take from there.
State the facts Ma’am, just the facts. When persuading people, make your point, back up that point with hard facts from authorative sources and draw the picture of how the facts back up your point. I had the opportunity to help a person get better at this. His theory was he like to surprise people with “the big bang”, so he would hold on to the point and lead up to it. By the time he got to “the big bang” the audience had to draw their own picture from the facts to the point. If you leave people to get from point A to point B on their own, some will make it some won’t, and some may finally get there after a number of detours. When it comes to persuading, state your point first, then back it up with cold hard facts. Give the audience the destination first so they can more easily connect the dots. When backing up your point, take the emotion out of the way, use facts. Take the emotion out of your argument, but don’t take away your passion.
Be flexible, adapt to change. Sometimes yielding to the other side is the proper thing to do in light of the facts. You may back up your point with corporate policy, standard operating procedure (SOP), or that’s the way we have always done it; but once you have allowed the other point of view to be heard and the reasoning behind it you may note that this does go against SOP, but it has potential for a positive outcome by reducing the project timeline without increasing the risk of the project. When attempting to persuade, be sure that you are flexible enough that you may be persuaded. Having two parties that can not be persuaded, you can not create a win-win situation. Remember, the party has to win is the organization.
Don’t use office politics….first. We have often heard about the office end-run or going over the head of a person to get what you want. When the time comes such tactics may be necessary, but do not use these as first course of action. You will loose respect of team members and stakeholders if you become known as playing the office politics game. If the conflict is with one other individual, take the case of the PM wanting to short-cut analysis in order to save time and budget, then take the case to that individual first. As stated above, not only understand their point but the reasoning behind their point. If you do not agree, then make your case. Make them understand your point and back up your point with facts. It may take several back and forth’s to accomplish full disclosure of both sides of the story. However, do not let this deteriorate into an adversarial situation. At some point, it may be necessary for you to open this issue with your Manager to handle with the PM’s Manager.
Create shared vision. When persuading use your words, your passion and any necessary audio/visual props to draw a picture for the audience of the desired outcome that you are working toward. Draw the picture in everybody’s mind so clear that they see it as well as you do. Creating shared vision when influencing others is a powerful tool and the clearer they see the picture, the more persuasive you become.
I am often asked for advice on BA Career paths, Certifications, What technique to use, templates, tools, and so on.. It seems to me that everyone is looking for that “One size fits all” solution on how to perform the role of the BA. The one path up the BA Career Ladder, the one way to go about getting your certification, should I learn DOORS, RequisitePro or Composer?
One thing that I have learned in my many years of doing BA work is that there is no “One size fits all” way of delivering the BA role. Your BA approach will be different depending on the type of project you are involved in. It will differ for a COTS project vs. Capability Gap Analysis. Your approach and tasks that you perform will be different if you are doing enhancements to an ERP system vs. a Vendor Assessment. The techniques you use would be different as well as the templates you may use.
Robin Grace handled the template issue in her article on BA Times entitled “It’s Time for Template Zombies to Die”. Often BAs looking for a template to use will get one from a friend that works for a much larger firm, or a new hire BA brings one with them from a larger firm. The smaller firm uses the template as is, even though there are sections that do not pertain to the type of BA work that the firm does. It may be at times Management will ask “It took you three days to write a two-page document?” Sometimes the response is to make the document 10 pages, and all you have done is added a lot of fluff with no meat. Often, that fluff ends up in the template for the document. Instead of adding fluff, remind Management, “it is more than just writing a document; there is quite a bit of analysis done to make that document right”. Often people go by what they see and forget about the work done behind the scenes to get to the deliverable. When you do come across a template to use remember this is just a guideline, it can be changed to fit your current situation. Feel free to remove, add or reword sections of the template to make it usable for your task.
I have written many times about the BA Career path. In my last article, I surmised that there are as many paths up the BA Career Ladder as there are people willing to forge them. Getting career advice from those that have gone before you is great and can help you forge ahead, but it does not mean there is one and only one way to climb the career ladder. Advice is helpful, but you are still in charge of your career.
So in any given situation, instead of looking for the “correct” way to handle the situation, do what any good BA would do. Identify and consider all possible solutions, expand your knowledge so you can assess all possible solutions, identify the risks of each solution and select the best possible solution given the knowledge you have at the time. Remember, the “One size fits all” solution does not exist.
Still a very timely topic of discussion, from the person who wishes to transition into a Business Analysis career who wants to know what skills they must have to be a successful BA, to the new BA who wants to know what skills they need to add to their repertoire, to the Senior BA who wants to know where to go next in their career; everyone wants to know how to improve their skills to get to that next level of their career.
Two of my colleagues take on this subject, Kupe in BA Times discusses soft skills vs. hard skills. He notes the importance of soft skills in being a successful BA. Kupe is not suggesting hard skills are not important, he notes that hard skills is what is going to get you noticed, stand out in a crowd, but it is the soft skills that will land you on that next level and keep you there. After all, nobody wants to work with a jerk.
Laura discusses whether Project Management is the next step in the career of a Senior BA at Bridging-the-Gap. She discusses how this use to be the case years ago but is no longer the only option. In fact, we now see the reverse happening where Project Management professionals transition into Business Analysis careers. For those who have reached the pinnacle of their BA career, besides Project Management, they could move into BA Management, creating a BA Office within their organization, Enterprise Analysis, Management Strategic Consulting, Business Consulting, Business Subject Matter Expert or external IT and Business Management Consulting. There are as many paths as there are people willing to forge them.
Elizabeth Larson will be taking on a similar topic at the Southwest Ohio Business Development Conference in April. She will discuss whether Business Analyst and Project Manager should be one or two roles within the organization. At this very same conference I will be presenting the topic “Improving Your BA Skills: From Self-Assessment to Self-Improvement”. This is where I will discuss the many ways you can gain new and improve current BA skills. This is a conference not to be missed if you are in the Cincinnati area on April 29, 2011.
This topic has been around for many years and as you can see is still a very hot topic today, getting a lot of press. There is no one way to build your career, forge your own path. Remember you are in charge of your career. Unemployment, downsizing or IT outsourcing may derail your plans for a time, but don’t allow that to stop you permanently. For some general guidelines, as Kupe suggests, develop the hard skills necessary to accomplish the tasks of a BA and get you noticed. Then develop the soft skills that will land you on that next plateau of your career. Remember, that your current job is not your career, it is just your current position in your career; you decide where to go next. Let your passions guide you. If Project Management doesn’t excite you, good; now you have other options to continue your career.
ESI International, a premiere education provider in the fields of Business Analysis and Project Management; and an Endorsed Education Provider (EEP) of the IIBA® held an educational webinar in which they laid out the “Top 10 Business Analysis Trends for 2011”. Presenting these top 10 trends was Glenn R Brule, CBAP, CSM, Executive Director of Global Client Solutions for ESI International. ESI’s Top 10 Trends for Business Analysis are:
1. Business Architecture will be the primary focus of business analysts
2. Business Analysis will guide the surge in cloud computing
3. Requirements management and development (RMD) will lead in delivering smart business perspective
4. Business Process Modeling Notation (BPMN) will solidify its reputation as the industry standard
5. Agile success will go to those willing to break with tradition
6. BAs will be recognized as the critical change management proponent to avoid troubled projects
7. Resurgence of Centers of Excellence
8. RMD will be essential to regaining market share
9. RMD will continue to struggle to define itself
10. RMD will require better balanced competencies
These trends show a bright 2011 for the Business Analysis profession. As businesses strive to remain competitive, increase efficiencies and regain market share in the improving US and world markets Business Analysts will be critical in examining the inner workings of organizations, model those processes and help businesses resolve roadblocks to its strategic initiatives. I believe we shall see increased emphasis put on process modeling and other “hard” skills over the soft skills previously sought in BAs. I am not sure we will see a great resurgence of BA Centers of Excellence but BAs will be required to find a structured yet flexible approach to requirements management and development that help organizations find those increased efficiencies.
Those of you who follow my ramblings know that I have been a strong proponent for Enterprise Analysis and the strategic value of the Business Analyst within the organization. My views can be ascertained from my previous articles:
BA: Business Alignment for the Organization
Business Case vs. Project Charter; Do You Need Both?
Business Analysis has far reaching impact on the Organization
IT Governance Needs to Change to Gain a Competitive Advantage
Making the Business Case for an Internal BABOK
Building the Business Case for the Business Case
Business Analysis: Building the Bridge
Yet, as the International Institute of Business Analysis (IIBA®) grows in recognition, I find that many organizations, especially SMBs, do not utilize the BA role for strategic value. Most organizations have BAs and use them in their traditional tactical role on projects in requirements gathering and solution validation; but very few organizations utilize the BA role for Enterprise Analysis.
As the framers of the Business Analysis Body of Knowledge® (BABOK®) sit down to write version 3.0 of the BABOK® Guide and continue to work on the Enterprise Analysis extension to the BABOK® Guide, I hope that they put particular emphasis on this very important BA role. Perhaps companies will take note and start to utilize their BAs to help the organization achieve its strategic goals.
The BABOK® Guide does mention tasks that a BA may perform under Enterprise Analysis, including but not limited to Capability Gap Analysis, Market Research and Feasibility Studies. However, it falls short of describing how the BA should perform their strategic duties. The BA having performed the Enterprise Analysis task(s) builds a business case, resulting in a Business Case document, for a solution to resolve a business need of the organization identified during the Enterprise Analysis activity. This business case is presented by the Project Sponsor to the project review board (governance body) for approval to proceed with the project. The Enterprise Analyst (EA), having performed the up-front analysis that resulted in the business case, should sit in support of the business case and the Project Sponsor. He/she should be available at the presentation to answer any questions the governance body may have concerning the business case.
The EA also works with the governance body to ensure that every business case brought up for approval has traceability back to the organization’s strategic goals and objectives and that the most optimal mix of projects get approved that best contributes to the organization’s strategic goals. This would be a portfolio of projects that do not conflict with each other and advances the organization the best in achieving its strategic goals.
When we see organizations utilize the EA role more effectively perhaps we will see better project success rates in the Standish Group’s CHAOS Report.
For those of you who have wondered where I have been, I am happy to say that I was in the Bahamas. I took a long deserved vacation with the family to the Bahamas. The cruise and the trip were excellent. Now I come from the 80 degree sunny weather of the Bahamas and Florida to the 20 degree snowy weather of Cincinnati, it just doesn’t seem fair. No, I was not in the Bahamas for a month or two months, but getting caught up with everything takes time.
Recently, I have been pondering the question “Has IT become irresponsive to business requests?” As I go from organization to organization I look at the time it takes from 
request to solution implementation and I am dumbfounded. For those of us who have been in application development services for awhile remember that what use to take a day now takes a week, or longer. Yes, we have things like Sarbanes-Oxley (SOX) and other regulations to thank for this; but also I see that organizations themselves put so much process into their developing of IT business solutions, that the time to fill a business request gets longer and longer. Let’s take a look back to see how this happened.
In the beginning there was chaos. The business manager, needing a widget, made a request to the IT manager, the IT manager handed down the request to the developer, who spoke this language called “techie”. In three days, the business manager needing his widget, went to the IT manager and asked “Hey, where is my widget?” The IT manager replied, “I will find out for you”. He went to the developer and asked ‘Where is the widget?”, and the developer handed him a midget. The IT manager said “I am not sure this is what he wanted”. The IT manager returned to the business manager with the midget. The business manager said “That is not what I asked for, can’t you understand plain ‘biz talk’?” He further inquired, “Why couldn’t you tell me when it would be done and stop the developer when he started building the wrong thing?” The IT manager said “I need help!” and chaos ensued.
Then The Project Manager (PM) stood up and said I can help. I can put together a project schedule and draw pretty pictures for you that will tell you exactly when that IT business solution will be done. The IT manager said “I like pretty pictures, yes do that”. So the business manager made a request to the IT manager for a fidget. The IT manager handed down the request to the PM. The PM made a project schedule, carefully drafted a project scope, wrote a communication plan and a risk mitigation plan and made deadlines and milestones. He then showed all his work to the IT manager who looked at it in awe. Then the PM handed all his work to the developer who stripped out just the parts he needed to create the widget. In seven days, the business manager needing his fidget, went to the IT manager and asked “Hey, where is my fidget?” The IT manager showed the business manager all that the PM created and the business manager looked at it in confusion. The IT manager said, this says your fidget will be done in two days. The business manager said, at least now you can tell me when it will be done, but what is taking so long? So now they have structure to the chaos. In two days the IT manager delivered the widget to the business manager and the business manager said “that is not a fidget, what is wrong with you?” The IT manager said I do not understand what you want.
So the Business Analyst (BA) stood up and said I can help. He said your application development team speaks “techie” and the business people talk “biz talk”. I speak both languages and can translate what the business is asking for into “techie” for the development team. The IT manager said “Yes, do that”. So the business manager requested a zidget from the IT manager. The IT manager handed the request down to the BA and the PM. The BA went and talked to the business manager and said “tell me about this zidget you want”. He made long lists of requirements and definitions of what a zidget is. Meanwhile, the PM made his project schedule, full of scope, plans and drawings. The BA went to the PM and handed him all the requirements and said this is what the business means by a zidget. The PM handed all that the BA and the PM had created to the developer who stripped out just the parts he needed to create this zydget. In ten days, the business manager needing his zidget, went to the IT manager and asked “Where is my zidget?” The IT manager showed the business manager all that the PM and BA had created, who looked at it in great confusion, and stated “Is that what I asked for?” The IT manager said “Yes it is, and it will be ready in two days”. The developer showed the finished zydget to the BA, who stated “this is not quite right, make a little change here”. So the developer did as the BA said. In two days the IT manager delivered the zidget to the business manager, who declared “Look you got it right!”
The above story does not really account for the time and effort that Quality Control and Production Change Control put into the process. So it is easy to see why a day has become a week, or longer; and make it appear as if IT has become irresponsive to business requests. However, in most organizations the above is the normal process, we call project life cycle (PLC), to get an enterprise application development change made. Most organizations have emergency procedures that circumvent the normal procedures to get a change made quickly. More and more I see those emergency procedures being used. What does this cause, new production change control processes and validation, which usually translates into more people. So what can be done to improve this process? Go back to Chaos?
Today I read a couple of blog posts concerning the qualities to look for in Consultants. The first blog titled “Top 10 Qualities Of A Great Consultant” listed Does the consultant have non-profit experience as the first quality. I was ready to fire off my reply, but as I kept reading I realized that this was written for the non-profit sector. The second blog titled “10 Qualitie
s To Look For When Hiring Consultants” listed several qualities that would be very difficult to “look for” prior to hiring the consultant. It would be very difficult to pose questions during an interview to gage the Consultant’s A Penchant for Facts, Sift and Filter Out, Think Ahead, Precision, Self Discipline or Honest to a Fault. Also if you do not need the consultant to fulfill a leadership role within the organization or IT business solutions team then Leadership is not a quality to look for in applicants.
My colleague, Jeff Welsh, wrote a two piece blog on the "Seven Deadly Sins of Consulting", in which he notes the seven things that a Consultant should never do when engaged at a client. A lot of them are common sense things and some of them come from experience. After reading all these blogs, I have compiled a list of qualities to look for in applicants for a BA role within your organization. Questions can be formed during an interview to help gage the applicant’s ability in these areas.
1. Depth and breadth of experience and knowledge
A review of the resume/CV will show the applicant’s prior work experience. The more senior, critical or strategic activities you wish the consultant to perform, the greater work experience and knowledge you will want the consultant to have. Also, ensure the consultant’s work experience is relevant to the tasks you will ask the consultant to perform. Such as, if you are implementing a new ERP package, find a consultant that has done ERP implementation projects.
2. Dedication to profession and work
The BA Consultant should have great dedication to the BA profession and to his/her own work. A consultant that stays abreast of BA resources, keeps up-to-date on training and/or has achieved BA certification is showing dedication to the profession. Every business person should take great pride in their work and deliverables. The BA Consultant is no different.
3. Excellent communication skills and interpersonal savvy
Effective communication is essential for Consultants. Oral and written communication skills are a necessity. Communication to the client should be relevant and timely. Miscommunication and Under communication to the client tend to shorten your stay at the client. One of the posts noted above stated “Honest to a Fault”. Sometimes, blunt honesty backfires and cause greater issues. Finesse and tact should always be practiced when handling sensitive issues.
4. Customer focused
All Consultants, including BA Consultants, should always be focused on delivering value to the customer. During the interview probe the Consultant’s commitment to the customer.
5. Results oriented
The BA Consultant should be dedicated to delivering results. If the applicant’s resume/CV does not show their achievements and results then probe the Consultant’s dedication to adding value and delivering results in a timely manner during the interview.
6. Can see the “big picture” and work in the details
Having the “big picture” view, knowing how your activities fit into that picture, and then being able to work in the details of your activities is truly an art. Consultants are often asked to perform the tedious tasks, such as research and document activities that require hours of repeating processes. It is not glorifying or high-profile work, but necessary to be completed. Being able to go beyond customer expectations doing these kinds of tasks is a way to prove your value to the client. While working in the details, not taking your eyes off the big picture and ensuring that decisions are made that keep the big picture in tact is also an art.
7. Team player
Personality conflicts are always detrimental to the team unity. Bringing on Consultants that do not work well with the team causes people management issues and divert resources to handle those personality conflicts rather than more productive activities. Derogatory comments about other consultants, or worse the client’s employees, is a fast track to causing team conflict. As Jeff puts it “don’t be a prima donna”.
8. Creative thinking
Sometimes solutions to complex business problems require the ability to leap beyond conventional thinking. They require creative solutions that require creative and conceptual thinking. Situational questions can devolve the Consultant’s ability to “think out of the box”.
9. Personal organization
Being personally organized helps deliver results sooner. Having to continually search for documentation or other items can be a great waste of time. Being able to remember meeting appointments and being on time to meetings show a good degree of personal organization.
10. Dependable
Being where you are suppose to be at the time you’re suppose to be there is a great attribute for Consultants. Being punctual really is greatly appreciated by the client, so when you are going to be late to work or an appointment communicate the delay. That too is appreciated.
So if you are responsible to bring in consultants to help your IT business solutions staff you have some guidelines to look for when determining who to bring in to complete your IT staffing. If you are a BA Consultant make sure you exceed customer expectations in the areas above and you will have a satisfied customer.
s To Look For When Hiring Consultants” listed several qualities that would be very difficult to “look for” prior to hiring the consultant. It would be very difficult to pose questions during an interview to gage the Consultant’s A Penchant for Facts, Sift and Filter Out, Think Ahead, Precision, Self Discipline or Honest to a Fault. Also if you do not need the consultant to fulfill a leadership role within the organization or IT business solutions team then Leadership is not a quality to look for in applicants. My colleague, Jeff Welsh, wrote a two piece blog on the "Seven Deadly Sins of Consulting", in which he notes the seven things that a Consultant should never do when engaged at a client. A lot of them are common sense things and some of them come from experience. After reading all these blogs, I have compiled a list of qualities to look for in applicants for a BA role within your organization. Questions can be formed during an interview to help gage the applicant’s ability in these areas.
1. Depth and breadth of experience and knowledge
A review of the resume/CV will show the applicant’s prior work experience. The more senior, critical or strategic activities you wish the consultant to perform, the greater work experience and knowledge you will want the consultant to have. Also, ensure the consultant’s work experience is relevant to the tasks you will ask the consultant to perform. Such as, if you are implementing a new ERP package, find a consultant that has done ERP implementation projects.
2. Dedication to profession and work
The BA Consultant should have great dedication to the BA profession and to his/her own work. A consultant that stays abreast of BA resources, keeps up-to-date on training and/or has achieved BA certification is showing dedication to the profession. Every business person should take great pride in their work and deliverables. The BA Consultant is no different.
3. Excellent communication skills and interpersonal savvy
Effective communication is essential for Consultants. Oral and written communication skills are a necessity. Communication to the client should be relevant and timely. Miscommunication and Under communication to the client tend to shorten your stay at the client. One of the posts noted above stated “Honest to a Fault”. Sometimes, blunt honesty backfires and cause greater issues. Finesse and tact should always be practiced when handling sensitive issues.
4. Customer focused
All Consultants, including BA Consultants, should always be focused on delivering value to the customer. During the interview probe the Consultant’s commitment to the customer.
5. Results oriented
The BA Consultant should be dedicated to delivering results. If the applicant’s resume/CV does not show their achievements and results then probe the Consultant’s dedication to adding value and delivering results in a timely manner during the interview.
6. Can see the “big picture” and work in the details
Having the “big picture” view, knowing how your activities fit into that picture, and then being able to work in the details of your activities is truly an art. Consultants are often asked to perform the tedious tasks, such as research and document activities that require hours of repeating processes. It is not glorifying or high-profile work, but necessary to be completed. Being able to go beyond customer expectations doing these kinds of tasks is a way to prove your value to the client. While working in the details, not taking your eyes off the big picture and ensuring that decisions are made that keep the big picture in tact is also an art.
7. Team player
Personality conflicts are always detrimental to the team unity. Bringing on Consultants that do not work well with the team causes people management issues and divert resources to handle those personality conflicts rather than more productive activities. Derogatory comments about other consultants, or worse the client’s employees, is a fast track to causing team conflict. As Jeff puts it “don’t be a prima donna”.
8. Creative thinking
Sometimes solutions to complex business problems require the ability to leap beyond conventional thinking. They require creative solutions that require creative and conceptual thinking. Situational questions can devolve the Consultant’s ability to “think out of the box”.
9. Personal organization
Being personally organized helps deliver results sooner. Having to continually search for documentation or other items can be a great waste of time. Being able to remember meeting appointments and being on time to meetings show a good degree of personal organization.
10. Dependable
Being where you are suppose to be at the time you’re suppose to be there is a great attribute for Consultants. Being punctual really is greatly appreciated by the client, so when you are going to be late to work or an appointment communicate the delay. That too is appreciated.
So if you are responsible to bring in consultants to help your IT business solutions staff you have some guidelines to look for when determining who to bring in to complete your IT staffing. If you are a BA Consultant make sure you exceed customer expectations in the areas above and you will have a satisfied customer.
This month I have been exploring the IT and Business working relationship. It is a hot topic these days getting a lot of press. STAR BASE Consulting is conducting a pulse survey asking what is the relationship like in your organization. BA Times notes that your “Customers Don’t Want to Work with You!” A couple of weeks ago, I looked at the relationship and how BAs could reduce the rivalry, if there is one. Last week I took the relationship to the Organizational level and described how the Organization can build a unified, collaborative team.
You say Organizational Structure, Seating Charts, Enterprise Analysts (EA) and Business Analysts (BA) are all find and dandy, but what about me and my small IT shop? I don’t have enough people to split into EAs and BAs. How do you split one person? Small-to-Medium Sized Businesses (SMBs) usually have an IT shop of 10 people or less. Maybe at most 2 of them will be BAs. I even had one CIO recently tell me that in his small shop he doesn’t really have full-time BAs, but five Programmer/Analysts that do their own analysis. So we will assume these are the hybrid Developer/Business Analyst role within the organization. So in this kind of structure, how can we improve the IT and Business working relationship?
In SMBs, where resources are scarce, it is not uncommon for people to perform multiple roles or “wear many hats” within the organization. In today’s economy, where IT spending and salaries have stalled but the workload has not: IT is getting even more squeezed. In this situation, when the SMB cannot make one of its BAs the strategic role (EA), or perhaps the organization does not need full-time enterprise analysis activities going on, it becomes even more crucial for the BAs to assist in building a unified, collaborative working relationship between IT and the business. So let’s look at some of the key points I have discussed in the past two weeks.
Seating Chart - Two Desks
When looking at this seating chart you realize that there is only one person, so you only need one desk, correct? Allowing the BA to have a desk in the IT Department and one in the business unit of the organization allows them to build a working relationship with each team. By spending part of the day or week with each team, the BA can understand the challenges each team faces. Even if the BA can spend only part of his/her time sitting with the business unit that they are suppose to support, it helps build awareness of the daily challenges that the business people face on a daily bases. This helps the BA identify business needs to improve business processes and make the business run smoother. This also makes the BA approachable by the business people to assist to work on problems and will help get buy-in from the business people when the BA has analysis tasks that require business input.
Communication is Key
Communication is a key skill for a BA, but becomes even more important in this situation. The trap that the BA must avoid is the business feeling that the BA is approachable only when he/she is sitting at the desk in the business area. Or that the BA is available for IT project work only when he/she is sitting at the desk with the IT business solutions development team. The BA must communicate to both teams that he/she is available whenever they need assistance; it is their goal to assist. The BA also must represent the needs, desires and limitations of each team to the other. Make the IT application development team understand the business requirements and why these requirements are needed. Make the business understand the time involved to make “a simple change” to an enterprise application. By representing each team to the other, and making each understand the work at hand, whether that is requirements or solution testing, they are creating a shared vision across the organization.
Build the Bridge
Through effective communication of the needs and limitations of one team of the business to the other and representing the each team to the other the BA can build a bridge of understanding between the two groups. By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.
Whether in a large organization or SMB, business must go to IT for technology solutions. Even in an IT Outsourcing situation, there are on-site IT people to directly talk with the business people. In SMBs, where resources are less and people “wear many hats”, the BA role of liaison becomes more important to overall IT business solutions success.
Last time I took on the subject of IT and the Business working relationship. Is it an “Us vs. Them” relationship or a collaborative, mutually beneficial working relation where you appear to be on the same team. Now I wish to take a look of this subject from the organizational perspective.
Kupe recently wrote on this subject at BA Times, where he discusses the point of whether your “internal customers” really wish to work with the IT department. So how does the Organization get rid of the “Us vs. Them” mentality within the organization?
Organizational Structure
Take a look at the Organizational Structure, do the Business Analysts (BA) within the organization report to a single Manager or Director, or are they dispersed throughout different departments of the organization. Do they report up to a Business or the IT Manager/Director? If they report to business, are they perceived as part of the business or business partners to work with the IT folks to achieve technology solutions. How are they perceived by the IT Team, as their business partners, SMEs or IT folks that are the “business-face” of IT. If they report to IT, how do the business units perceive them, as IT employees that they must work with to get technology solutions.
I have work in organizations that have had each reporting structure. I have had a third structure suggested to me, where the Business Analysis Office (BAO) is a separate unit within the organization that does not report to either the business or IT. Would this make them perceived as an independent unit to assist both the business and IT in achieving needed IT business solutions?
Seating Chart
Even if you decide that the organization is best served by the BAO reporting to IT, where should your BAs sit, within the IT Department or with the business units they are to support. One of the roles of the BA is to identify business needs and make a business case for a solution to that need. To do so, the BA should sit with the business people that perform the day-to-day tasks of the business. The BA needs to understand the daily challenges of the business and they can not do that tucked away in the IT Department.
I actually recommend splitting the BA role within the organization into two roles: Enterprise Analyst and Business Analyst (Business Systems Analyst).
Enterprise Analyst
The Enterprise Analyst (EA) would be the analyst that needs to sit with the business to understand the day-to-day challenges that the business people within the organization. They work with the business people to identify gaps that need filled and competitive advantages that can be gained. These are the analysts that will perform market analysis, capability gap analysis, SWOTs, feasibility studies and so forth to help identify business needs. They then build the business case for a solution, business or IT, to that business need. The EA should support the business case, being the one that knows the most about the case, before the governance body (Project Review Board). Once approved, they turn the business case over to the Project Management Office (PMO) and a new project is born.
Business Analyst
Business Analysts (BA) work with the PMO and IT enterprise application development team to make the solution to the business need a reality. The BA may report to the PMO or as suggested above to a separate BAO within the organization. This BA would take the business and functional requirements defined by the EA and refine them to give more detail to the application development team to help define the solution. The BA could use the EA or other business partner as the Subject Matter Expert (SME) during the project lifecycle.
The EA is the strategic role and the BA is the tactical role of business analysis. The EA helps the organization achieve its strategic goals through enterprise analysis activities. Unfortunately, this is the role of business analysis that most organizations are missing. This with a lack of an internal Business Analyst Body of Knowledge and Enterprise Architecture keep more than just the BAs within the organization repeating processes that cause a great waste of time. So every organization should strive to have both roles of business analysis performed for the organization. Ensure that enterprise analysis activities are being performed to further the strategic goals of the organization.
Kupe recently wrote on this subject at BA Times, where he discusses the point of whether your “internal customers” really wish to work with the IT department. So how does the Organization get rid of the “Us vs. Them” mentality within the organization?
Organizational Structure
Take a look at the Organizational Structure, do the Business Analysts (BA) within the organization report to a single Manager or Director, or are they dispersed throughout different departments of the organization. Do they report up to a Business or the IT Manager/Director? If they report to business, are they perceived as part of the business or business partners to work with the IT folks to achieve technology solutions. How are they perceived by the IT Team, as their business partners, SMEs or IT folks that are the “business-face” of IT. If they report to IT, how do the business units perceive them, as IT employees that they must work with to get technology solutions.
I have work in organizations that have had each reporting structure. I have had a third structure suggested to me, where the Business Analysis Office (BAO) is a separate unit within the organization that does not report to either the business or IT. Would this make them perceived as an independent unit to assist both the business and IT in achieving needed IT business solutions?
Seating Chart
Even if you decide that the organization is best served by the BAO reporting to IT, where should your BAs sit, within the IT Department or with the business units they are to support. One of the roles of the BA is to identify business needs and make a business case for a solution to that need. To do so, the BA should sit with the business people that perform the day-to-day tasks of the business. The BA needs to understand the daily challenges of the business and they can not do that tucked away in the IT Department.
I actually recommend splitting the BA role within the organization into two roles: Enterprise Analyst and Business Analyst (Business Systems Analyst).
Enterprise Analyst
The Enterprise Analyst (EA) would be the analyst that needs to sit with the business to understand the day-to-day challenges that the business people within the organization. They work with the business people to identify gaps that need filled and competitive advantages that can be gained. These are the analysts that will perform market analysis, capability gap analysis, SWOTs, feasibility studies and so forth to help identify business needs. They then build the business case for a solution, business or IT, to that business need. The EA should support the business case, being the one that knows the most about the case, before the governance body (Project Review Board). Once approved, they turn the business case over to the Project Management Office (PMO) and a new project is born.
Business Analyst
Business Analysts (BA) work with the PMO and IT enterprise application development team to make the solution to the business need a reality. The BA may report to the PMO or as suggested above to a separate BAO within the organization. This BA would take the business and functional requirements defined by the EA and refine them to give more detail to the application development team to help define the solution. The BA could use the EA or other business partner as the Subject Matter Expert (SME) during the project lifecycle.
The EA is the strategic role and the BA is the tactical role of business analysis. The EA helps the organization achieve its strategic goals through enterprise analysis activities. Unfortunately, this is the role of business analysis that most organizations are missing. This with a lack of an internal Business Analyst Body of Knowledge and Enterprise Architecture keep more than just the BAs within the organization repeating processes that cause a great waste of time. So every organization should strive to have both roles of business analysis performed for the organization. Ensure that enterprise analysis activities are being performed to further the strategic goals of the organization.
STAR BASE Consulting is conducting a new pulse survey this month asking the question “is there really a rivalry between IT and Business or is this all just sensationalized hype?” I am very interested in seeing the results of this survey, but I believe I can predict the results. In almost every organization I have ever worked in the “Us vs. Them” culture existed. The relationship between IT and Business was more segregated, even adversarial at times, than that of a partnership.
Kupe tackles this topic this week on BA Times, where he discusses creating an environment in which the business wants to work with IT to derive technology-driven solutions. Doug Goldberg does an in-depth analysis of the subject on his blog, in which he describes approaches that a business-side analyst and an IT-side analyst to take to create a collaborative environment.
This topic is nothing new, just as the relationship between IT and Business is nothing new.
It took decades to get it where it is today. I am sure you can find bright spots in which IT and Business work together to achieve their goals, but in more organizations than not, this is not the case. Just as business processes and technology advance year by year, the relationship between IT and Business can be made better. I believe the Business Analyst is in prime position to turn the relationship around to a positive, collaborative, trusting relationship in which the two work together to achieve the strategic goals and initiatives of the organization. Why the BA? The BA is one role that works on both sides of the fence. The BA works with business stakeholders to bring out requirements for business improvement or application development solutions. The BA also works with the IT Solution Delivery Team to develop the solution that meets the business requirements. As the BA works with both teams, they are in prime position to bridge the gap between the two. So how should the BA go about bridging the gap?
Build a Relationship of Trust
One of the often overlooked roles of the Business Analyst is that of liaison between IT and the Business. In order to fulfill this role the BA must have a relationship with both sides of the organization. That relationship has to be built on trust. The business must understand that the BA is there not only to gather requirements but to understand the needs of the business and represent those needs to the IT delivery team. The IT delivery team must feel that the BA will represent the capabilities and limitations of technology to the business.
Communicate
The greatest factor that creates the “Us vs. Them” relationship is a lack of understanding. The business wonders why it takes IT so long to make a seemingly easy change. The IT application development team feels that business can not communicate effectively and does not understand the process of making application enhancements. Last month I spoke about creating a shared vision in relation to requirements and IT solutions. The BA should also create a shared vision of the needs and limitations of one organization to the other. The BA can communicate not only the requirements for IT solutions, but the stakeholder concerns surrounding those requirements. This adds context and can improve the ultimate solution developed as it increases the IT delivery team’s understanding. The BA can communicate to the business that the process of making application enhancements is more involved then changing a little piece of code and there it is. Testing, Quality Assurance, moving changes to production, Sox regulations, post-install processes and support are all time consuming tasks and increase the amount of time it takes the IT application development team to make an application enhancement. The more the business understands about these processes and the value they add to the solution, the more considerate they will be to the needs of the IT delivery team.
Build the Bridge
Through effective communication of the needs and limitations of one side of the business to the other and representing the other team to each team the BA can build a bridge of understanding between the two groups. By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.
So take the liaison role of the BA seriously and work to replace the adversarial relationship with a collaborative, understanding relationship. In this way you can show the BA value to the organization.
Kupe tackles this topic this week on BA Times, where he discusses creating an environment in which the business wants to work with IT to derive technology-driven solutions. Doug Goldberg does an in-depth analysis of the subject on his blog, in which he describes approaches that a business-side analyst and an IT-side analyst to take to create a collaborative environment.
This topic is nothing new, just as the relationship between IT and Business is nothing new.
It took decades to get it where it is today. I am sure you can find bright spots in which IT and Business work together to achieve their goals, but in more organizations than not, this is not the case. Just as business processes and technology advance year by year, the relationship between IT and Business can be made better. I believe the Business Analyst is in prime position to turn the relationship around to a positive, collaborative, trusting relationship in which the two work together to achieve the strategic goals and initiatives of the organization. Why the BA? The BA is one role that works on both sides of the fence. The BA works with business stakeholders to bring out requirements for business improvement or application development solutions. The BA also works with the IT Solution Delivery Team to develop the solution that meets the business requirements. As the BA works with both teams, they are in prime position to bridge the gap between the two. So how should the BA go about bridging the gap?Build a Relationship of Trust
One of the often overlooked roles of the Business Analyst is that of liaison between IT and the Business. In order to fulfill this role the BA must have a relationship with both sides of the organization. That relationship has to be built on trust. The business must understand that the BA is there not only to gather requirements but to understand the needs of the business and represent those needs to the IT delivery team. The IT delivery team must feel that the BA will represent the capabilities and limitations of technology to the business.
Communicate
The greatest factor that creates the “Us vs. Them” relationship is a lack of understanding. The business wonders why it takes IT so long to make a seemingly easy change. The IT application development team feels that business can not communicate effectively and does not understand the process of making application enhancements. Last month I spoke about creating a shared vision in relation to requirements and IT solutions. The BA should also create a shared vision of the needs and limitations of one organization to the other. The BA can communicate not only the requirements for IT solutions, but the stakeholder concerns surrounding those requirements. This adds context and can improve the ultimate solution developed as it increases the IT delivery team’s understanding. The BA can communicate to the business that the process of making application enhancements is more involved then changing a little piece of code and there it is. Testing, Quality Assurance, moving changes to production, Sox regulations, post-install processes and support are all time consuming tasks and increase the amount of time it takes the IT application development team to make an application enhancement. The more the business understands about these processes and the value they add to the solution, the more considerate they will be to the needs of the IT delivery team.
Build the Bridge
Through effective communication of the needs and limitations of one side of the business to the other and representing the other team to each team the BA can build a bridge of understanding between the two groups. By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.
So take the liaison role of the BA seriously and work to replace the adversarial relationship with a collaborative, understanding relationship. In this way you can show the BA value to the organization.
Like Adriana Beal, I am often asked by BAs and aspiring BAs if I think that becoming certified would be a good career move. Adriana covered the Certified Business Analysis ProfessionalTM (CBAP®) certification from the International Institute of Business Analysis (IIBA®) very well. She noted two situations in which she, and I, would recommend you to obtain the CBAP® certification: 
just introduced by the IIBA. This certification is targeted to the intermediate BA who has not yet achieved the 5 years of BA work experience required by the CBAP®. The IIBA has positioned this certification as a stepping stone to the CBAP®, as such it does not have a recertification process. The CCBATM is good for 5 years and it is expected that within that time most recipients will achieve their CBAP® certification. If not, you will have to sit for the CCBATM exam again.
So is it a good idea to get the CCBATM certification? There are many good reasons to obtain a certification; Adriana points many of them out in her article so I will not repeat them here. However, I am often asked this question by BAs with no or less than one year of work experience. They clearly do not meet the requirements of the CCBATM certification; so what is the alternative for them?
The alternative to a certification for someone who is just starting out their BA career is a “certificate” from an education provider that you have completed some training in a specific area. It is advisable to get your training from an Endorsed Education Provider (EEPTM) of the IIBA so that you know that what is being taught is in line with the IIBA Business Analysis Body of Knowledge® (BABOK®). One other recommendation for those just starting out their BA career, go ahead and join the IIBA now. Just putting your IIBA membership on your resume shows your dedication and passion for the BA profession. It also gives you an excellent talking point during interviews.
As you are beginning your career as a BA, concentrate on improving your BA skills and gaining experience in a breadth of BA tasks and techniques. Remember, work experience can stand alone on your resume; a certification (or certificate) can not.
- the job titles on your work history do not reflect your experience in business analysis (they include other titles such as programmer, software developer, financial analyst, etc.) and/or;
- you spent many years doing business analysis work for one company (perhaps even with the title of BA), but never obtained post secondary education, and is finding it difficult to get your resume noticed by other companies.
just introduced by the IIBA. This certification is targeted to the intermediate BA who has not yet achieved the 5 years of BA work experience required by the CBAP®. The IIBA has positioned this certification as a stepping stone to the CBAP®, as such it does not have a recertification process. The CCBATM is good for 5 years and it is expected that within that time most recipients will achieve their CBAP® certification. If not, you will have to sit for the CCBATM exam again. So is it a good idea to get the CCBATM certification? There are many good reasons to obtain a certification; Adriana points many of them out in her article so I will not repeat them here. However, I am often asked this question by BAs with no or less than one year of work experience. They clearly do not meet the requirements of the CCBATM certification; so what is the alternative for them?
The alternative to a certification for someone who is just starting out their BA career is a “certificate” from an education provider that you have completed some training in a specific area. It is advisable to get your training from an Endorsed Education Provider (EEPTM) of the IIBA so that you know that what is being taught is in line with the IIBA Business Analysis Body of Knowledge® (BABOK®). One other recommendation for those just starting out their BA career, go ahead and join the IIBA now. Just putting your IIBA membership on your resume shows your dedication and passion for the BA profession. It also gives you an excellent talking point during interviews.
As you are beginning your career as a BA, concentrate on improving your BA skills and gaining experience in a breadth of BA tasks and techniques. Remember, work experience can stand alone on your resume; a certification (or certificate) can not.
I am often asked what is a Business Analyst, what is the role of the BA or what does a BA do? Of course, those questions can be answered in many different ways that usually begin with the old standby answer “It depends…”.
When answering those questions, as with most BAs, I will get into the role of the BA within the organizational structure, Enterprise Analysis vs. Requirements gathering on a project, tasks and techniques. I go beyond these limited explanations and try to answer what I believe the requester is really asking “What is the goal of a BA?” I believe the goal of all business analysis activities, whether it is Enterprise Analysis or Requirements Gathering, should be to create a shared vision among the stakeholders.
Create a Shared Vision
Creating a shared vision is much like painting a picture. You are painting a picture in everybody’s mind so clear that everybody can see and understand the picture. No, painting
is not one of the tasks of business analysis. You paint a picture with your words and documentation. Text documents, flow diagrams, use cases, storyboards, activity diagrams, business process models, wireframes and other mockups can all be used in paint a picture. These can be used in combination to paint an even more vivid picture for your audience. Sometimes, as in requirements elicitation, it may mean that you gain the vision of the stakeholder. If in a requirements workshop, focus group discussion or one-on-one interview, drawings on paper or a whiteboard can facilitate shared vision and understanding. Often, it may be that you paint the “as-is” picture for the business stakeholder(s), and then they paint the “to-be” picture for you. By painting a picture so vivid that all stakeholders share the same vision of it, this is how we build the bridge.
Target the Vision to the Audience
In order for your audience to gain a vision, they must not only see the picture, but understand it. The picture must be painted in a way that facilitates understanding; it must be presented in a way that the audience can comprehend. You may use flow diagrams, use cases, story boards and/or activity diagrams when painting the vision to a business audience. You may use text documents, flow diagrams and/or activity diagrams to paint the picture for a technical team. You may use very short summary text documents and/or flow diagrams to present to management. To create a shared vision the picture must be presented in a way that facilitates quick comprehension from the audience to whom you are now presenting.
Sell Your Vision
Not only in our business analysis tasks, but in work outside of business analysis, we must create that shared vision; then be ready to talk about the vision and ensure that all see the same vision. Adriana Beal writing for Bridging the Gap, talks about successfully selling your initiatives to management. As Adriana writes, understand your manager’s framework and persuade your audience not only to accept your point of view, but to act upon it. What she is describing is painting a picture so vivid for your manager that they gain a shared vision with you and that they will want to take immediate concrete action on your proposal.
When answering those questions, as with most BAs, I will get into the role of the BA within the organizational structure, Enterprise Analysis vs. Requirements gathering on a project, tasks and techniques. I go beyond these limited explanations and try to answer what I believe the requester is really asking “What is the goal of a BA?” I believe the goal of all business analysis activities, whether it is Enterprise Analysis or Requirements Gathering, should be to create a shared vision among the stakeholders.
Create a Shared Vision
Creating a shared vision is much like painting a picture. You are painting a picture in everybody’s mind so clear that everybody can see and understand the picture. No, painting
is not one of the tasks of business analysis. You paint a picture with your words and documentation. Text documents, flow diagrams, use cases, storyboards, activity diagrams, business process models, wireframes and other mockups can all be used in paint a picture. These can be used in combination to paint an even more vivid picture for your audience. Sometimes, as in requirements elicitation, it may mean that you gain the vision of the stakeholder. If in a requirements workshop, focus group discussion or one-on-one interview, drawings on paper or a whiteboard can facilitate shared vision and understanding. Often, it may be that you paint the “as-is” picture for the business stakeholder(s), and then they paint the “to-be” picture for you. By painting a picture so vivid that all stakeholders share the same vision of it, this is how we build the bridge.Target the Vision to the Audience
In order for your audience to gain a vision, they must not only see the picture, but understand it. The picture must be painted in a way that facilitates understanding; it must be presented in a way that the audience can comprehend. You may use flow diagrams, use cases, story boards and/or activity diagrams when painting the vision to a business audience. You may use text documents, flow diagrams and/or activity diagrams to paint the picture for a technical team. You may use very short summary text documents and/or flow diagrams to present to management. To create a shared vision the picture must be presented in a way that facilitates quick comprehension from the audience to whom you are now presenting.
Sell Your Vision
Not only in our business analysis tasks, but in work outside of business analysis, we must create that shared vision; then be ready to talk about the vision and ensure that all see the same vision. Adriana Beal writing for Bridging the Gap, talks about successfully selling your initiatives to management. As Adriana writes, understand your manager’s framework and persuade your audience not only to accept your point of view, but to act upon it. What she is describing is painting a picture so vivid for your manager that they gain a shared vision with you and that they will want to take immediate concrete action on your proposal.
A few months ago I wrote on the benefits of developing a Business Case and how it should be used during the IT Governance and SDLC (Waterfall) process. My main point was that the Business Case document needs to be revisited at different points in the SDLC by the IT Governance body to continue to give its blessing to the project. At any point, yes even after development, the IT Governance body can hold up the “halt” sign on the project when factors or the environment has changed to make the project solution of little to no value. However, this can not be done when the IT Governance body reviews the project and the Business Case only at project inception. Constant review of the business case also assists in initiating the risk mitigation plan when factors or the environment changes that makes such mitigation necessary.
Today I look at the Business Case from a different perspective, that of Project Management. I have been involved in organizations that did the Enterprise Analysis activities that identified a business need and built the business case for a solution. The business case was brought before, and received the blessing, of the IT Governance body and a new project was born. It was then turned over to a Project Services team whose first task was to create a Project Charter.
I found it amazing that the similarities, in format and content, between the Business Case document and the Project Charter document were far greater than the differences. Some sections were reordered and some content was moved from one section to another, but essentially it would be easy to swap the names on the documents and most people wouldn’t even notice. Other than the intended purpose and audiences of the documents, they were essentially the same document. This naturally leads to the question: Do You Need Both Documents, or is it a great waste of time?
Yes, the Project Charter defined a few details in greater detail than the Business Case, but also realize it was written at least a week later, when more factors were known. Also, such content as risks and mitigation plans were then transposed, and further defined, into the project’s design documents. So why can’t the Business Case be used as the Project Charter?
In most cases, I would submit that the Business Case should be used as the Project Charter. Remember the Business Case has received the blessings of the IT Governance body and should therefore direct the scope of the project. Going back to the IT Governance body for approval of a Project Charter mostly restating the contents of an already approved Business Case would definitely be overkill and put undo burden upon the IT Governance body.
One case where Project Charter(s) are necessary after the approval of a Business Case, is when that Business Case is to be split into multiple projects to bring about the Business Case solution. In this scenario you would want a Project Charter for each project to define what part of the Business Case scope that particular project was initiated to handle.
In rare, very complex, business problems with complex business solutions you may find need for both a Business Case document and Project Charter document(s). In most cases, even in large companies, using the Business Case to define the scope and reach of a project is sufficient to get the job done.
Today I look at the Business Case from a different perspective, that of Project Management. I have been involved in organizations that did the Enterprise Analysis activities that identified a business need and built the business case for a solution. The business case was brought before, and received the blessing, of the IT Governance body and a new project was born. It was then turned over to a Project Services team whose first task was to create a Project Charter.I found it amazing that the similarities, in format and content, between the Business Case document and the Project Charter document were far greater than the differences. Some sections were reordered and some content was moved from one section to another, but essentially it would be easy to swap the names on the documents and most people wouldn’t even notice. Other than the intended purpose and audiences of the documents, they were essentially the same document. This naturally leads to the question: Do You Need Both Documents, or is it a great waste of time?
Yes, the Project Charter defined a few details in greater detail than the Business Case, but also realize it was written at least a week later, when more factors were known. Also, such content as risks and mitigation plans were then transposed, and further defined, into the project’s design documents. So why can’t the Business Case be used as the Project Charter?
In most cases, I would submit that the Business Case should be used as the Project Charter. Remember the Business Case has received the blessings of the IT Governance body and should therefore direct the scope of the project. Going back to the IT Governance body for approval of a Project Charter mostly restating the contents of an already approved Business Case would definitely be overkill and put undo burden upon the IT Governance body.
One case where Project Charter(s) are necessary after the approval of a Business Case, is when that Business Case is to be split into multiple projects to bring about the Business Case solution. In this scenario you would want a Project Charter for each project to define what part of the Business Case scope that particular project was initiated to handle.
In rare, very complex, business problems with complex business solutions you may find need for both a Business Case document and Project Charter document(s). In most cases, even in large companies, using the Business Case to define the scope and reach of a project is sufficient to get the job done.
What an exciting time to be a Business Analyst! Why do I say that? Because there is so much going on within and for the profession; within organizations worldwide as well as for the profession globally.
Those that follow the discussion forums on the Business Analysis groups (BA Forum, IIBA®, Modern Analyst) on LinkedIn, have seen me post and comment. I have seen conversations develop into two opposite points of view, usually between two individuals, and neither side is willing to change their view, nor consider the other view. When conversation degrade to name calling, you just know that if these two individuals were in the same room that they would be putting on the boxing gloves and it would be a knock-down, drag-out fight to the end. What I think these people are missing…or seem to forget…is history.
Whether you wish to admit it or not, the profession of Business Analysis is still very much in its infancy. It is growing dramatically all over the world. Look at the IIBA membership and chapter start-ups over the past few months. This leaves very widely spread opinions as to what the job of a Business Analyst is. Business Analysis or the IIBA does not enjoy the history and recognition that Project Management and the PMI® receive today. Someday it will, and the IIBA is growing maturity one building block at a time. Let’s take a look.
The PMI was incorporated in 1969, offers 5 certifications, has over 300,000 certified individuals and the PMBOK® is in its Fourth Edition. The IIBA was incorporated in 2006, offers one certification and is adding its second by end of the year, has less than 1,000 certified individuals and the BABOK® is in its Second Edition. Even ITIL® can be traced back to the British Government of the 1980’s. Six Sigma also got its beginnings in the 1980’s. So the IIBA and the Business Analysis profession does not get the recognition that these other professions, methodologies and/or approaches get at the C-level within organizations. It took some time for organizations to recognize these others, they want to see quantifiable results. Business Analysis is getting there; they are proving their value to organizations every day; and with time it too will get its due recognition.
So what is the International Institute of Business Analysis® (IIBA®) doing to help the cause? A few months ago they launch the Online Library, last month they release the second version of the BA Competency Model, and recently have announced their second certification level. Promised in coming months is the Agile extension to the BABOK. Make no mistake about it, the IIBA stands behind and for the Business Analysis profession. They are building maturity one building block at a time. As with all previous professions, methodologies and/or approaches organizations will be slow, but will eventually, adapt and recognize the value. BA Center of Competency and Center of Excellence are beginning to get recognized for the value they bring to the organization.
So why is it an exciting time to be a BA? Because we current practitioners are in on the ground floor. How often do you get an opportunity to define a profession for the world? Just as the framers of the PMI and PMBOK did 40 years ago, we forge a new area for the world to follow. Wouldn’t you grab the bull by the horns?
Those that follow the discussion forums on the Business Analysis groups (BA Forum, IIBA®, Modern Analyst) on LinkedIn, have seen me post and comment. I have seen conversations develop into two opposite points of view, usually between two individuals, and neither side is willing to change their view, nor consider the other view. When conversation degrade to name calling, you just know that if these two individuals were in the same room that they would be putting on the boxing gloves and it would be a knock-down, drag-out fight to the end. What I think these people are missing…or seem to forget…is history.
Whether you wish to admit it or not, the profession of Business Analysis is still very much in its infancy. It is growing dramatically all over the world. Look at the IIBA membership and chapter start-ups over the past few months. This leaves very widely spread opinions as to what the job of a Business Analyst is. Business Analysis or the IIBA does not enjoy the history and recognition that Project Management and the PMI® receive today. Someday it will, and the IIBA is growing maturity one building block at a time. Let’s take a look.The PMI was incorporated in 1969, offers 5 certifications, has over 300,000 certified individuals and the PMBOK® is in its Fourth Edition. The IIBA was incorporated in 2006, offers one certification and is adding its second by end of the year, has less than 1,000 certified individuals and the BABOK® is in its Second Edition. Even ITIL® can be traced back to the British Government of the 1980’s. Six Sigma also got its beginnings in the 1980’s. So the IIBA and the Business Analysis profession does not get the recognition that these other professions, methodologies and/or approaches get at the C-level within organizations. It took some time for organizations to recognize these others, they want to see quantifiable results. Business Analysis is getting there; they are proving their value to organizations every day; and with time it too will get its due recognition.
So what is the International Institute of Business Analysis® (IIBA®) doing to help the cause? A few months ago they launch the Online Library, last month they release the second version of the BA Competency Model, and recently have announced their second certification level. Promised in coming months is the Agile extension to the BABOK. Make no mistake about it, the IIBA stands behind and for the Business Analysis profession. They are building maturity one building block at a time. As with all previous professions, methodologies and/or approaches organizations will be slow, but will eventually, adapt and recognize the value. BA Center of Competency and Center of Excellence are beginning to get recognized for the value they bring to the organization.
So why is it an exciting time to be a BA? Because we current practitioners are in on the ground floor. How often do you get an opportunity to define a profession for the world? Just as the framers of the PMI and PMBOK did 40 years ago, we forge a new area for the world to follow. Wouldn’t you grab the bull by the horns?
Now didn’t I say that Business Analysis has far reaching impact on the organization? A new Forrester research report supports my claim as it ranks Business Analyst #1 of the 13 Most Important IT Roles.
The age of IT specialization has been replaced by an emphasis on skills that can translate across the enterprise. According to Forrester, this shift can be traced to a number of emerging trends:
* Maturing technologies such as software-as-a-service and business intelligence are changing IT skills requirements;
* The growing array of outsourcing options have altered in-house staffing priorities, with more specialized skills increasingly likely to be outsourced; and
* The continued search for cost-reduction opportunities has changed how IT decisions are made.
With those trends in mind, here is Forrester’s list of the 13 Most Important IT Roles, based on the percentage of IT executives who believe each role is growing in importance.
#1 – Business Analyst – 70%
Talk about holding all the cards: Not only do these IT pros know the business, they also have their fingers on all the insight. As the saying goes, knowledge is power.
#2 and #3 – Architecture and IT Strategy/Planning – 66%
As IT has evolved into an increasingly important part of business, both of these roles have become critical in ensuring that every department has the infrastructure and tools that it needs.
#4 – Project Management – 65%
What business doesn’t need people who can mange multiple personalities, master numerous business processes, understand different aspects of the business and make sure things get done?
#5 – Security – 62%
With the onslaught of breaches and identity theft that constantly filters through the headlines, not to mention the growing mandates for better access controls, is there really an explanation needed here?
#6 – Service Management – 60%
The whole thing about the customer applies here to, as managing IT from the customer’s perspective has become de rigueur.
#7 – Client Relationship Management – 56%
We’re in the age of customer service, and anyone who’s mastered the art of managing CRM environments is worth their weight in gold.
#8 and #9 – Business Continuity and IT Financial Management – 55%
With companies paranoid about their systems surviving natural and man-made disasters, and cost-effective IT spending more important that ever, it’s no wonder these roles are on the rise.
#10 – Portfolio Management – 50%
This is a growing area driven by the desire to demystify the measurement of the impact of IT investments.
#11 – Asset Management – 34%
Like other spin-offs from more general business roles, this is another specialized function better outsourced.
#12 – IT Research – 30%
Research? That’s what consultants are for.
#13 – Human Resources (within IT) – 20%
HR for IT is an increasingly unnecessary luxury in an increasingly self-service environment.
Take a closer look at that list and you will notice Business Analysis has been ranked #1, #2, #3 and #10.
The age of IT specialization has been replaced by an emphasis on skills that can translate across the enterprise. According to Forrester, this shift can be traced to a number of emerging trends:
* Maturing technologies such as software-as-a-service and business intelligence are changing IT skills requirements;
* The growing array of outsourcing options have altered in-house staffing priorities, with more specialized skills increasingly likely to be outsourced; and
* The continued search for cost-reduction opportunities has changed how IT decisions are made.
With those trends in mind, here is Forrester’s list of the 13 Most Important IT Roles, based on the percentage of IT executives who believe each role is growing in importance.
#1 – Business Analyst – 70%
Talk about holding all the cards: Not only do these IT pros know the business, they also have their fingers on all the insight. As the saying goes, knowledge is power.
#2 and #3 – Architecture and IT Strategy/Planning – 66%
As IT has evolved into an increasingly important part of business, both of these roles have become critical in ensuring that every department has the infrastructure and tools that it needs.
#4 – Project Management – 65%
What business doesn’t need people who can mange multiple personalities, master numerous business processes, understand different aspects of the business and make sure things get done?
#5 – Security – 62%
With the onslaught of breaches and identity theft that constantly filters through the headlines, not to mention the growing mandates for better access controls, is there really an explanation needed here?
#6 – Service Management – 60%
The whole thing about the customer applies here to, as managing IT from the customer’s perspective has become de rigueur.
#7 – Client Relationship Management – 56%
We’re in the age of customer service, and anyone who’s mastered the art of managing CRM environments is worth their weight in gold.
#8 and #9 – Business Continuity and IT Financial Management – 55%
With companies paranoid about their systems surviving natural and man-made disasters, and cost-effective IT spending more important that ever, it’s no wonder these roles are on the rise.
#10 – Portfolio Management – 50%
This is a growing area driven by the desire to demystify the measurement of the impact of IT investments.
#11 – Asset Management – 34%
Like other spin-offs from more general business roles, this is another specialized function better outsourced.
#12 – IT Research – 30%
Research? That’s what consultants are for.
#13 – Human Resources (within IT) – 20%
HR for IT is an increasingly unnecessary luxury in an increasingly self-service environment.
Take a closer look at that list and you will notice Business Analysis has been ranked #1, #2, #3 and #10.
Keith Ellis compares the business analysis profession to an iceberg in his article on BA Times. He notes that it looks small on the surface but when you get into it how much of “the job” is not visible on the surface.However, my take away from this article is about the impact of business analysts on the organization. “..not in little ways. In a big way!” Business analysis done properly can impact the organization unlike any other role within the organization. It literally changes the way the organization does business. It impacts every business unit within the organization and can affect project portfolio, financial performance, product offerings and speed to the market; all affecting competitive advantage.
You must also realize the negative impact that BAs can have on the organization when business analysis activities are not performed correctly, or not at all. It can also have a negative impact on competitive advantage. As Keith says “This is not an IT thing, it’s a business success thing.”
We practitioners often get bogged down in the day-to-day activities of the job and loose site of the impact we have, or can have, on the organization. Sometimes it is necessary to stop, take a deep breath and re-visit our own impact on the organization. Implementing a BA Center of Excellence for the organization can go a long way in ensuring the business analysts’ impact on the organization is positive.
What is the BA impact in your organization?
How many times have you developed Use Cases for a project, gone over them with the stakeholder, reviewed the functional requirements of the system, developed and delivered your IT business solution to have the stakeholder want to make changes to it immediately? Is this a symptom that the stakeholder did not understand the Use Case?
More then likely what the stakeholder did not understand is what the user interface (UI) would look like or how it would act. So then we as Business Analysts (BA) turn to Microsoft Visio, PowerPoint or some other tool to create a mockup or prototype of the UI. We share that with the stakeholder, but he/she is still left without the whole picture.
So now we as BAs turn to Microsoft Word, PowerPoint or some other tool to put some details behind the Use Cases and UI. We share that with the stakeholder and get their approval to build the solution. So back to Microsoft Word we go and write a high-level and eventually a detail design to give to the developers to build what we have laid out to the stakeholder. Now all of sudden you three to six documents that you must track and keep in synch; a change to one document may mean a change to another.
Masayuki Otoshi gives a solution to this dilemma in a BA Times article as storyboarding; a way to put Use Case, UI and detail specifications in one document. The article shows an example of user login webpage. It gives examples of the main stream, providing a correct user name and password and an exception stream, providing an incorrect user name and password.
On the surface storyboarding to provide UI and detail information to the stakeholder sounds like a good idea. The simplicity of the example falls short to show the usefulness of this tool. I deal mainly with complete Enterprise Resource Planning (ERP) systems and eCommerce website interfaces to the back-end order fulfillment system. Using storyboards to show the stakeholder(s) what the eCommerce webpages or the ERP desktop screens will look like before they are built allows the stakeholders to make changes to the look and feel of the system before development dollars are spent to build it. Giving the stakeholder(s) a more complete picture of the proposed system look and functionality during analysis and design phase of the project should reduce the amount of rework requested.
Storyboarding has been used in the Agile system development methodology for awhile. It has not caught favor in the SDLC or Waterfall methodology as of yet; but the need to draw a more complete picture to the stakeholder(s) of a proposed IT business solution as early as possible in the project cycle may give storyboarding the light of day.
I do see the usefulness of storyboarding for the SDLC as well as the Agile methodology. I look back on past projects where I could have used storyboarding, if nothing else, to decrease the project schedule.
I do raise one word of caution…remember your audience. All too often I have seen IT business solutions project teams try to combine multiple documents to serve several purposes. Giving the stakeholder(s) the level of detail that developers need to develop the solution may cause confusion with the stakeholder. So do not try to combine everything into one document. Even your wording should be different for stakeholder documents and technical documents. So try storyboarding if appropriate to the project. Someday we just may find it as mainstream as requirements documents and Use Cases are today.
More then likely what the stakeholder did not understand is what the user interface (UI) would look like or how it would act. So then we as Business Analysts (BA) turn to Microsoft Visio, PowerPoint or some other tool to create a mockup or prototype of the UI. We share that with the stakeholder, but he/she is still left without the whole picture.
So now we as BAs turn to Microsoft Word, PowerPoint or some other tool to put some details behind the Use Cases and UI. We share that with the stakeholder and get their approval to build the solution. So back to Microsoft Word we go and write a high-level and eventually a detail design to give to the developers to build what we have laid out to the stakeholder. Now all of sudden you three to six documents that you must track and keep in synch; a change to one document may mean a change to another.
Masayuki Otoshi gives a solution to this dilemma in a BA Times article as storyboarding; a way to put Use Case, UI and detail specifications in one document. The article shows an example of user login webpage. It gives examples of the main stream, providing a correct user name and password and an exception stream, providing an incorrect user name and password.
On the surface storyboarding to provide UI and detail information to the stakeholder sounds like a good idea. The simplicity of the example falls short to show the usefulness of this tool. I deal mainly with complete Enterprise Resource Planning (ERP) systems and eCommerce website interfaces to the back-end order fulfillment system. Using storyboards to show the stakeholder(s) what the eCommerce webpages or the ERP desktop screens will look like before they are built allows the stakeholders to make changes to the look and feel of the system before development dollars are spent to build it. Giving the stakeholder(s) a more complete picture of the proposed system look and functionality during analysis and design phase of the project should reduce the amount of rework requested.
Storyboarding has been used in the Agile system development methodology for awhile. It has not caught favor in the SDLC or Waterfall methodology as of yet; but the need to draw a more complete picture to the stakeholder(s) of a proposed IT business solution as early as possible in the project cycle may give storyboarding the light of day.
I do see the usefulness of storyboarding for the SDLC as well as the Agile methodology. I look back on past projects where I could have used storyboarding, if nothing else, to decrease the project schedule.
I do raise one word of caution…remember your audience. All too often I have seen IT business solutions project teams try to combine multiple documents to serve several purposes. Giving the stakeholder(s) the level of detail that developers need to develop the solution may cause confusion with the stakeholder. So do not try to combine everything into one document. Even your wording should be different for stakeholder documents and technical documents. So try storyboarding if appropriate to the project. Someday we just may find it as mainstream as requirements documents and Use Cases are today.
Futurists have been fore-telling the look of the business enterprise and the IT Department for years. The latest version from the Corporate Executive Board state that we are in for rapid, radical change. It fore-tells that the IT Department in 5 years will bear little resemblance to the IT Department of today. As business users become more tech savvy, the business units will absorb a lot of today’s IT functions. Along with continued IT outsourcing, they predict that only 25% of today's IT professionals will still be in IT in 5 years.
The CTO blog does not forecast such a dismal future for the IT professional, but it also acknowledges the need for better alignment with business strategic goals and faster IT solutions delivery.
Whereas, I will not completely buy in to the idea that 75% of today’s IT professionals will not be working in IT in 5 years or that change will be so rapid or radical. It is increasingly apparent that change in IT solution delivery is necessary, and that is where I suggest that business organizations start; in particular IT Governance.
I hope to see today’s IT Governance Committee, which approve and prioritize IT business solutions projects, replaced with a Business Improvement Project Review Board who approve and prioritize all business improvement projects. This new Governance Body will consider all business improvement projects; those with business solutions and those with IT solutions. As I mentioned a few weeks ago this new board needs to better track all projects and continue to give its support to all projects at every stage of the project. Once the cost of the project outweigh the benefits, or other external forces make continuance of the project unwise, the project can be stopped and decrease the expense to the organization.
Along with that we will see the idea of a Project Management Office (PMO) replaced with a Business Improvement Office (BIO). The BIO will be staffed with people with business backgrounds and those with IT backgrounds; however, cross-training and best practices will require all members of the BIO to look for the best solution, considering both business and IT solutions, to meet the needs of the business. The BIO will take over the project management, business analysis and quality assurance aspects of a project.
Continued competitive pressures will force the BIO to change its practices in order to achieve faster solution delivery. Some will embrace the Agile methodology; others will develop some hybrid methodology taking parts from both the Agile and Waterfall methodologies. However they achieve it, continued pressures for competitive advantage will require continual improvement in the methodology to push for faster and faster delivery while not sacrificing quality.
Many references now forecast a change to IT Departments and IT staffing as we know it today. It will be interesting to see the changes as they come about and see which forecast was most correct.
The CTO blog does not forecast such a dismal future for the IT professional, but it also acknowledges the need for better alignment with business strategic goals and faster IT solutions delivery.
Whereas, I will not completely buy in to the idea that 75% of today’s IT professionals will not be working in IT in 5 years or that change will be so rapid or radical. It is increasingly apparent that change in IT solution delivery is necessary, and that is where I suggest that business organizations start; in particular IT Governance.
I hope to see today’s IT Governance Committee, which approve and prioritize IT business solutions projects, replaced with a Business Improvement Project Review Board who approve and prioritize all business improvement projects. This new Governance Body will consider all business improvement projects; those with business solutions and those with IT solutions. As I mentioned a few weeks ago this new board needs to better track all projects and continue to give its support to all projects at every stage of the project. Once the cost of the project outweigh the benefits, or other external forces make continuance of the project unwise, the project can be stopped and decrease the expense to the organization.
Along with that we will see the idea of a Project Management Office (PMO) replaced with a Business Improvement Office (BIO). The BIO will be staffed with people with business backgrounds and those with IT backgrounds; however, cross-training and best practices will require all members of the BIO to look for the best solution, considering both business and IT solutions, to meet the needs of the business. The BIO will take over the project management, business analysis and quality assurance aspects of a project.
Continued competitive pressures will force the BIO to change its practices in order to achieve faster solution delivery. Some will embrace the Agile methodology; others will develop some hybrid methodology taking parts from both the Agile and Waterfall methodologies. However they achieve it, continued pressures for competitive advantage will require continual improvement in the methodology to push for faster and faster delivery while not sacrificing quality.
Many references now forecast a change to IT Departments and IT staffing as we know it today. It will be interesting to see the changes as they come about and see which forecast was most correct.
As I move from client to client, IT shop to IT shop, the one think I notice is that most organizations do not have an internal BA Body of Knowledge. There are several reasons that I can think of as to why organizations have not taken on the task of developing an internal BABOK:
1. Companies are slow to embrace the idea and value of a BA Center of Excellence.
2. Companies do not understand what an internal BABOK is and what should be in it.
3. Companies have not realized the value of an internal BABOK.
4. Not enough time, not enough resources.
So let’s take a look at these reasons. First, creating a BA Center of Excellence would allow the organization to use their BA talent in a more strategic role within the organization. It would allow them to move their BAs among the business units within the organization with a much less learning curve. BAs leaving the organization don’t take valuable business knowledge out the door with them and just as important, new BAs have a much shorter ramp up time to become effective to the organization. I believe once organizations realize the value that developing a BA Center of Excellence can have on the organization, they would all want one.
Secondly, there is reference material available that conceptually describes an internal BA Body of Knowledge, but you would have to dive deep into reading material to find it. So, let me spell out for all to see what we are talking about when we say an organization should develop an internal BA Body of Knowledge. This is a centralized, electronic copy of documents that define anything within the business. This is a wealth of knowledge that all your BAs can draw from to better perform their duties. This would allow a BA to learn a new area of the business quickly that they have not worked in before as they are assigned new tasks. This BABOK would define the business organization, the business units with it and the interrelationships between those business units. What did that sound like to you? If you said an Enterprise Architecture, you are absolutely correct. The first thing to include in your internal BABOK is the organization Enterprise Architecture, including all five parts of the architecture. Also include the BA Career Ladder, BA Competence Model, BA Job Descriptions, new BA training material, BA departure review and BA reference material pertinent to the organization.
Thirdly, now that you understand what wealth of knowledge is included in an internal BABOK, I think you can realize the value of it without me saying a word. Most organizations do not have an Enterprise Architecture, let alone an internal BABOK. Those organizations that somewhat have one; usually have it dispersed all over the company network, which makes finding material very difficult. Centralized, easy to access, electronic, included in the company’s backup and restore process adds tremendous value to the organization.
Lastly, this is always the reason that many good ideas do not take form. Realize, that if you had an internal BABOK that your BAs used on a daily basis that research tasks take a lot less time. This can decrease project schedules, freeing up more than just BA resource time.
That all sounds nice, but what does it mean to the organization? Well, there are many benefits to having an Enterprise Architecture and internal electronic BABOK to the organization:
- Project portfolio in greater alignment with business strategic goals and initiatives
- Realization of BA talent in a more strategic role
- New BAs become more effective to the organization faster
- Ensure enterprise knowledge stays within the organization when BAs leave the organization
- Starting point for Enterprise Capability Gap Analysis
- Reference material for new product feasibility studies
- Reference material for competitive edge analysis
- Required material for new enterprise software impact analysis
There are many benefits to the BA practice within the organization:
- Reference material easily available without exhaustive searching
- Understand BA Competencies important to the organization
- Understand BA Competencies needed to achieve the next level on the BA Career Ladder
- Move within the business units of the organization with greater ease and knowledge
- Needed reference material for Enterprise Analysis activities
Now can your organization survive in these economic times without an internal BABOK?
Powered by Compendium