Tag: Requirements

When is the BA’s Work Finally Finished?

Written by Cynthia Low on July 15, 2008. Posted in Articles.

The business analyst’s work is not finished when the requirements document is signed off. Although other experts are responsible for the project activities, the BA remains involved to ensure that decisions made have no adverse impact on the business stakeholders. As the project progresses, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the agreed solution will satisfy the requirements.

After the solution has been built, the BA collaborates with many people on activities such as testing, conversion, cutover, and training. Depending on the roles defined in an organization and the project, the BA may collaborate with the people who are responsible for these activities, or the BA may be the responsible person. In either case, the BA ensures that all of the right things happen.

Monitor Solution Design and Planning

As the technical team derives the solution design, the BA must learn enough about the implications of that design to ensure that it supports the requirements well. For example, the BA might:

Review user classes to ensure that all of the solution functions, uses, and end users have been accounted for.
Review the developers’ functions and feature list for completeness.
Map the documented requirements (both functional and Quality of Service) onto the elements of the system design to ensure complete coverage.

When the technical team defines their phasing plan (which identifies the order in which requirements will be addressed and functionalities designed and built) for incremental development, the BA must ensure that the plan supports the stakeholders’ needs. If the plan calls for features to be delivered in a certain order, the BA should ensure that the planned order and delivery dates will suit the business stakeholders. The BA should also ensure that the phasing plan provides opportunities for any needed prototyping or validation during the project.

Tracing the requirements to the design is a good way to ensure complete coverage, and it lays the foundation for maintaining traceability throughout the project. The traceability information must be captured and recorded as the designs are being done, as trying to derive the traceability after the fact is difficult, if not impossible.

Finally, as the solution is being designed and built, the BA may identify business process improvements that are unrelated to the solution that is being built that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Approved Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to be sure that those deliverables satisfy the requirements and can be used by the intended end users.

System testing looks at the final system to determine if the requirements have been satisfied.
System integration testing refers to testing the final solution to ensure that it can coexist and integrate with existing systems and databases. Many organizations have an independent testing group whose main responsibility is to prepare for and perform these tests. When that is the case, the BA will usually review the test plans and the test results, and at times, the BA may help with the testing. However, in organizations that don’t have testing groups the entire responsibility falls to the BA.
Operations testing involves testing the solution to ensure that it can be installed and run without an adverse effect on the other existing systems. If the computer operations group takes responsibility for this testing, then the BA will usually review the test plans and the test results. But if this testing is necessary and no one takes responsibility for it, then the entire responsibility for this testing falls to the BA.
Acceptance testing ensures that the business need and user’s needs have been fully satisfied. If the customer takes responsibility for this testing, then the BA will usually review the test plans and the test results. Otherwise, the entire responsibility for this testing falls to the BA.

Assess Other Solution Options

The BA should collaborate with a variety of people on the project as the solution is being put together. In all cases, expect the experts in each area to be making good choices. The BA’s role in the collaboration is merely to serve as the business stakeholders’ advocate and assure that their needs will ultimately be met.

Although the technical team takes the lead in evaluating and deciding on the technologies that could be employed to build the solution, the BA should remain involved. This is because every technical choice has the potential to cause limitations in the solution that will be noticeable to the users. So, the BA must learn enough about the effects of the team’s technical choices to ensure that they actually do support satisfying the requirements, and ultimately, the business needs.

When the plan involves purchasing or leasing (as opposed to developing internally) a solution, the BA may take the lead in choosing the solution. But even if someone else has primary responsibility for this, the BA will still remain closely involved. The BA ensures that any RFP (request for proposal) or RFQ (request for quote) accurately translates the requirements. The BA should also verify that the proposals received will fully meet the business need. And, when the solution is finally received, the BA ensures that it is adequately tested to be sure that is actually satisfies the requirements.

Support Implementation of the Solution

In some organizations, an operations team takes the lead in implementation, but often the BA is responsible. In either case, the BA must remain involved to ensure that implementation and any necessary conversion meets the needs of the users.

The BA ensures that any necessary installation planning is done, and that the appropriate technical experts review that plan for correctness. This could be as simple as ensuring there is enough disk space for the new software, or as complex as replacing entire computer systems with new ones.

Conversion is almost always an issue. Since the solution is most likely changing some attribute of the business process, there will probably be data conversion; there may also be other kinds of conversions to be done. Planning for these includes identifying the rules for handling the inevitable problems that will be found.

Finally, the plan to the final cutover to the solution must be well thought out. When should it happen? Will there be downtime involved? If so, how much is acceptable? An important, but often overlooked item is the “backout” plan. If the cutover fails, what must be done so the business can resume working with the old system? If there is significant data conversion or other changes, this can be a difficult problem.

Communicate the Solution Impacts

The responsibility for communicating the impact of the solution is assigned to different people in different organizations. In any case, the BA must still remain involved. Before the new solution is implemented, the BA should work with the business stakeholders to ensure that they are ready for it by:

Ensuring that everyone who needs to know about the implementation has the information they need, when they need it, before implementation
Setting the expectations of users and other stakeholders about how the change will affect them and the business process
Making sure that any needed training and help is available to the users in a timely manner

After the implementation is complete, the BA collaborates with the appropriate people to report on the implementation. This reporting provides pertinent information to all the parties who need to know that the implementation took place, and if there were problems. A key item is the business impact that the change had. Since the project was undertaken to improve a business process, the actual impact on the business process is of major concern.

Perform Post-Implementation Review and Assessment

The final validation occurs after rollout of the solution is complete. This activity, also known as “Lessons Learned,” is designed to help the organization learn from each project, supporting continuous process improvement.

You need to capture these successes, identify why they happened on this project, and determine what can be done on future projects to make them routine. The parts of this project that worked particularly well represent opportunities for future projects.

By the same token, if there were things in this project that were problematic, they also represent opportunities for improvement. You need to capture these issues, identify why they happened on this project, and determine what can be done on future projects to avoid them.

The Lessons Learned review is one of the most potent mechanisms for organizational learning and continuous improvement, as long as you actually use what you learned in future projects.

In Summary

Solution assessment includes all the activities that the BA collaborates in to ensure that the technical and other decisions being made by the development team result in meeting the needs of the business and users. These activities include design decisions, phasing for incremental development, maintaining the traceability matrix, choosing technologies, procuring solutions, and ensuring usability.

Jill Liles has been the Marketing Manager for Global Knowledge’s Business Analysis training courses for two years. Her background is in continuing education and non-profit marketing, and she graduated Summa Cum Laude from Peace College in Raleigh, NC.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.

Getting Back to Basics: Fourth Fundamental – Choosing Elicitation Techniques

Written by Cynthia Low on July 2, 2008. Posted in Articles.

Since April, I’ve been writing a series of articles for this website about the basic competencies of business analysis. I’ve been doing this for a couple of reasons. First, I enjoy staring at my computer for hours on end and thinking about grammar. Secondly, and more importantly, the enormous influx of available information over the last several years has caused many business analysts to lose track of the core, basic principles of this vital discipline.

So far, I’ve written three articles, which have covered understanding your organization’s overall goals, creating a common vocabulary among your team and identifying the sources from which you’ll extract requirements. For my fourth article, I’ll be covering elicitation techniques.

A Pre-Elicitation Meeting
In articles like this, writers often make things seem easier than they actually are. Therefore, let me caution that there are a number of complications inherent to elicitation. For starters, your customers and stakeholders, with all due respect, likely won’t understand the process that you’re taking them through. Furthermore, because each stakeholder is most interested in his or her individual needs, that individual will be less conscious of the many interdependencies that exist between requirements. To combat this, it’s a good idea to look back at the stakeholder categories you’ve developed (see the third article in this series), sit down with the groups-either virtually or in real life-and walk them through your goals and expectations regarding elicitation. This is an excellent time to establish individual roles and to let them know that you’ll be coming back to them soon, when it’s time to talk validation.

Four Elicitation Opportunities
I recently saw an infomercial for a machine that sorts change. Simply dump your bucket of mixed-up coins in and it organizes them all into neat, coherent little piles. I immediately thought of business analysis-particularly requirements elicitation.

Say a client comes to you and says, “Let’s build a rocket!” Immediately after determining that this client is sane, you’d find yourself with a big bucket of mixed-up questions and ideas. What color will the rocket be? Where is a good place to buy rocket fuel? How far into space should the rocket go? Do rocket scientists get paid by the hour? As a business analyst, it’s your job to use the practices we’ve already discussed and requirements elicitation to sort all of those random questions and ideas into neat little piles of requirements that can be used to meet your ultimate goal. Here are four opportunities for elicitation and a look at some of the techniques to consider for each:

1. Enterprise Analysis
Enterprise analysis can help you develop a vision for your potential product or solution. Staying with our rocket-building theme, it’s where you’ll begin to get a sense of what your rocket is going to need to be able to do. Two useful techniques at this stage are brainstorming and surveys. When dealing with a group of experts, brainstorming sessions are effective because the group will have an inherent understanding of logistics and the reality of the situation. Conversely, if you’re dealing with a group of, say, non-rocket scientists, consider conducting surveys. This will help to limit tangents and hone ideas based on the questions you choose to include.

2. Requirements Definition
When defining your requirements, consider joint application design (JAD) sessions. Like brainstorming sessions, JADs work best when dealing with a group of stakeholders who have a high level of subject matter expertise. However, unlike brainstorming sessions, they may run for days at a time and follow very specific agendas. A detailed agenda lets you ensure that all uncertainties are unearthed and that no miscommunications occur.

3. Requirements Analysis and Documentation
Here, as you begin to go deeper into determining the needs and conditions required to build your rocket, analysis becomes vital-as in gap analysis, root-cause analysis and force-field analysis. Gap analysis enables you to identify the “gap” between where you are and where you want to be. Root-cause analysis, which is perfect for the neurotic among us, considers all of our problems and identifies the “root causes” of those problems. And, force-field analysis, which derives from the social sciences, identifies the “forces” that influence progress toward a goal-both positive and negative.

4. Solution Assessment and Validation
With your solution and its requirements in sight, it’s essential to circle back to your stakeholders for validation. As obvious as this may sound, startlingly often, business analysts fail to ensure the validity of the requirements that they’ve elicited. Multi-voting and prototyping will help you build consensus and demonstrate how your solution will materialize, going forward. Criteria-based grids and impact/effort grids are effective, too, as they weigh requirements against formal criteria and rank them in terms of importance and feasibility.

Next Time – Choosing the Best Modeling Technique
Tune in next month for article number five of five. In this, the exciting series finale, we’ll bring all of the back-to-basics practices together and close out with a discussion of modeling techniques.

Glenn R. Brûlé, Director of Client Solutions at ESI, has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn was formerly a Director at Large for the International Institute of Business Analysis (IIBA) where he was responsible for forming local chapters of the IIBA around the world.

Group Dynamics and Requirements Elicitation

Written by Richard Lannon on June 16, 2008. Posted in Articles.

As an information technology professional, developing your business acumen is important. One of the skills you need is the ability to facilitate. In your case, it is all about “facilitation for elicitation of requirements” to solve business problems. In working with groups, there are a number of dynamics that the facilitator needs to be aware of. It is helpful if you consider the different group characters and how to deal with them.

The Isolator
This is that one person who remains outside the group or is thinking about previous topics. Consider spending time helping people get acquainted or have discussions using pairing and triads. Provide opportunities for debriefing or summarizing what was discussed. Get the participants involved.

The Monopolizer
We all know this person. They monopolize the time and focus of the group. Be clear on your expectations, use your body language to hurry the speaker or, when they take a breath, say “thank you” and ask for other comments. You can also use a parking lot to write their points down. It is best not to interrupt. However, it is OK to watch for the talkers to draw a breath, and then attempt to regain control by leaping into the instant of silence this creates. Move fast, but speak softly and gently.

The Facilitator as Expert
As the facilitator, you should never set yourself up as the expert. You are there to understand the requirements and help establish direction. Consider avoiding answering every question yourself by letting group members respond to each other. Do not feel obliged to comment on everything that everyone says. Reduce your own authority by sitting down with the group.

Group Sharply Divided
This is where the groups are together physically but not together in interests or point of view. Mix the group up and get people to move around the room. Put them in new requirement work teams and assign the groups a specific relevant task to complete. Have team members present and then debrief. If a solution cannot be reached, get agreement to park it! Make sure you ask the group if they feel comfortable moving on even though the issue dividing them is not settled. Be prepared with several group exercises, tools and techniques. Most important; keep cool, detached, and unhurried. Use a light touch.

Antagonistic Duo
These are the two people exchanging negative vibes and making everyone uncomfortable. Confirm that the conflict is positive and ask them to continue their disagreement. Set the stage by moving them closer together, arrange other group members as observers, and establish a scribe. Most importantly make explicit ground rules for conflict. Ask group members for feedback. Get everyone involved by taking the issue away from the duo by saying, “You have highlighted an important issue for us.” Here is an exercise for the entire group to participate in that continues exploring these issues, but in a different way.

The Cozy Duo
Here two friends are choosing to give each other comfort. They are making side conversations. This is not alright. The best solution is change the teams and rearrange the seating locations at a break to split the cozy duo up. Position the change as an opportunity to get a different perspective.

Unresolved Members
People are not engaged. It happens. Sometimes people do not understand why they are participating; they never wanted to participate; they just do not care or maybe they are bored. Break time! Check the thermostat and drop the heat in the room. Maybe change things around. Consider a group exercise, a short controversial video on the topic, Have the group brainstorm on a new agenda and create consensus. Be brave and leave the room while they do it. The break may help you to refocus and help them to become more active.

Highly Defensive Group
In this case the group members have erected barriers to protect their personal or professional images. This is about self-preservation. You need to get people talking and sharing in a low threat way. Move slowly with no pressure. Focus on facts and intellectual work for a time, gradually introducing small amounts of selective attitude. Avoid role-playing. Be open to revealing more about yourself. Sometimes this sets the stage for other people to reveal information.

The Big Group
If the group has many members and no sense of inter-relatedness, be prepared to use pairs, triads and work groups. Rearrange the group into round tables so they can see one-another. Get people discussing specific related topic. Make sure you walk around the room making contact with people. Establish “associate facilitators” to manage the different groups. The larger the group the more ground rules, definition of roles and leadership required. Avoid feeling and attitude work with large groups. Keep people on track.

The most important thing as a senior professional, business analyst, manager or leader in developing your facilitation skills is to have fun and enjoy the process. Find ways to enhance being a facilitator and applying requirements elicitation best practices. Develop your group dynamic skills along with the tools and techniques of requirements elicitation. Remember to leverage the group’s unique character and get the members engaged.

Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808

The Business Case: Is It the Next Agile?

Written by Terry Longo on June 16, 2008. Posted in Articles.

In earlier blog entries I discussed the notion that not requirements but the business case should be the center of the BA’s existence, and that the business case must somehow account for the costs and risks of the components comprising the intended solution.

The notion of agility is one of the primary tenets for dealing with change. But how can there be so much discussion about Agile Development, Agile PM, and Agile BA without also discussing “Agile Business Case Management”? After all, software development, PM and requirements activities are driven by and exist within the context of the business case. Before continuing, I want to acknowledge absolutely that, from a level-of-effort point of view, the specific activities around requirements management are the most demanding aspect of BA. But as requirements exist within a context of constant change from within (project dynamics) and from the outside (business dynamics), when focusing on the requirements themselves, how do we know when the business case needs to be revised and reconsidered due to those changes?

Anecdotally, in bringing up this question with my audiences at the Seattle and Denver BA Symposiums, there was general acknowledgement that requirements management is currently the main focus of Bas, and that the business case frequently falls by the wayside, once solution development commences.

Is this the case for you? What are your best practices regarding business case management to ensure that it continues to be revisited in light of development, operational, and/or business changes? When your business cases are created, do you specify boundaries (cost, risk benefit, etc.) beyond which their relative value is lost?

Five Critical Issues that will Define the BA Profession in the Next 10 Years

Written by Marcos Ferrer on June 2, 2008. Posted in Articles.

Well, loyal readers, John Dean didn’t set me off with his recent column (insufficiently fascist, entirely too rational), AND I want to think about what he said before deciding to respond. This means we can take our discussion about BA and Identity Systems back to the highest level, before we diving for the next drill down (I know, I promised a drill down, AND this is more fun).

In this case, the highest level issue that comes to mind regarding Identity Systems has to do with “executive sponsorship” for a national consensus on the requirements for such systems.

The ONLY source of executive sponsorship powerful enough for BAs to succeed in Identitying System Requirements are the people themselves, and yet the people (as a whole) rarely rally to a transparent process for the common good, which is exactly what we are proposing. When the people do rally, the effect is immense.

Let’s face it – half the time, a BA can’t even get quality requirements on projects where the stakes are much smaller than for a National Identity System. Commonly accepted “project failure” symptoms, such as Failure of user acceptance, Failure to deliver mission critical function, Missed deadlines, Over budget, Poor requirements documentation, Scope creep, etc. sound like Project Management problems to outsiders and executives.

Most BAs know that these failures are really due to organizational resistance (including stakeholders and IT people) to the BA process. As the famous joke goes:

Q: How hard is it to deliver on time and under budget?

A: It’s easy, how much must I spend by when?

Time and money are very important, but not if the what you are building gets lost in opaque, non-transparent petty politics. The root problems tend to be deeply human ones, revolving around self respect, conflict avoidance, territoriality, work avoidance, organizational tribalism (silos and secrecy), fear of change, lack of trust and much more.

To these deeply human issues, let us not forget simple corruption, which is less emotional and more premeditated, and cringes in the light that BA practice can bring.

This suggests the Five Great Challenges to our profession. These are the issues that will define our profession, and will decide if BA can make a difference. We believe that we can increase project success and reduce the overwhelming waste and failure rate that is currently an accepted part of the world of projects. Will everyone else?

Will the society at large empower BAs to operate at the level of professionalism required of (say) accountants (transparency, completeness, accuracy)?

Given the importance of the what in a project, will PMI agree that BA must precede projects, and BAs must be at least peers with PMPs, instead of answering to their time and budget needs first?
Will the earliest CBAPs actually be a credit to the profession? Will they generate successes, and word of mouth, to help boost the profession, or will they have the same outcomes as everyone else?
Can the society at large understand the BA process well enough to understand why they want to support it?
What, if any, are the rules for public disclosure of private malfeasance? There are such standards for lawyers, doctors, accountants, etc. What will ours be?
What, if any, are the rules for public disclosure of private malfeasance? There are such standards for lawyers, doctors, accountants, etc. What will ours be?

Mere certification cannot resolve these issues, but it is a good start. If you believe, like I do, that BA must rise in our society, please contact me with your ideas. We must lead, or continue to follow, and I for one am tired of being an armchair quarterback.

Thanks for being my reader, if this inspired you at all, please make a comment, so BA Times can know that we care.

Have fun!