Author: Angela Wick

Good Meetings create shared understanding, not BRDs!

Written by Angela Wick on March 17, 2015. Posted in Articles. 1 Comment on Good Meetings create shared understanding, not BRDs!

Deliverables and artifacts were a focal point of BA work during the early part of my career. If I look back, it seemed the primary purpose of a BA was to generate paper—lots of paper—usually in the form of a giant BRD (business requirements document), and other related artifacts to support the Software Development Lifecycle and Project Management Process. As I grew in my career I realized my role as a BA was much more, and continued to evovle and struggle with the role of the template and paper.

As business and projects evolve, the primary purpose of the BA role is evolving too and increasingly has very little to do with paper! Not that agreed upon requirements are not important, please hear me out!

Many BAs still operate in a traditional environment where their requirements process flows like this:

Gather requirements (usually in a large, 20+ person meeting, series of meetings, and interviews).
Fill out requirements templates (usually alone in a cube).
Send out the requirements document and schedule the sign off meeting
Review requirements and hope for sign off (Another big meeting).
Re-write requirements (usually alone in a cube).
Review requirements (another big meeting, or send via email).
Re-write requirements (usually alone in a cube).
Harass and stalk many people until they re-read (probably not), and sign-off requirements.

Is it possible to achieve success using this approach? Maybe, but meetings like this are not effective and limiting your deliverables to a set of one-size-fits-all templates leaves too much room for gaps and errors.
In contrast, BAs who operate on teams with a more modern, flexible and collaborative approach operate under different expectations. They still need to perform standard BA functions and tasks, but with a different mindset and approach, this BA:

Modifies their BA approach based on the unique needs of each project.
Schedules small groups meetings to develop shared understanding
Uses interactive, visual facilitation techniques to help the team discover and learn together.
Produces only documentation needed by the team to move forward each day.
Is okay adding visuals and models to the templates, and okay with using models and diagrams for the sole purpose of creating conversation, the diagram may or may not end up in a formally signed document.
Delivers “shared understanding” instead of or with a BRD

Maybe the process would flow something like this:

BA drafts a visual model.
Team reviews and reacts and learns. (Update model collaboratively.)
BA drafts additional visual models.
Team reviews and reacts and learns. (Update models collaboratively.)
BA documents only items needed by the team to move forward.
Team weighs in on what is valuable for them to move forward.
Team reviews and approves documentation. No surprises (or stalking) because the BA has developed SHARED UNDERSTANDING!

This scenario offers many benefits, including:

Consistent collaboration: Collaboration happens throughout the process. Instead of the BA filing out requirements templates in solitary cube confinement, the team uses visual models to “write” the requirements collaboratively.
Shared understanding: The BA does not “own” the requirements, the team does. The team shares an understanding of the value, goals and vision of the project. The shared understanding instills trust and confidence. The BA facilitates this process.
Processing time: You have time between meetings to process, analyze, and find gaps and issues and constraints. You are able to bring up these questions and issues to the team, maybe create a visual to help the discussion along.
Strategic Documentation: The requirements package changes for each project. Deliverables have a specific purpose and require much less rework if the shared understanding has been developed in advance!

As momentum swings toward this more flexible, just-in-time approach to requirements, how does the BA role change? How do we adapt? Which BA competencies become more important? If we aren’t supposed to be sitting in our cubes updating templates and generating paper, what should we be doing? What skills do we need to develop?

It may sounds simple, but as collaboration becomes the focus of project work, BAs really shine when they become expert meeting facilitators, conversation architects, and agents of change readiness.

These expert skills go beyond the basics of setting and agenda, keeping participants on task, tracking action items, and writing minutes. BAs with expert-level facilitation skills know how to:

Use visual models to get conversations started and highlight gaps in shared understanding.
Engage everyone using techniques that allow introverts and extroverts to contribute.
Use interactive techniques that inspire people to engage physically.
Make meetings efficient and valuable for all participants.
Gather large amounts of information in a short amount of time.
Create a collaborative environment face-to-face and virtually.
Process and analyze the results of each collaboration session to make the next session productive, helping the team move steadily toward their goals.

Meeting time is so precious. Expert facilitators make the most of attendee time by building a shared understanding of value and purpose. It’s part of an Agile mindset that can and should be used in all project environments (traditional, Agile, and hybrid). Creating a shared conversation and shared understanding is more important than what’s on paper.

Honestly, shared understanding done well may mean a lot less documentation, you are the judge of how much documentation is valuable to the team.

So, how do BAs know when they have reached this level of shared understanding? Here are a few hints:

People tell you! Eager stakeholders ready and willing to comment that they feel heard and are ready to move forward
Stakeholders are not looking for or grasping for issues for the team to discuss, they feel confident the most important pieces are covered
They feel they are reading a review of what was discussed when they review the final deliverable
Stakeholder consistently contribute with an understanding of other stakeholder impacts and a big picture view of their needs
When you “check in” with them on how the process is going, they enthusiastically are getting a lot out of the meetings and team interactions.

Using expert facilitation skills to reach a shared understanding with your team will lead to less defects and fewer enhancements. When BAs focus on learning and discovering, instead of just collecting and recording, they will boost their team’s ability to navigate complex change.

Don’t forget to leave your comments below.

Get your Requirements Off to the Right Start with these 5 Steps!

Written by Angela Wick on February 16, 2015. Posted in Articles. 1 Comment on Get your Requirements Off to the Right Start with these 5 Steps!

It’s project kick-off time! February, more than any other month, tends to be the time when organizations transition from planning to action. New initiatives have been prioritized, dollars have been allocated and teams are being formed—everyone is ready to get to work.

BAs being assigned to these projects often working with new PMs or new leaders and sometimes leaders expect BAs to jump in and start detailed requirements, like NOW! BAs are often asked to begin gathering requirements before solution scope and context are defined. The project scope might be defined, but that does not mean the solution scope is defined.

Most leaders I talk to would say they expect that BA start with scope and context activities and some planning, yet BAs don’t feel that is what leaders are asking of them. BAs feel they are expected to jump into specification level of detail based on expectations from leaders and business stakeholders, coupled with unrealistic deadlines.

BAs might be tempted to go with the flow and jump right into detailed requirements. Instead, we need to rock the boat a bit, think strategically, and advocate for the time needed to properly get requirements right and avoid the rework. After all no matter if we are working on agile or traditional projects, rewriting and reworking requirements because we jump to writing details vs. aligning on the big picture spells waste and disaster. Our leaders DO want context and the big picture defined, even if they seem focused on details and deadlines. Here are 5 things BAs should do to build a solid foundation for their requirements:

Create a Scope/Context Diagram: A high-level scope/context diagram helps the project team understand the boundaries of the solution. Agile and traditional teams benefit from this critical visual of the solution. It helps the team identify stakeholders, processes, products and systems that will be affected by the solution. The diagram offers a great starting point for dialogue when BAs begin their work. Even when assigned to a project late in the game, I start with this as a critical tool to build credibility with the team that I understand the scope of the solution, its impact. Stakeholders and I have alignment to where the details fit into the bigger picture, and this makes planning easier. I find leaders LOVE these diagrams and teams can rally around all the details once everyone has the same big picture visual to understand where the various details fit in.
Document The As-Is and the To-Be: The as-is and to-be models, often presented in the form of a diagram rather than text, are a valuable tool for defining gaps between the current state and the future state. These models can model the process (current and new), the product (current and new) or the system (current and new). They are really great at showing the changes that will be taking place and that we are eliciting requirements for. These don’t need to be at a detailed level, they should be high level to start, adding detail if needed. Agile and traditional teams will rally around full understanding of what details impact what parts of the bigger process with the proposed changes.
Most BAs see the value in this information, but they get caught up in details. We need to put our reading glasses and microscopes away and look at the big things. Outline the major differences between the current state and future state before beginning with the details.
Identify Stakeholders: Who are your primary stakeholders and how will the solution impact their team, processes, and/or systems? This step seems so obvious. We know our stakeholders, right? We always have a list of key leaders and SMEs before a project begins. Have we taken it to the level of what user roles are impacted and how? And communicated/reviewed this with all project stakeholders.
A key analysis at the beginning is to identify all user roles impacted by the solution and how they are impacted. This gets elaborated as we discover more, and a high level to start can really help the team move forward with very positive results.

In truth, projects rarely start with exactly the right stakeholders. They either start with an unnecessarily large group (everyone), that we help refine and manage based on impact, or with small group that expands with the scope.

When we leap into requirement details too quickly without solution scope, context, as-is and to-be, we miss stakeholders, which means we miss requirements. We use extra time to get these stakeholders up to speed on the project and they often miss the very important collaborative processes in the initial phases of elicitation.
Outline Acceptance Criteria: Similar to the future state, acceptance criteria outlines the minimum criteria that will make the solution a success, and gives BAs and stakeholders a glimpse of the future. BAs begin to understand what success looks like and this picture keeps us focused on value. The strategic focus on value helps us make good choices along the way. On agile teams acceptance criteria is often paired with User Stories; here I am discussing the entire solution, so a comparable term in agile is MVP (minimum viable product) and its criteria.
Tailor the BA Approach: For every new project BAs should consider what is new or different about the project. Which techniques will work best in the project environment to best define the solution? Is there more or less risk? In what areas? How can we use techniques to mitigate them? Custom development projects have a very different approach then package software, and process improvement projects are different as well. The same approach, techniques, and templates will not work, we need to tailor the approach for the unique project and solution characteristics.
Even if the deliverable list remains the same for every project from a governance perspective, we always have flexibility in how we elicit the information and how to use the templates. For example, a package software project might require us to dig into and understand the vendor capabilities and functions and do a gap analysis, then user demos and prototyping with the vendor package. Whereas a project to build a new in-house system, with team members scattered across the world might require a series of virtual requirement workshops focused on the users, what they need, and why. Prepare for these differences and prepare the team for them.

When we consider these activities carefully, we quickly realize they are interdependent. BAs need to work through them iteratively, circling back through each task multiple times as the project evolves. For example, we can’t really develop a high-level scope diagram without the help of some stakeholders, and we can’t identify all stakeholders before you define the scope.

Because of this spiral effect, BAs need to be very aware of “good enough.” We need to be efficient in order to be effective. Don’t worry about perfect or complete. Focus on the main components and the quality of dialog, engagement, and relationship building with your stakeholders. We need to focus on what we need to generate and maintain your focus on value throughout the project.

Don’t forget to leave your comments below.

We’re Agile, You’re Agile, Why are We Struggling?

Written by Angela Wick on January 19, 2015. Posted in Articles.

So, here’s the scenario: Your organization wants to purchase packaged software to support a key business function. Your team thoroughly evaluates several products and chooses the best fit. During discussions with the vendor, you discover they “use Agile.” This is great because your organization “is Agile” too! Awesome! Contracts get signed and we all get to work.

Then, things start to go awry as your assumptions jump out of the dark corners and startle your progress. Communication crumbles, messages are confused, processes and practices differ, team dynamics and what even is “a team” seems to be a huge struggle. You soon discover that the most basic agile terms being used do not mean the same thing! Your version of Agile does not align with your vendor’s version of Agile.

Ah….as a project team we have gotten trapped into defining agile vs. being agile in the face of chaos. When we try to work things out, all the definitions, contracts, processes, and promises lean us towards anti-agile patterns to clear up the confusion. Instead, we may need to focus more on being agile as a team.

I’ve seen many 3^rd party relationships crash and burn during their first implementation effort simply because they did not discuss, up-front, what being an agile team means. You need to go beyond “We are Agile” and really did into the details. Here’s how to get started:

Describe the team structure. Many vendors are agile only within their team and practices once they get contracted work from the client until they hand it back. This can be a huge problem if the project team overall expects all teams (client and vendors) to work together as a single agile team. Many agile mindset patterns are broken once two teams “hand off” to each other.
Questions you should ask the vendor: How do you integrate your team’s agile practices with the client teams? How do you envision the teams working together in an agile way? What challenges have you previously had working with other agile organizations and how did you resolve them?
Describe practices/methodologies. Again, agile is really a mindset, and approach. Under the Agile umbrella there are many methodologies and practices. You should compare your practices to your vendor’s. Discuss how you will fill any gaps.
Questions you should ask the vendor: What does Agile mean in your organization? How do you elicit and mange requirements? What’s your approach for code development? How do you support testing? What does implementation look like?
Discuss deliverables/artifacts. The output from agile teams can vary dramatically: some teams might generate reams of paper or gigs of data for each iteration, other teams might generate a wall of sticky notes, and some teams produce zero artifacts…their only deliverable is the working product. If your organization has requirements for product documentation, you need to know if the vendor can meet these expectations. Make sure your governance needs are discussed.
Questions you should ask the vendor: Does your company produce any project documentation beyond the working product? What documentation is created, when, by who, and for what purpose? How do you document issues, priorities, test cases, etc.? What documentation is expected from the client team to work best with vendor agile practices?
Discuss roles. Some Agile teams subscribe to a strict Scrum methodology, and some are Scrum-like, using aspects of Scrum, but not as a methodology. When working with an agile vendor, roles and responsibilities should be clear to ensure efficient communication and collaboration. Make no assumptions on what roles and titles do, and make sure the vendor is not making assumptions of your roles either.
Questions you should ask the vendor: What support roles will you provide? What are their functions? How do they align to our team structure? What roles do you expect our team to have and how will they work together with your roles?
Define Terms. Terms often mean different things across organizations. In some places, a scrum might just be a daily project meeting. In other places, the word is used to define an entire philosophy or methodology. Ask your vendor to define the terms they use when discussing their agile approach. Other terms that I see often confused: Sprint, Story, User Story, Task, Acceptance Tests, Requirements, Defects, and Backlog.
Questions you should ask the vendor: What does Scrum mean to you? How do you define a sprint? How do you define the start and end of an iteration? What is the definition of done? What is your definition of Epic (User Story, Feature, Task, etc. . . .)? How would you describe a retrospective?
Discuss theory versus practice. Even if you share similar definitions for each term, take your questions one step further to understand how your vendor applies these terms in day-to-day work.
Questions you should ask the vendor: What does a daily scrum meeting look like? What does testing look like? How long are your average sprints? How do you prioritize the items for each iteration?
Dig into user stories. User stories also vary dramatically by organization. They usually encompass multiple pieces of a solution to get to the essence of value to a user. Therefore, your vendor user stories might only reflect a small part of one user story (the part they deliver) for your organization. This is a common issue and means value is not aligned between vendor and client, and this will cause a multitude of issues for the project and solution.
Questions you should ask the vendor: What do your user stories look like? What level of detail do they go to? How do they integrate with other user stories in my organization? Could I see a sample user story? What techniques does the team use to elaborate on the detail of the user stories? Whose role is it to create the user stories?
Describe collaboration. Collaboration is a key component of the Agile Manifesto. Many teams who use an agile approach require the team to sit together in one room for the majority of their working hours. Other teams collaborate once per day during their daily Scrum and then go back to their cubes and work independently, all day (not recommended!).
Questions you should ask the vendor: What does collaboration look like in your organization? How do teams share information with each other and with other teams? How does communication happen within a day and day by day? Are meetings planned or spontaneous? What do meetings typically look like? Could we watch one of your teams work for a few hours?
Discuss testing scope and terminology. User testing often means something different to your vendor. Their focus can be quite narrow as they are focused only on their small piece of your organization’s end to end solution.
Questions you should ask the vendor: What does user acceptance test look like? Does the vendor support processes required to integrate their product to other systems?

Obviously, the depth you go to in investigating the agile practices of your vendor depends on the scale of the relationship you are forging. Small package software projects might require just a short discussion related to key support functions provided by the vendor. Large scale partnerships involving integrated teams, high risk, high costs, lots of custom code, or hundreds of user defined settings require deeper discussions about agile practices.

Either way, don’t make the mistake of focusing only on the product and its features. Spend some time understanding how your vendor approaches team work, collaboration, requirements, development, testing and implementation. Collaborate and talk through it together, before the contract is signed. Don’t assume your Agile and their Agile is the same.

Don’t forget to leave your comments below.

Virtual Requirements Meetings: Painful or Practical?

Written by Angela Wick on December 15, 2014. Posted in Articles. 1 Comment on Virtual Requirements Meetings: Painful or Practical?

Painful! Definitely!

The idea of sitting through a requirement workshop via teleconference seems like torture. Virtual requirements meetings tend to bottleneck our ability to effectively collaborate. Attendees and facilitators:

dread the dead air and the anonymous beeps in and out: “Hello, this is Angela. Who joined?” “Bob. Bob? Bob, are you still on the call?”
seem lost without visual cues like hand raising, eye rolling and head nodding. “Does everyone agree with that change? Is there anything else we need to add?” Silence. Facilitator wonders: “Does that mean everyone agrees or no one is paying attention or everyone is talking on mute?”
feel constrained when they can only collect/offer information verbally, one person at a time.
feel limited when their most successful in-person techniques don’t translate to a virtual environment.

Painful, but Required!

Despite the dread and pain, the need for effective virtual collaboration is increasing. Even in small to mid-sized organizations, it’s rare to find all stakeholders sitting in the same building or even in the same city.

Every partnership, packaged software purchase, acquisition and merger, expands the geographical and administrative footprint of an organization, making face-to-face collaboration more expensive and more difficult to schedule.

Instead, we conduct most of our professional business virtually via phone, email, or instant message. Face-to-face communication, even in our personal lives, seems to be dwindling. (I know you have sent a text to someone in your home instead of walking to the other room to talk to them!)

Whether we like it or not, virtual communication is a key requirement in our modern, global and mobile life! So, until we can teleport or project Jedi Council-style holograms, we need to find a way to make current virtual collaboration methods, like conference calls, more efficient and effective.

Let’s Get Practical!

If there is a practical need to boost our virtual communication competencies, then where should we begin? How do we address the pain points that prevent us from feeling comfortable with virtual requirement meetings? Here are a few ideas:

Chunk It. Don’t try to do requirements for the entire project in a series of 5 consecutive, full-day virtual sessions. Find a way to create requirement components so the meeting length stays reasonable and stakeholders are more likely to attend the entire session.
Offer a Straw Man or Prototype. Do your homework in advance using stakeholder interviews, shadowing, organization documents, etc., to build a starting point for your requirements meeting. Create a prototype, outline a basic business process or system flow, or propose high-level requirements. The starting point will provide a context for dialogue.
Sidebar: Use instant messaging (or texting or email) as a way to communicate with others during the call.
1. You could instant message the host when you have a question.
2. The host could ask participants to vote on a question via text.
3. The host could ask participants to send new issues to the group via email.
Share documents. Many requirement conference calls feature a group of people moving page-by-page through a large project document that was emailed to attendees. Everyone sees a copy during the meeting, but usually only one person edits. Efficient virtual facilitators take document sharing to the next level by allowing participants to annotate documents collaboratively during a conference call.
Modify techniques. Most, maybe ALL, facilitation techniques used in-person can be modified to fit a virtual environment. Explore your organization’s suite of conference call tools. Do you already have access to virtual whiteboards and sticky notes? Experiment with these tools. Get creative and find a way to “virtualize” your favorite facilitation techniques.
Use templates. Create templates for gathering information from your conference call stakeholders before or during the call.
1. During that awkward time when you are waiting for people to join the call, let them add information to a status report or update an issue log.
2. Ask them to update an agenda template with discussion items or questions.
3. Ask them to add requirements to templates broken down by functional areas.
Use new virtual collaboration tools: There are all sorts of online virtual tools that can be used in combination with traditional conference call applications to engage participants. These tools are great for brainstorming and problem solving; they are amazing for truly engaging participants in a meaningful way.

Advantages of Virtual Communication?

Is there any upside to virtual requirement meetings? Can they be more effective than face-to-face sessions? Yes! Especially when attendees participate in a non-verbal way, by annotating documents, filling out templates, or using virtual whiteboards. Here are a few of the virtual advantages:

Anonymity: Contributions to virtual whiteboards and templates can be completely anonymous. Participants can be honest without fear of backlash. Shy participants can “speak up” without feeling judged.
Equal Input: Introverts and extroverts stand on equal footing when they are asked to annotate a document or update a template with text tools rather than verbally.
Difficult Personalities: Personalities are neutralized when using effective facilitation techniques in person or virtually, helping ensure difficult personalities and power dynamics do not sabotage your meeting.
Efficiency: A well-crafted meeting and use of virtual tools and techniques can help facilitators gather a large amount of information in minutes. Well-crafted meetings remove the virtual bottleneck of one speaker at a time and allow all attendees to submit information to the template simultaneously.

Virtual communication and facilitation skills will remain a key competency for BAs for years to come. Stop torturing your stakeholders with boring, ineffective conference calls. Find new and creative ways to alleviate the common pain points. Please share your virtual facilitation tips in the comments below!

Don’t forget to leave your comments below.

The BA Role: Has it really changed in the last 15 years?

Written by Angela Wick on November 17, 2014. Posted in Articles.

As I tweet my latest BA adventures, I ask Siri to find the best restaurants near my hotel, Skype with friends in Mexico, and order my favorite bottles of Napa Valley wine on Amazon, I can’t help but be amazed by how much technology has saturated my life in the last 15 years.

Internet, email, mobile devices, “the cloud” and social media have transformed the personal and professional lives of a huge portion of our world’s population in such a short amount of time.

Visionaries like Bill Gates, Steve Jobs, Jeff Bezos, etc. get most of the media credit for the technology explosion, but instead of focusing on their undoubtedly awesome leadership, I often find myself thinking about project teams. I think about the thousands of programmers, project managers, architects, testers, and of course business analysts—that move the vision to reality.

Given this technology explosion, one would expect that the tools, processes and procedures used to deliver technology have evolved dramatically in the past 15 years as well.

What do you think? Has project life changed in the last 15 years? A lot, a little or not at all? When focusing on the BA role, have the primary functions of the BA evolved? Have BA tools and techniques changed? Have the deliverables changed?

Have the mindset and behaviors changed?

Here are a few thoughts about how project life has changed and how those changes impact the BA role:

Higher Stakes

Whether a project delivers solutions to internal or external customers, the stakes are higher in 2014 than they were in the 1990s. In the past, system and process errors often had manual back-up procedures. The people around then still remembered what the business rules and logic are.

Now, we are so dependent on technology, that, in many cases, business shuts down when the system does not work— orders don’t process, inventory does not move, money doesn’t flow, customers/employees jump ship.

These high stakes impact the BA role in the following ways:

Accurate requirements become even more important than in the past as customers and operations are impacted more when requirements are missed.
Contingency plans for key functions become critical to protect employee/customer relationships.
BAs become risk managers and need to effectively communicate risks, dependencies, and constraints so that projects do not move forward with bugs, gaps or inefficiencies that will compromise the value of the solution being implemented.
The partnership between BAs and QA (test teams) needs to be stronger. BAs need to help QA prioritize test cases and provide context and expected results for key test cases.
The partnership between PM and BA needs to be stronger than ever, both managing key aspects of value, risk, and complexity impacting how both roles work with stakeholders and manage scope and priorities.
A competitive environment in most industries that changes quicker than most project can keep up. This means high stakes if teams cannot flex to the changes, BAs need to be able to adapt and work with changing requirements to ensure the most value is delivered.

Increased Complexity

Fifteen years ago, most BAs were probably working on in-house software/process projects that involved 2-3 systems and a multitude of manual paper procedures, supporting a single business unit or product. The entire project team probably shared space on one floor (or even one large room) and many of the stakeholders were just a few floors away. BAs often grew to understand systems and processes so well, they did not need extensive assistance from subject matter experts.

Business and project complexity grows as companies expand and merge, and it’s happening more often and faster than before. In many cases, dozens of systems interact, integrations and interfaces are critical and complex, users expect more form systems, and BAs gather information from people across the country and even across the globe.

Increased complexity pushes BAs to:

Strengthen their elicitation techniques to account for the immense amount of information complexity, and cross-functional connections; amounts no single person can possibly keep up with as their own knowledge base.
Transform elicitation skills and techniques to discover requirements that are unknown when the project starts. Helping the team discover requirements they did not know they had, but add immense value to the changing landscape.
Strengthen analysis techniques to make the critical connections between functions, processes, rules, data and user experience end to end.
Increase the use of collaboration techniques. In the past, solutions may have been more obvious. Now defining solutions for complex systems requires meaningful collaboration from a diverse group of stakeholders who are rarely in the same city.
Strengthen their facilitation techniques to help stakeholders focus, prioritize, and discover requirements as we learn together.

More vendor package software

Packaged software purchases from third-party vendors also add complexity to projects. Organizations assume packaged software solutions offer reduced costs and efficient implementation and are surprised when project delivery is not seamless.

As organizations expand their use of packaged software, BAs must:

Define vendor roles and responsibilities, especially understanding the role the vendor BA and client BA. The vendor BA’s role is to be a functional expert of the vendor application, functions and options. The client BA needs to be the voice of what the user and process goals and business rules are to meet the solution objectives.
Quickly build strong and trusting relationships with vendors, yet keeping vendors accountable for bringing options and alternatives to realize requirements.
Understand and evaluate vendor requirements strategies, and options to meet requirements. Escalate any related issues that would impact solution value.
Quickly map current systems/processes to packaged software process/functions. Understand and communicate gaps and changes to stakeholders. Prototype, pilot and test quickly to understand requirements and designs fully.
Understand when to leverage vendor knowledge and when to leverage business knowledge to ensure value from the package.

Less time to do requirements

Time and cost have always been focus of solution delivery. Organizations apply strong pressure on their project teams to deliver solutions faster. Our stakeholders have less time too, which means we need to alter our practices to work more efficiently.

In recent years, this pressure has resulted in tighter timelines for business analysis and requirements. With increased complexity and shorter timelines in 2014, BAs need to:

Reevaluate BA practices and techniques to maximize efficiency.
Reevaluate how we use meeting time, collaborate more, and in smaller groups to get work done.
Reevaluate how we document requirements; watch our level of detail for each audience; document in pieces and context rather than big requirements documents.
More alignment to other projects needed to integrate value across solutions.
Understand and communicate solution priorities and risks; base the requirements and testing plans accordingly.
Ask for more time if needed with a solid plan in place to provide value to the stakeholders, and identified risks in business terms if time is not allocated.

Agile Approach

In the 1990s, most BAs worked in a traditional waterfall environment where templates were the norm and the software development life cycle was clearly defined with a regimented organization-wide or application release schedule.

Many organizations continue to operate in this fashion, but more organizations are trending to using an Agile or hybrid approach to deliver solutions.

The role of the BA in projects using an Agile or hybrid approach can be a bit ambiguous, but in general this Agile or hybrid approach compliments a movement toward more collaboration and flexibility in solution delivery, and less focus on SDLC process.

BAs working on projects using an Agile or hybrid approach need to:

Utilize techniques that inspire collaboration and meaningful dialogue to generate effective and innovative solutions.
Understand their role and how it adds value to the solution delivery.
Understand timing and deliverables may change, but mindset and what we do as a BA does not.
Advocate for the value they add to the project.
Let go of role definition based on governance processes and focus on the essence, value, and goal of what you do as a BA.

How has your BA role changed over the years? Are you still generating 100+ page BRDs?

Don’t forget to leave your comments below.