Skip to main content

Tag: Business Analysis

Business Analysis: Is it a Bottleneck in Your Project?

How often is a project manager, architect or developer waiting on the Business Analyst to complete a requirements document, finish a model, or finalise a process. As all business analysts (BA’s) know it takes time to identify and talk with all stakeholders, elicit requirements, analyse them, then document and review them. And as good business analysts we all want them perfect and very detailed with no ambiguity.  But how do you produce such well defined, clear, concise, non ambiguous and detailed requirements in projects where expectations are greater, deadlines are getting shorter and budgets are tighter.  As the time given for gathering and documenting requirements decreases, so too does the detail and quality of the documented requirements.  We all know how long creating those amazing models takes.

I have worked in a number of organizations and on many projects, and it is common in project teams to have only one person acting as the business analysis on requirements, while there is  a team of developers making the code changes or developing the software from scratch. After all – often only one requirements document may be being produced so why put more than one person on it.

Getting good quality detailed requirements is critical to a project and a good business analyst is required to produce them. But why not put two or three or maybe even more business analysts on a project or function. When was the last time you worked on a project where business analysts outnumbered developers? So why not have more people working on one of the most critical phases of a project? Some of the advantages are shared knowledge, collaboration, peer reviews, a greater range of ideas and possible solutions, and reduced timeline if more resources are available.  And any cons can be overcome with good project and document management techniques and tools, even egos can be overcome.  But often a company’s business analyst’s resource is stretched and putting more than one on a project or function is just not possible.

So if we can’t apply more people to the problem of reducing the requirements timeline then how else can we do it?  Well we see more and more talk about agile development methods where business representatives talk directly to the developers cutting out much of the need for BA’s.  This can work in the right situation and in the right environment, but many companies and projects have found agile causes more problems with overruns and quality issues when not fully embraced and understood.

I have seen a project work where multiple BA resources worked on the requirements and specialised in particular areas. The requirements were not completely detailed up front but the business vision was, and high level requirements were documented to a level that allowed estimation to be performed.  Then as each iterative development phase started on each business area the BA responsible would verbally present his or her concept to the development team in detail, with mock screen shots or story boards, models of the process, and associated business rules. Allowing the developers and testers to see the complete picture as well as the detail is important and allowing them to ask questions and seek clarification on issues instantly speeds up the process of transferring information.  If anything does change then an efficient and quick change management process is very important.

The process of documenting requirements is often a lengthy one that produces many large documents. I know I have written many large requirements documents full of detailed requirements, Use Cases and diagrams in my time.  On the positive more time gives our requirements more detail and clarity, unfortunately this can often lead to more time spent on changes and change control.

So is a large requirements document or many Use Case documents the best way or best practice.  Well the answer is it depends. It depends on the organization and their development process and rules, and if the whole team is located together. Some organizations still have a very rigid waterfall development framework, strict financial models, that requires formal reviews by a large number of stakeholders before the next phase progresses. They rely on large detailed requirements documents and accurate cost estimates. The costs are a large part of this process and it is easy to understand all these controls in a large organisation, but it does mean the requirements process of capturing, analysing, documenting and reviewing requirements takes a long time. We see more and more press about agile development methods and many companies want to take advantage of these without understanding how their whole development framework needs to change.

So what we want is a way of speeding up the requirements process without losing any of the detail or the communication to stakeholders that allows them to confirm the requirement and therefore deliverables are correct.

Vision documents are excellent at capturing the stakeholders’ vision and needs of what is to be delivered, and Use Cases and User Stories are effective ways of communicating how someone will interact with a system and how it will respond, as well as capturing the all important alternate and exception conditions.  The quality of service requirements are also important as they give us the parameters by which the system must operate under.  Other supplementary specification documents capture report and interface requirements.  So it is important we capture all of these things and convey them for approval to the stakeholders and developers.  It is how we do this that can change and speed up the process.

I know if I have to stand up in a room and present requirements or Use Cases to a group of people I really want to know and understand what I am talking about so I can not only present it well I can also answer questions on them.  So if I have to present requirements to stakeholders or developers and a view of the proposed system then I also want to know I have captured all the detail and understand it well. People also seem more open to asking questions when there is someone there to answer them.  You also have the advantage of seeing if people are confused or lost when you’re explaining something that allows you to rephrase or simplify what you’re saying.

I have found that by talking to stakeholders and developers you are able to convey more information and understanding than from just a written document, in a much shorter time frame. But it is important that everyone hears the same information and gets the same picture.  So conveying requirements verbally to developers is seen as answer to speed up the development process as we see in agile development, especially if you are always available for developers to confirm details with.  As with anything there are risks but there are ways to mitigate them.

So in my experience a middle ground is important.  We need to capture the business’s vision in a document because it will be referenced a lot and it is an important we capture it in detail and clarity.

With requirements and Use Cases capturing a high level view is important but much of the detail can be conveyed verbally. We need to capture enough detail to ensure we have identified everything and have enough detail to perform a preliminary estimate. And detailed use cases are important for critical or high risk parts of an application.  And working closely with developers, architects, and testers is important.  After all it’s about the solution and not just the requirements.

Don’t forget to leave your comments below.


Ross Wilson is a Principal Consultant with Equinox Limited in Auckland, New Zealand, specialising in requirements management. He has been working in IT for 27 years and has a wealth of varied project experience in a number of different industries. For the last 14 years, he has focused on business analysis, project management, and team leadership. Ross can be contacted at [email protected]

Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 2)

In Part 1 of “Business Analysis in Flow – The Work of the Agile Analyst ,” I talked about the new skills and attitudes business analysts need to bring to agile development. When your organization adopts this value-centered approach, you need to have, as I wrote, “a tolerance for ambiguity along with a concurrent drive for specificity and closure.”

Now it’s time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let’s take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.

Setting the stage: Requirements planning activities

To set the stage for requirements, the team strives to create a shared understanding of the product by all the stakeholders.

Traditional Analysis Agile Analysis Adaptation
Attend project chartering sessions to define a vision, glossary, requirements risks, and product stakeholders.
  • Design, facilitate, or participate in product vision and roadmapping workshops.
  • Help your customer understand which roles and themes to best deliver in each product release.
  • Help your customer and team identify logical groupings of value-based requirements, and use these groupings to create a product roadmap showing incrementally delivered requirements over time. These requirements often take the form of minimally marketable features, stories, or epics (i.e., large stories that cross releases), use cases (high level only), events, or a combination.
Review and modify a list of tasks, time, and delivery dates in a work breakdown structure plan developed by the project manager.
  • Design and facilitate (or participate in) release and iteration planning workshops.
  • Regularly prune the product backlog by collaborating with team members to generate a relative size estimate for backlog items.
  • Conduct analysis “spikes” (short, timeboxed research stories) to elaborate on backlog items that need more analysis, researching requirements and their priorities.

Generate a SWAG (“S#*&-Wild-Ass-Guess”) estimate of time, effort, or cost for each requirement in the specification or user requirements document.

  • During iteration planning, together with the rest of the team, write down the needed tasks to deliver each user story, and estimate how many hours they will take.
  • Share actual time usage information with your team so that the team can track progress via visual graphs (“information radars”) such as burndown, burn up, or cumulative flow diagrams.

Requirements elicitation activities

During requirements elicitation, the team identifies the sources of requirements and then discovers, derives, evokes, and elicits requirements from those sources.

Traditional Analysis Agile Analysis Adaptation
Plan how to elicit requirements using a variety of techniques.
  • Use face-to-face, collaborative elicitation techniques (workshops, prototypes) as much as possible while avoiding techniques (interviews, surveys, documentation study) that require longer lapse times or interpretation.
Plan, design, and facilitate requirements workshops over weeks (or months).
  • Plan and facilitate short, informal requirements modeling sessions throughout each iteration.
  • Plan and facilitate product vision and roadmapping workshops and release planning workshops.
  • Teach your customer about supplemental analysis models so that they can question, participate, critique, review, and approve them (this should be done in traditional projects as well).
  • Sketch out prototypes and identify user acceptance test data in real time, while a story is being designed, coded, and prepared for testing.

Requirements analysis activities

During analysis, the team seeks to understand and define requirements so that stakeholders can prioritize their needs and decide which requirements to build.

Traditional Analysis Agile Analysis Adaptation
Define the scope up front by using a set of requirements models as the basis for detailed modeling.
  • Help your customer define the vision and the scope up front-at a high level only.
  • Help your customer and team create lightweight models during product roadmapping and release planning. These models help customers carve out a value-based release schedule that balances business priority with architectural dependencies.
  • Collaborate with architects and developers on design to ensure that requirements include the technical aspects of the product.
Develop analysis models for the entire set of requirements that are in scope.
  • Help your customer and team develop stories (user stories as well as stories that incorporate or separately define quality attributes).
  • Help your customer and team develop and extend analysis models that support understanding backlog items selected for delivery in an iteration-if and when needed.
Ask the customer to prioritize requirements using a ranking scheme. If the customer is not available, do the ranking yourself.
  • Help your customer assign a business value and a ranking to each backlog item.
  • Help your customer understand requirements dependencies that might warrant adjustments to backlog rankings.
  • Question rankings based on goals or themes for upcoming release or iterations.
  • Assist your customer and team to right-size high-priority backlog items that are too big to deliver in combination with other high-priority backlog items in the next iteration.

Requirements specification activities

Specification involves refining and organizing requirements into documentation (typically a software requirements specification). This includes the entire set of functional and nonfunctional requirements to be transformed into design, code, and tests.

Traditional Analysis Agile Analysis Adaptation
Write a requirements specification.
  • Help your customer and team write stories (or if you’re acting as proxy customer, you write them).
  • Create doneness criteria for stories so that each becomes a well-defined, small piece of valuable software for delivery in the next (or current) iteration.
  • Create user acceptance tests or sample input and output data for each story.
  • Determine the form and format of documentation that is necessary and sufficient for requirements-related work-in-progress, handover, or product documentation.

Requirements validation activities

During validation, the team assesses whether the product satisfies user needs and conforms to the requirements.

Traditional Analysis Agile Analysis Adaptation
Set up and run meetings to review and sign off on requirements documents, and help customers run acceptance tests after the entire product’s code has been created.
  • Meet with the customer and some team members to prune the backlog (once or twice each week).
  • Participate in iteration demonstrations and listen to stakeholder feedback on the delivered requirements to learn the customer’s real needs and determine how to adapt the evolving product.
  • Plan and facilitate, or participate in, iteration retrospectives, and learn from the customer how you can help deliver value faster.
Communicate with developers or testers (or respond to their e-mails and calls) to explain information in the requirements document; attend or run formal requirements review meetings.
  • Conduct just-in-time analysis modeling with customers and your team to validate the business value of each story and to ensure it will be delivered to the customer’s satisfaction.
  • Participate in daily stand-ups.
  • Sit with developers and testers as they are building code and tests to explain the story and its doneness criteria.
Help testers create user acceptance tests, or run those tests, after the entire product has been designed, coded, and unit/system/integration tested.
  • Define input data and expected results or specific user acceptance tests as part of defining doneness for each user story, iteration by iteration.

Requirements management activities

Requirements management involves monitoring the status of requirements and controlling changes to the requirements baseline (“a point-in-time view of the requirements that have been reviewed and agreed upon to serve as the basis for further development,” Gottesdiener 2005).

Traditional Analysis Agile Analysis Adaptation
Establish the requirements baseline, document change control processes, and generate requirements trace matrices.
  • Help the customer and team establish a product backlog and define the smallest necessary requirements attributes for each backlog item.
  • Help the customer and team define “just enough” requirements tracing needed to satisfy external regulatory body expectations.
  • Help the team determine simple, meaningful requirements mapping and organizing (features to stories, events to stories, etc.).
  • Define simple, unobtrusive ways to trace stories, with the aim of capturing metrics that will be useful for reuse and promoting development efficiencies.
Attend or schedule change control meetings.
  • Help the customer and team prune the product backlog continually (reprioritize items, break down stories, assign rankings, estimate size, and explore requirements dependencies that will impact architecture and therefore release planning).
  • Help the customer maintain the product backlog items (on story cards on a wall, in a spreadsheet, or using an industrial strength agile requirements management tool)-or do this on behalf of the customer.

Learning: The heart of agile success

A mantra for agile teams is “inspect and adapt.” This means regularly checking on the delivered product and the processes used. Continuous improvement (called “kaizen” in lean approaches) is essential to agile success. How do you inspect and adapt your business analysis work to learn and develop?

Traditional Analysis Agile Analysis Adaptation
  • Participate in milestone or project “lessons learned” sessions to find out what went wrong, what went right, and who is responsible for the problems. The project manager fills out the lessons learned template and writes the closeout document.
  • Sit with your manager once or twice a year for a performance review, and get feedback on your performance, months or weeks later. Sometimes that feedback includes second-hand comments from your customer and team.
  • Use acceptance tests, examples, sketches, simple drawings, and face-to-face communication to get feedback on your understanding of requirements.
  • Participate in daily stand-up status meetings to hear the impact you are having on other people’s ability to deliver.
  • On any given day, as an item you committed to deliver is deemed done, show it to the customer to get feedback on it and confirm that the conditions of satisfaction have been met.
  • Design and facilitate, or participate in, iteration and release retrospectives (every two or three weeks, depending on your iteration timebox) to learn what works, learn what to adapt, and collaboratively agree on one or two things to do differently in the next iteration or release. The goal is to learn, adapt, get better, and experience joy in your work.

The new world of agile analysis

So there you have it – a bird’s-eye view of how business analysts operate and add value in agile projects. As you can see, this approach calls on you to stretch your analysis muscles.

As an agile analyst, you are deeply committed to delivering business value and building the right product as soon as possible. As a member of an agile team, you are less concerned with roles and job boundaries, and more concerned with delivering as a team.

You experience the rhythm of successive elaboration and product delivery. You thrive on feedback and small, continual improvements. What’s more, you have an intense need to self-reflect, communicate transparently, improve your skills and abilities, and serve your team and customer. You thrive on the energy and joy of being in rhythm with an agile team.

Thanks!
The author would like to thank Phil Abernathy, Susan Block, Mary Gorman, Kamal Singh, Norman Stang, and Stephanie Weiss for their helpful review and feedback on a draft of this article.

Copyright © EBG Consulting, Inc., 2009

(This article first appeared in Modern Analyst, May 2009)

Don’t forget to leave your comments below.


Ellen Gottesdiener is the Principal Consultant and Founder of EBG Consulting, Inc. She helps business and technical teams collaborate to define and deliver the product customers value and need. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. As an agile coach, trainer, and contributor to the agile IIBA BABOKTM agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. Learn more from her articles, tweets and blog, free eNewsletter and find variety of useful practitioner resources on EBG’s web site.

References

Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. GOAL/QPC, 2005.

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

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:

Cecilie_Article_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.

Cecilie_Article_Image2

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

cecilie_Feature_CroppedLike 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.


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].

Is Your Business Analysis Process Like Buying a Car?

Kupe_Blog_Dec_7This past weekend my wife and I bought a new car.  I was replacing my 14 year old Ford Explorer and had 3 cars in my sights. I went to 3 dealerships to test drive those cars.  What a nightmare!  I thought the car buying experience was going to be better than 14 years ago.  I actually think the process is worse.

With all the online tools available and my network of friends I did all the research.  I knew which cars I liked, what the dealers pay for the cars and what people in my area have been paying for them.  The first step I took was to submit my information on the dealership’s website, get a price quote and set up an appointment to test drive the car.  For each dealership I received an automated email stating I was a preferred customer and when I arrived at the dealership I would speak directly to a manager. The manager would work with me to test drive the car and settle on a price.  I was lead to believe I could expect to be in the dealership for 30 minutes to an hour.  With my preferred customer number the dealership had all my information.  What a great way to buy a car, right! Absolutely…if it actually went down like that. 

When I arrived at the dealership, I was quickly moved to work with a salesperson who started to ask me what car I was interested in. He broke out a form and began asking me for my name, phone, address, email etc.  I am a calm and patient person, but this set me off. This person knew nothing about me and it would take 30 minutes to explain what I already shared with the dealership online.  I left the dealership letting them know I was not planning on buying a car from them.  Could you believe 3 days later I received an email from the internet dept. of that dealership asking me if I was still interested in a car. Aah!!!! I was reminded why I don’t buy cars often.

Is your business analysis process like buying a car? I hope it is not close.  Your process needs to be customer focused.  I spoke with someone a few weeks ago and her organization was still in a “throw it over the fence” mode.  That fence was so high and thick that she never received a question from the developer and was not even sure what the implemented solution looked like until it was in production.  When she told me, the look on my face had to be saying, “Are you kidding me?”  I assume her business stakeholders felt like me when buying a car.  They shared information with the BA and then when the developer had questions they were probably asked the same types of questions..

At another company they did not throw it over the fence, but they still used a poor version of waterfall. The developers and QA team were not brought in at the beginning of the project.  The BA would review requirements with the tech lead and QA lead that would then estimate the build and test portion of the project.  If the high level estimate was approved developers and QA analysts were assigned.  You think they had questions? Even if the questions were not asked directly to the business stakeholder, their time and money was being spent on a lot of knowledge transfer.  

This extra time and some unnecessary back and forth with your business stakeholders does not help promote the value of Business Analysis.  As the BA you need to raise your hand and demand some change if your project lifecycle is not customer focused.  Your role is to help implement solutions to improve the business area you support.  Always make sure your process is geared towards that goal. 

 Always be easy to deal with,

Kupe