Skip to main content

When is the BA’s Work Finally Finished?

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.

Copyright © Global Knowledge Training LLC. All rights reserved.


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.

First Critical Issue – NOT!

The first great challenge I listed last month was:

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

Why might we want this?  Would it really make things better for project outcomes?  Would it help our professional success?  Watch me contradict myself!

Let’s brainstorm a little.  Don’t accountants “ruin projects” in their own way?  Sure they do.  How about:

  • Enron’s creative accounting, with the knowledge of the CFO (Fastow)
  • The failure of Baring’s investment bank, due to a one month long, 29 billion dollar speculative binge by a single young trader (responsible accountant’s name unknown).
  • Which accountants were overseeing the enormous investments being made in sub-prime mortgages?

What these all have in common is that certain members of each firm, who happened NOT to be accountants (except for Fastow, who clearly was in a position to know better), used their power to bypass accounting standards, intimidate and manipulate the accountants (aren’t you on our team?), and to invent new, unsustainable pyramid schemes, commonly known as no-brainer market opportunities (this stuff is only illegal for small operators like you or me).

This is similar to what happens in some projects: A PM, or executive sponsor uses their power to bypass the business investigation, analysis and due diligence performed by some BA.  The outcomes vary from unnecessary extra costs to complete project failure, sometimes even in the billions of dollars.

The difference is that the responsible accountants in the financial projects tend to go to jail.

Hmmm, maybe we don’t want this – can you imagine yielding to some PM’s pressure to stretch the rules, and ending up in jail when things go wrong?  You think maybe we wouldn’t like this? 

THEN WHY DO WE DO IT TO ACCOUNTANTS?  What is different?

The answer to this question tells us how to change challenge #1.

Mere certification cannot resolve these issues, AND 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!

20-20 Vision

I have always been intrigued by the organizational structure based on two reporting hierarchies, in which each employee has an “HR” manager and a “business” manager.  While I do not claim to understand all of the implications of such an arrangement, I did work very closely with a client using that structure, and a couple of dynamics were very clear:

  1. The business managers are able to really focus on vision, strategy, and execution
  2. Employees in general had a keen sense of ownership of their own careers and roles in the organization, supported enthusiastically by their HR managers

No doubt you have heard (and even harrumphed yourself in a fit of frustration) the adage “If you want something done right, you have to do it yourself”.  Though this is taken as a comment on quality (“done right”), I think it is more a comment on fulfillment of vision.  This is why the BA and his or her elicitation, analysis and documentation skills are so valuable – they are about extracting, reconciling, and revealing the stakeholders’ vision.

It is the dual-hierarchy management model I observed that prompted me to wonder: Is it not the case, axiomatically, that the business manager (the role, not the person) really is the business analyst?  Well, maybe that’s putting it too strongly.  But what if, by design, business managers were also business analysts?  It is common practice for the business manager, who is accountable for business results, to envision the to-be state and then delegate the business case development to a BA.  Imagine the efficiency to be gained if the business manager was also the BA – and what that means in terms of the potential for fulfillment of vision?

It seems the dual-hierarchy organization implicitly embraces the value and importance of the Business Analyst.  I wonder too whether there are other organizational idioms that give the BA role the space it needs.

Have you had experience with the dual-hierarchy management approach, or for that matter with other organizational design elements that are explicitly favorable to the practice of BA?

More BA Basics and BA/PM Debate

fireworks_july2.pngAs you read this, you may well be gearing up for the July 4 Independence Day holiday or, if you’re in Canada, winding down after the July 1 Canada Day holiday. Whatever the celebration, I hope a good time was or will be had by all.

In this Business Analyst Times, Bob Wysocki and Glenn Brûlé continue with their respective ongoing series. This time, Bob takes A First Look under the Hood of the BA/PM Position Family. In his last article, he took a general look at the BA/PM “landscape.” In this issue, he defines the six positions he sees in a BA/PM family, looks at the skills required and discusses professional development for the BA/PM position. Glenn continues his Back to Basics series (should that be BAck to BAsics?) with Getting Back to Basics: Fourth Fundamental – Choosing Elicitation Techniques. In this article, he examines the complications, stumbling blocks and other problems inherent to elicitation. But he also offers very constructive tips and help to overcome obstacles in the process.

In Agile Oxymorons, regular blogger, Terry Longo, asks some probing questions about why the BABOK doesn’t have a more prominent role in the lives of BAs and wonders if terminology needs to be clarified. Hiring a BA? Looking for a BA Position? If you’re in either camp, What are Gen X and Y BAs are Looking for in Their Careers? should provide some practical information.

I hope you find some interesting reading in this issue and that we hear from you with your suggestions for future issues.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

Agile Oxymorons

In my previous entry, I argued that the business case needs to be central to the BA’s view of the world, with requirements management being the most demanding in terms of level of effort.

In June I attended and presented at all three BA World Symposium events (Seattle, Denver, and Minneapolis), and I took away a couple of anecdotes that I’d like to share:

  1. Polling my presentation audiences revealed that maybe 10-15% attendees had downloaded the BABOK v2 Draft.
  2. I listened to a discussion about “Agile Analysis based on Web 2.0” – suggesting to me that BAs sometimes work too directly in the solution space rather than the problem/need space….

What does it mean?  Shouldn’t the BABOK have a more prominent role in the lives of those who are calling themselves BAs?  Don’t we, as a community, need to be more diligent about the importance of distinguishing problem space language from solution space language?  Have you downloaded and read BABOK v2?  Are you practicing “agile business analysis”, and if so, to what extent do your agile BA practices depend on specific technologies?

Inquiring minds want to know!  Please take a minute to share your thoughts/comments.  Thank you!