Tag: Career

Are Business Analysts In Danger of Becoming Extinct? Part 1

Written by Glenn R. Brule on September 27, 2011. Posted in Articles. 1 Comment on Are Business Analysts In Danger of Becoming Extinct? Part 1

Most organizations have an understanding of the value of business analysis and what requirements mean to a project. At the same time, conditions are emerging that have the potential to undermine the position of the business analyst to the point of extinction. In this first part of a two-part article, we’ll take a closer look at what has brought these circumstances about in order to provide a clear understanding of why BAs need to balance their technical and business skills and demonstrate proof of their value to the organization.

Some historical perspective on the evolution of information technology draws interesting parallels to the story of David and Goliath. IT essentially began with the Goliath that was the big old, clunky IBM 3480 mainframe. The David to IBM’s mainframe came along as the new Windows operating system and networks. David won the day and the mainframe went the way of the dinosaur. New opportunities continued to expand the world of technology with network computer systems and the major emergence of the Internet. With that, the Internet, desktop computers and local area networks became the new Goliath. The new David was the software developer who was desperately trying to crank out products that could work on networks and the Internet. As Goliath’s world of technology grew out of control, yet another David in the form of the project manager was introduced in order to gain control over the world of software development.

Up until that point in time, success was measured with clarity and precision. To the technology world and software developers, to measure meant answering the questions, “Is it working well and are the lines of code being executed?” So the project manager was brought in to gain control over what wasn’t working. The result was a clearer definition of success in terms of time, budget and quality. However, Goliath continued to rage on in the software development vs. project management battle, as failure reports from the Standish Group and other research bears out.

The project manager began to partner with the business analyst. David now took on the dual roles of the project manager/business analyst and he understood the secret weapon to defeating Goliath was requirements. Prior to that partnership, the PM was responsible for what could be called requirements activities. When the additional role of the BA was introduced, there were two disciplines aiming to subdue the mighty Goliath.

During the time before the BA was introduced, measurements of success and progress were relatively easy. The introduction of the complementary BA role was as a strong communicator and facilitator, acting as the catalyst to project success. The overarching problem is that BAs are now selling themselves short in promoting their business skills when they should actually be promoting a balanced portfolio of technical and business skills. While facilitation and communication are critical, they are difficult to quantify. As a result, BAs risk extinction because by putting all their eggs in the business skills basket, they aren’t exercising their technical skills that demonstrate quantifiable impact.

BAs need to understand their audience when it comes to balancing business skills and technical ones. The people who grew up in technology—project managers, software developers—are now our leaders—the CIOs and managers of IT teams who are accustomed to black-and-white quantification. So in order for BAs to adequately sell the value and impact of their contributions, they need to speak the language of their audience, which can only be done through a balanced portfolio of competencies. For example, as a practitioner of enterprise analysis activities, the BA can identify inefficiencies in the organization and provide direction on how to improve them. These are activities from which impact can be clearly proven.

Most critical to practicing a balance of competencies is understanding the BA’s business value and impact. As an example, about 10 years ago, one of the top five banks in Canada found that its insurance division wasn’t generating nearly the amount of revenue that had been anticipated. The bank was very progressive in its view of the realm of requirements and business analysis. It had actually coined the term “SWOT team” for their BAs due to their ability to identify strengths, weaknesses, opportunities and threats. The bank sent in the SWOT team to evaluate all business issues related to its auto insurance business.

The SWOT team discovered that in order to give a prospect a quote over the phone for auto insurance, it took an average of 17-20 minutes (a quantifiable metric). With further investigation, they began to clearly understand that there were multiple systems with which the call center reps had to deal that slowed them down and prevented them from handling more customers.

The SWOT team proposed a service-oriented architecture-type system that pulled together all systems and provided access to information through a common interface that put everything on one platform. This enabled the call center reps to dramatically reduce the time it took to provide a quote. The resulting increase in revenue was estimated at a cool C$1 million a day.

This example should resonate loudly with BAs. The SWOT team didn’t go in with just their communication skills drawn; they

identified an inefficiency
did their analysis of the people in question, as well as of the entire organization
developed a solution that impacted the auto insurance business and drove further change in the divisions for personal, mortgage and homeowners insurance

They accomplished all of this, in addition to making C$1 million more a day.

They did it through enterprise analysis, requirements analysis, creating models, facilitation, solutions assessment and validation: in other words, a very broad portfolio of competencies.

In Part 2 of “Are Business Analysts in Danger of Becoming Extinct?” we’ll examine the balance of competencies needed along the BA’s career spectrum

Don’t forget to leave your comments below.

Glenn R. Brûlé, CBAP, CSM, Executive Director of Global Client Solutions, ESI International, brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. A recognized expert in the creation and maturity of BA Centers of Excellence, Glenn has helped clients in the energy, financial services, manufacturing, pharmaceutical, insurance and automotive industries, as well as government agencies across the world.

Business Analyst “Real Jobs” — Define the Problem

Written by Greg Busby on August 29, 2011. Posted in Articles. 1 Comment on Business Analyst “Real Jobs” — Define the Problem

Business Analysts are asked to do many things: elicit, document, and manage requirements; facilitate meetings; fit/gap and feasibility studies; act as a bridge or liaison between functional and technical groups. We often look at this mix of activities and think “This is my job”. Through this series of articles, I’m going to talk about the things that a BA needs to do as part of their “Real Job”. Not just the skills and activities we practice on a day to day basis nor the tasks that we are assigned and complete from project to project basis, but the reasons behind those skills and activities; the what and why of delivering value to the business via IT projects.

Charles Kettering said “A problem well stated is a problem half solved” more than half a century ago, and it is still true today. Helping the customer come to an understanding of what they want to do and why is the crucial first step to getting a project going. Without this understanding, the project is off on the wrong foot. Sometimes, though, reaching this understanding is not that easy.

In this article, I address the perception common among BAs that “I [help] solve problems”. While this is partly true, I think that the Real Job of the BA is to help the customer accurately and succinctly define problems (or issues, the preferred term for business-side people).

How many times have you started a project where the customer asks you to implement something, and you realize it is really a solution? Do you forge ahead, holding requirements workshops and putting the documents together? Or do you stop and ask them why they want the project, only to have them say “Because I said so, that’s why!”?

Be careful. Either approach could get you in trouble, and knowing when and how to do both as appropriate is one of the things that identifies a real BA. Which brings us back to this part of the BA’s “Real Job”: defining the problem or clarifying the issue.

Clarifying the issue involves working closely with the customer to understand the rationale for the project and how it fits in to the business. Whatever level you are working at in a given project, from high-level strategy to enhancement of an existing system, help the customer articulate the business value of the project by showing how it will address an issue (solve an existing problem).

There are as many levels of business issues as there are types of requirements, and in fact we can map them nicely. I’ve created a modified version of the venerable V-diagram to show how business issues map to requirements.

You‘ll notice the two-headed arrows on the slide; this is because requirements don’t exist in a vacuum. In examining a requirement at any level you can turn it on its head and look at what issue that requirement is intended to address. As you dig in, be sure to ask “are we solving the right problem?” This may lead you to uncover issues at other levels; issues that, when addressed, may make the problem you are currently examining simply disappear.

Carefully articulating the issues or problems when documenting requirements can lead to improved

traceability and provide a common language when discussing matters of scope. It can also help with the all-important prioritization of requirements, that often onerous job of separating the ‘must haves’ from the ‘should haves’ and the ‘like to haves’. Clearly, if a requirement is related to a core problem that the system is intended to address it is a must-have, while those requirements that don’t actually address an issue probably are not.

CONCLUSION: There is little business value in a solution in search of a problem, sometimes known as “build it and they will come”. On the other hand, even an average solution to a problem shared by many people will be embraced and used. Keep in mind that problems and requirements go hand in hand. Make sure that you work with the customer to understand and clarify the right problem, and you’ll be well on your way to doing your “Real Job”.

Don’t forget to leave your comments below.

Greg Busby, CBAP(R), provides leadership for Cornell University’s BA practice, which he helped start 5 years ago. With over 25 years experience in IT, including Business Analysis, Product Management, Consulting, and Development. Greg’s focus is on establishing and maintaining the partnership between IT and business units to help ensure that technology projects support and further the institutional strategy and goals. His primary areas of interest are enterprise analysis, portfolio planning and analysis, BA/PM teamwork, and professional development of BAs.

Celebritize Yourself

Written by Greta Blash on July 4, 2011. Posted in Articles.

I just finished reading a wonderful book by Marsha Freidman, Celebritize Yourself,[1] which describes a three-step method to increase your visibility at work. I feel that after seven years of work in your profession as a business analyst, you should be recognized as an expert and if you are not, this book will help guide you through the process. Celebritize Yourself is about branding yourself as an expert. This book is not about becoming a Hollywood or TV reality celebrity, but about becoming recognized as an expert or leader in your field.

The three-step method to celebritizing yourself is

1. Write,

2. Speak,

3. Sell.

Write as much and as often as well wherever you can. If fact, everyone who is reading this article is invited to contribute to the Business Analyst Times website: http://www.batimes.com/contributing-to-ba-times.html about your own experiences pertaining to business analysis problems and solutions.

The second step, Speak, is your ability to give presentations to various groups through work-related projects or organizations such as IIBA, Toastmaster, etc. Speaking in front of a group is the number one fear that people have but as a business analyst, you are expected to give presentations about your work so why not take it a little farther by volunteering to give presentations outside of your work environment. The experience will provide you the opportunity to improve your speaking skills.

The third step, Sell, is about selling yourself as a business analyst for future projects or as an authority on business analysis topics so that managers will seek out your opinions. At one company where I worked, I facilitated a weekly brown bag lunch meeting for business analysts where we could share ideas about business analysis topics within actual projects that were currently underway. This proved to be valuable to the newer business analysts and project managers, and also gave me the opportunity to write and speak.

If you look on IIBA’s website, IIBA.org, you will see that IIBA encourages you to give back to your profession by volunteering to write and speak on business analysis topics.

Volunteering activities include:

Willing and able to devote two to six hours per week to IIBA calls and volunteer-related work
Access to email, the Internet, and a word-processing program
Willing and able to attend committee meetings, as scheduled, via conference call or in person.

Before you start, the author recommends that you make a list of your strengths and weaknesses. What are you good at? Is it your organizational and planning skills, your people skills, communications? These are the things that come easy to you and that you thoroughly enjoy. What about your weaknesses? These are the things you struggle with and don’t enjoy and may even try to avoid or pass on to another team member. Do you need to improve on any of these weaknesses? What makes you unique from other project managers when you compare yourself to them?

Next, the author suggests you answer the following questions:

1. What’s Your Vision for Celebrity? Before you can finalize a plan, you must decide where you want the plan to take you. What is your business analysis vision? Make it simple and write it out as to what you want it to be.

2. What is Your Commitment to Your Vision? How determined are you to become a great business analyst? Do you have your CCBA or CBAP certification? Do you attend your local IIBA chapter meetings? Do you communicate with other business analysts? Do you read articles and blogs on Business Analyst Times and respond to what is written there?

3. What is Your Own Unique Message? Defining your message is not always easy nor is it always obvious. But it is important to have a distinctive message about your knowledge, experience and education. What part of it do you enjoy the most and what energizes you to perform the work that you have been assigned?

4. Why Does Your Message Appeal to You? What do you love about being a project manager? Is it the planning, the execution, monitoring and control, or is it the team members or the satisfaction of successfully completing the project that greatly benefits the organization?

5. Why Will Your Message Appeal to Others? It is meaningless to start this journey unless your message can resonate with others. How can you reach out to others to touch their lives and benefit them regarding business analysis?

6. Who is your Target Audience? Who will benefit from your message? Is it other business analysts, stakeholders or students? Identifying your audience is the foundation for your entire plan. That is your personal marketing plan.

7. What’s Your Plan for Celebrity? The plan should contain a defined goal and specific steps that are necessary to achieve it. You should write this, evaluate it and update it frequently before committing to it.

8. When Will You Start? I assume by now that you are enthusiastic and you are thinking about starting your own celebrity journey. Here is a quote from Amelia Earhart: “The most difficult thing is the decision to act; the rest is merely tenacity.” The author suggests that you start out small and add to it as goals are achieved.

9. Have You Picked the Right Teammates? You are looking for individuals that can help support and constructively criticize you and your work. Choose teammates who clearly want to help you succeed. Embrace them and listen to what they have to say, even when it’s critical of your work.

10. How Will You Measure Success? When you consider the time and effort you will put into this, what will you expect to be your reward? Is it recognition from your peers, management or family? Is it the satisfaction of helping others? Only you can provide the answer to this question.

In summary, celebritizing yourself is not a means to an end, but it’s an ongoing journey. It is a path and not a destination. Don’t let the hard work dishearten you or let obstacles stand in your way. If you apply the principle in this article or from the book, you will find the journey becoming easier and your expectations will be met. To walk the path takes a strong commitment to develop a personal plan that can lead to a successful career while helping others. It can lead to a strong sense of fulfillment in your life.

[1] Celebritize Yourself, Author: Marsha Friedman, ISBN: 978-1-886057-20-3, Warren Publishing, Inc 2009

Steve Blash is an experienced IT professional consultant providing business and technology leadership, mentoring and vision. His areas of experience include project management, I.T. management, business process improvement, business analysis, business intelligence, data analytics and data warehousing.

The Bad Ass BA Observes the “Hunt for the Right BA”, Part 2

Written by Cecilie Hoffman on February 8, 2011. Posted in Articles.

In the January article, I talked about the job seeker’s difficulty sorting through job descriptions for business analysts. In Part 2, I want to turn it around and look at the “specialist” vs. “generalist” question that we face as we create our resumes – how do we position ourselves as we respond to job postings?

In the Feb 2011 IIBA Newsletter, Laura Brandenburg, IIBA Career Center Product Manager, said, in her article, “5 Steps to Becoming a Business Analyst”

Although IIBA® holds us business analysts together under a unified understanding of business analysis, the real world of business analyst job roles is often messy and difficult. BA roles, as we learn in the competency model, fall into three main buckets:

Generalists, who perform a wide variety of business analysis activities
Specialists, who use a limited set of techniques or a single methodology
Hybrids, who do business analysis within another job role

I think there’s a little more to consider. We have to put the generalist vs. specialist discussion in the context of the course of our careers, entry-level, mid-career, experienced-and-having-too-much-fun-to-retire. Here are three typical patterns:

In Pattern 1 you began your career doing software testing in under watchful supervision. Your manager was pleased with your instinctive planning and thoroughness and arranged for formal training in quality assurance. Along the way you discovered use cases and the iterative development. You became a QA generalist for software products, often requested by product managers for “dot oh” releases. Over time, your role evolved into a business analyst role with a specialization in testing activities.

In Pattern 2, you were hired as a business analyst because that’s the title all straight-out-of-college entry-level technical people were given until the manager figured out what you were good at. You had no clue what the BA role was or how to do it. You were given all kinds of work to do, and by asking questions you just figured it out. Because you were able to establish a good working relationship with Group X, you became the go-to person for their application, helping them map their business processes, determining their requirements, designing the user acceptance tests, often coding the changes and jacking the new code into the release environment. A larger company that has better software deployment practices bought out your company; you are no longer allowed to hot swap modules into the production environment. Instead, thanks to your new ITIL Foundations certificate, you became the BA manager for the new group that absorbed Group X.

In Pattern 3, the specialist pattern, you came out of school with a strong database background. You hired into a company that was transitioning from an in-house built HR system to PeopleSoft and became a data migration SME in no time flat. Because you showed that unusual combination of communication and analysis skills, your role shifted from database developer to functional requirements specialist to HRIS business analyst. Over the years your knowledge of PeopleSoft has become greater, both in depth (the integration of PeopleSoft to the company’s ERP system) and breadth (all the different business teams that use PeopleSoft and their wide variety of needs). You started speaking at conferences and writing articles for trade journals. Eventually, you started your own consulting company and now you are traveling the world, helping other companies with their PeopleSoft projects.

There are risks and benefits to both being a generalist and a specialist by the time you are at mid-career. In a nutshell, the risk to being a specialist is that you may become so narrowly focused as to limit your career growth options. The risk of being a generalist is that you may be lacking in-depth knowledge that would make you instantly useful to a hiring manager. The benefit of being a specialist is that if you have the high-demand skills, the likelihood of spending much time on unemployment goes down. The benefit of being a generalist is that you see the patterns across organizations and industries – your big picture view can make you extremely valuable to the right employer. Moreover, an employer who is looking for a generalist is likely to have an expectation of teaming you with subject matter experts.

How can an IT BA become a generalist? In the world of IT, Business Analysts tend to cluster in one of four areas, infrastructure, applications, operations and project management.

Project Management. Glenn Brulé coined the term “PooMBA”, a person who is paid one salary to do two jobs. In some back water IT environments, BAs are still “junior PMs”. There are also BAs who are acquiring and refining their project management skills by voluntarily taking on these types of responsibilities.

Infrastructure. The business analyst who has a lot of infrastructure experience may have a specialist title, e.g., network specialist or security specialist. While their job description lists all the technical expertise they are expected to have, the description may gloss over the crucial role they play in communicating with other technical teams. Middleware specialists e.g., TIBCO developers often have an Applications Developer title. While their focus may be on the low level functional requirements, the knowledge and skills of requirements analysis, management and communication are still critical to the success of the projects.

Operations. In the world of Operations, business analysts are often found juggling change requests, release schedules, quarterly freeze exception requests with one hand, and SOx guidelines with the other. Their managers may not think of them as business analysts, but the knowledge area of business analysis planning and monitoring applies directly.

Applications. Business and technical applications are as plentiful as mosquitoes at your picnic at dusk. A ridiculously over-simplified view of the world would put business-level applications in one bucket, and everything else in the other bucket. By business-level applications I mean those in the class of Enterprise Relationship Management systems, e.g., Oracle, or Human Resource management systems, e.g., PeopleSoft, or Supply Chain management systems, e.g., SAP, or Customer Relationship management systems, e.g., Sales Force, and … those applications that support a business function that is specific to the type of organization, for example, many city governments use Azteca’s Cityworks. Many Business Analysts spend their entire career in one application!

Let’s look at Petra’s situation. Her most recent experience is five years of experience doing release management. Prior to that she had two years of application change request management as an entry level BA. She has been the release management team lead for the past year and after that very long year the job is no longer an interesting challenge. Petra is worried that she has become pigeon-holed in her job, that is, her manager assumes she’ll do release management forever. Petra knows the operations angle of her job very well, but she hasn’t ever worked on a business case, she has never done a solution assessment, let alone worked on a cross-functional strategic initiative. She’s really good at release management and she knows these skills would transfer well to another company. Should she branch out or should she stay focused in this one area?

She looks at her company’s job postings and sees one in the Network operations group. They need a business analyst with requirements management skills and some PM experience. She has no infrastructure experience at this point in her career, should she apply for the job?

There’s no right answer – only more questions to be asked – chief among them is whether she is interested enough to explore this new area. Some companies have good Human Resource staff that can ask her questions to help her make a decision. Petra can also talk to her manager about career development – a good manager is willing to help. She could also talk to the manager of the network project to find out if she might be a good fit. Maybe this isn’t the right project, but there will be others. And, it will give her current manager time to plan a transition. Talking to her colleagues can also be helpful – they may know of even better opportunities for what they perceive her strengths and interests to be.

Truth be told, I have a bias towards developing a broad base, I think that a wide range of experience gives a BA a qualitatively better perspective to assess risk and benefit. You could argue that while I’m a generalist business analyst, that is, I have no expertise in any applications or infrastructure technologies; I have also specialized in being a generalist. In the same breath, I could argue that a Finance BA who systematically becomes proficient with every module in Oracle ERP is a person who has generalized specialist skills in a single application.

There’s plenty of wiggle room in the specialist – hybrid – generalist model, which is one of the beauties and aggravations of Business Analyst position. There’s more to job-hunting than just responding to job postings and shaking down your LinkedIn network for leads. Think about what you want from your career, what you are curious about, what skills and experience you want to acquire to make yourself the right BA for the jobs that interest you as well as the right BA that the hiring manager is hunting for.

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times and most recently the poem, A is for Analysis. See her blog on her personal passion, motorcycle riding, at http://www.balsamfir.com. [email protected]

The Bad Ass BA Observes the Hunt for the Right Business Analyst

Written by Cecilie Hoffman on January 25, 2011. Posted in Articles.

Like so many other people, I’m job-hunting. Job-hunting is never easy, even when you are doing it from the relative safety of having a job, but one that you would like to leave. In this era of the robo-online job postings, job-hunting feels particularly demoralizing because most companies do not provide any form of closure on your application. You apply, you get a robo-acknowledgement of your application and then you hear nothing for weeks and months. In four months of searching I have received exactly one email, machine-generated, that thanked me for my application and informed that the position had been filled. That organization went to the top of my list for, “keep an eye on them – they would be good to work for” because of the implication that someone had written a requirement to actually close the loop with applicants!

There are some good job postings out there, jobs that describe a position with required skills, experience and responsibilities that make sense for a business analyst. There are also a plethora of weird job postings wherein the job described seems either too narrow or too broad or suffering from role confusion. I’m seeing pattern in these less-than-optimal job postings. It seems that every company has their own definition of the role of the Business Analyst. From where I sit it is going to take more than a grass roots effort from the BA community to bring together the HR / hiring manager view of the BA and the IIBA’s vision of the BA. Here are four patterns in the job postings that cause me the most consternation:

Pattern #1: The “Bird in a Cage” model

Requirements jockey – We need you to handle proposal requests. You will write the BRD and throw it over the wall to the outsourced development team.

Requirements change control czar – “We need a patient, detail oriented, people-oriented person with excellent documentation skills.” Translation: you will be in the person that everyone complains to. The users and their managers will always be escalating; the development team will always be exhausted, and the auditors will always be looking for something to be wrong with the record keeping.

Pattern #2: The “Two for One” model

System Analyst / Business Analyst – “The successful BSA will drive end user experience innovation. Must have professional software development experience with front end web development (JavaScript, HTML, CSS, AJAX) and the ability collect requirements from stakeholders.”

Quality Assurance Analyst / Business Analyst – “You are the right person if you can model business processes, facilitate discussions and write detailed business requirements and use cases, facilitate walkthroughs of detailed business requirements and use cases, and perform functional tests.”

Project Manager / Business Analyst – “You are the right person if you can compartmentalize the perspectives and responsibilities of a PM and BA for a business owner who dithers. The last BA hired was great at dealing with the project stakeholders musing about changing direction, but her head exploded when she put on her PM hat and considered the ramifications to the project.”

Pattern #3: The “All in One” model

“You are the right BA for this company if your background includes an MBA, and MA in Information Science, and you have managed projects, and you have both IT and product development experience, and you have worked with marketing and sales teams and you are fluent in Mandarin Chinese, Russian, and Portuguese. 50% travel.”

Pattern #4: The “clone the 25-year veteran who just retired” model

“The right BA for us has experience in our customized PeopleSoft modules, can modify Business Intelligence reports, is familiar with SFDC, can do a mind meld with stakeholders, can hold the requirements traceability matrix in their head and can mentor junior business analysts.”

The IIBA is already working with PMI so that there will be a better understanding of the contributions of the two roles to future projects. Perhaps the IIBA might consider an initiative to work with Human Resources professional organizations as well. In my humble opinion more could be done to educate HR staff and hiring managers about the role of the BA. In many companies, “job reqs” (job requisitions) are drafted by the hiring manager and completed by an HR staff member. If that HR staff member were more familiar with the envisioned industry standard BA role, we might see fewer job postings like the ones above. In my ideal world, there would more consensus amongst companies about the role and value of the business analyst. Moreover that consensus would be in alignment with the IIBA vision, and we wouldn’t see job postings that leave us scratching our heads in bemused consternation.

Don’t forget to leave your comments below.