Skip to main content

Tag: Assessment

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.

An Examination of BA and PM Skills Profiles

In the previous article I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the “BA/PM” for lack of an appropriate position title. Requirements gathering and management was the thread in that article that inextricably links the BA and the PM in the Agile Project World.

In this article I want to look under the hood of this new professional that I am calling a BA/PM. Using the PMI PMBOK and the IIBA BABOK I will list the skill and knowledge profiles of the BA and the PM. A comparison of those two profiles will show remarkable similarity between the two. This should come as no surprise to anyone and will further support the creation of the BA/PM professional, at least in the agile project space if not the entire project space.

My hope is that I will have captured your interest and attention enough for you to share your thoughts and ideas whether you agree with me or not. I welcome opposing positions and the opportunity to engage in public discussions.

BA and PM Skills and Competencies

The following table presents a high-level comparison of the skills and knowledge of the BA and the PM as derived from the BABOK and the PMBOK.

skillschart.png

Is it any surprise that the two lists are nearly similar? From the perspective of the BA all of their work is done as part of a project and so they must have all the skills of a PM to match the complexity of the projects they manage. From the perspective of the PM, not all of their projects will have a BA component but they must have at least a working knowledge of the BA skills.

Assessing Proficiency Levels

Once a BA/PM position family is in place, the BABOK and PMBOK columns will be replaced with the position family,  and the column check marks will be replaced by the minimum proficiency levels as defined by Bloom’s Taxonomy, which is shown below:

Level 0:          I never heard of it.

Level 1:          I can define it.
1           Familiar with the terminology
2          Understands the basic concepts

Level 2:          I understand what it can do.
1                    Knows how it is used
2                    Can explain key issues and benefits
3                    Understands organizational relevance

Level 3:          I have limited hands-on experience.
4                    Has a working knowledge of basic features and functions
5                    Aware of relevant standards, policies and practices
6                    Requires assistance and supervision
7                    Can apply it in a limited (homogeneous) environment

Level 4:          I have extensive hands-on experience.
8                    Knowledge of operational issues and considerations
9                    Understanding of benefits and drawbacks
10                Working knowledge of relationships and integration
11                In-depth knowledge of major features, functions and facilities
12                Awareness of usage in other environments
13                Can work without assistance or supervision

Level 5:          I can adapt it to a variety of situations.
14                Theoretical background and understanding
15                Expertise in all major features, functions and facilities
16                Experience in multiple environments (heterogeneous)
17                Knowledge of and contribution to “best practices”
18                Ability to consult and coach others

Level 6:          I am recognized as an expert by my peers.
19                Extensive experience in multiple/complex environments
20                Industry and marketplace perspective
21                Historical and future perspective
22                Influencing wide or high-impact decisions and initiatives
23                Leadership on architecture, policies, strategy and “best practices” 

In order to be proficient at say, level 4, there must be visible evidence that the 10th through 15th behavioral characteristics are present in the person’s work habits. Neither the BABOK nor the PMBOK offer enough detail to assign a minimum proficiency level to each skill. Until there is a standard BA/PM position family, the need for a skill is just noted without a proficiency level assigned. In constructing this table, I started with the PM skills profile I developed, beginning with PMBOK and factoring in client contact for the past 20 years, and supplemented it with added skills and knowledge as noted in BABOK.

Professional Development of the BA/PM

With the need for the BA/PM professional firmly established let’s take a quick look at the BA/PM professional development program. The first piece of this puzzle is to define the BA/PM position family. Neither BABOK nor PMBOK has anything to contribute to defining the BA or PM position family. Here is my first take on that definition.

  • BA/PM Team Member
  • BA/PM Task Manager
  • BA/PM Associate Manager
  • BA/PM Senior Manager
  • BA/PM Program Manager
  • BA/PM Director

I intend to define these more precisely in a subsequent article and to suggest a professional development program structure for consideration.

Putting It All Together

I would certainly like to hear your thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.


Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

Personal Identification: The Soft Skills PRECEDE the Hard Skills, for BAs

Doggone and dadblast it, what is going on! Didn’t I just say the opposite last month? How is your tolerance for ambiguity holding up? Are you on top of the BABOK 1.6 BA Fundamentals? If you are aspiring to the top of your profession, and have the courage to self-identify, dive right in!

I begin by quoting the entirety of BABOK Chapter 8 here (don’t panic, it fits in the blog):

Chapter 8: Underlying Fundamentals
8.1 Introduction

8.2 Basic Skills
8.2.1 Analysis Skills

.1 Structured Analysis Techniques
.2 Issue Management
.3 Communication Skills
.4 Learning Skills
.5 Usability

8.2.2 Business/Domain Knowledge
.1 Products
.2 Processes
.3 Markets
.4 Systems
.5 Sources of Knowledge

8.2.3 IT Knowledge
.1 Paradigms
.2 Methodologies

8.3 Advanced Skills
8.3.1 Meeting Management
8.3.2 Presentation Skills
8.3.3 Decision-making Skills
8.3.4 Facilitation Skills
8.3.5 Communication Skills
8.3.6 Conflict Resolution
8.3.7 Negotiation Skills
8.3.8 Relationship Skills
8.3.9 Questioning Skills
8.3.10 Systems Thinking
8.3.11 Escalation Skills
8.3.12 Logic
8.3.13 Cultural Awareness

8.4 Leadership Skills
8.4.1 Coaching Skills
8.4.2 Facilitating Long-term Goal Setting
8.4.3 Motivational skills
8.4.4 Appraisal Skills
8.4.5 Interviewing Skills
8.4.6 Role Definition
8.4.7 Behavioral Coaching
8.4.8 Delegation skills
8.4.9 Succession Planning
8.4.10 IT Architectural Skills

8.5 Peripheral Skills
8.5.1 Sales

8.6 References

Interestingly enough, it is only the Basic Skills that have any detail at all, and those not much. What does this mean? The Basic Skills are the things that we learn just by doing IT requirements work. So many BAs cut their teeth on IT, that this is “self-evident” to many of us. The KEY skill is that we LEARN.

Self-test number 1:
Did you love school, or at least did you love reading and learning? Can you see the relationship between a three-year IT project and a three-year PhD program? WHY is it important to involve stakeholders (bet you don’t know)?

Next are the Advanced Skills. These are the sorts of things that BAs learn when (typically) we have been in a job long enough to have institutional knowledge and process experience, plus enough maturity to get along. In effect we get “promoted” to working with more people. We may not be good at it at first, but we’re here because we know so much and can share it. This thrusts us beyond analysis of processes affecting teams, into the processes of team analysis. We can lead the team to meetings, but can we make them think?

Self-test number 2:
How balanced were your SAT scores? Are you as comfortable with words as you are with complex IT and financial concepts? Would you rather listen, except when it is vital to talk?

Then comes Leadership Skills. This is Advanced Skills on steroids, in the sense that NOW you can really make it work, not just oversee uninspired meetings and team sessions.

Self-test number 3:
Do people just fall all over themselves to be with you and get your approval and do what you say because you are just plain charismatic and, frankly, too sexy for your project? If not, have you held at least one sales job for more than two years? If not, try it and find out if you want to lead.

Yes, this is the punchline. Leadership IS influence, regardless of style, or outcome. Sales IS the profession of learning to influence, for good or for evil (both kinds of leaders are out there – which will YOU be?).

SO, as you look for “people skills”, don’t forget that a successful sale means a happy customer, whether the customer is a stakeholder, an executive, a system user, a boss, or an IT team member.

Happy customers are getting what they want – good systems; no one loves a salesman who sells a lemon. If you have happy customers, you are on your way to the top of the profession.

Here is the problem we have posed: BUT, loyal reader, I am out of time this month.

© 2008 Marcos Ferrer

Never Let a Good Editor Go

When documenting systems, quality assurance requires quality support people, especially final content editors. They are worth their weight in gold-edged certificates. If you are part of a large project that has a very large documentation aspect, learn to nurture, develop, and retain a good editorial staff, and do not forget to keep everyone’s skills current on the tools you are using! The current crop of word processor and presentation software packages are constantly adding features to make your life easier.

In our ever more technical world, documentation is still one of the most important aspects. Everyone likes to “feel the weight” of what they accomplished, and documentation is commonly a major part of closure in a project.

The Second Eye
If you have ever had to write a program or a document that was 2000 pages or longer, you will probably get to the point of forgetting what you wrote days, weeks, or months ago. I know I do. That is where a good editor can save the day. Make it a habit of passing along the content in reasonably sized pieces to another soul who dutifully reads every line, checks every drawing for accuracy, and checks syntax and examples. This is a truly wonderful thing.

 A second set of eyes will see things that you cannot. Spelling, grammar, syntax, run on sentences, redundancy, too much or too little detail, irrelevant details, your own quirky tidbits that might not be as clear to them as to you, the list is endless … and the work is absolutely crucial!

Praise Your Editor
Thank them for finding those errors that you were unable to see after looking at the same page for hours. Most modern word processors can handle spelling errors but not if they are technical jargon or corporate jargon.

I like to break my content into smaller, specific pieces if possible, but this does depend on the client requirements. If the programs are small, then the sections can be small and succinct. In some cases, the sections require previous sections to be completed and functioning. Only someone who was totally familiar with the whole picture, the end product, and the inter-relationships of the pieces can provide you with a good set of eyes to review your content with.

Send them praises: Excellent work finding “the the”, “good idea to add that as well”, “you are once again correct, that part is unnecessary”. “good eye, I forgot that topic entirely”…

Editing is an Art
Being an editor requires a great depth and breadth of knowledge on the subject. I would not pass this document on to my teenage daughter; it would be gibberish. She once asked me to “fix” her paragraphs about the Crusades. I expounded on them and thought I was keeping it simple. Alas, I was way too technical. I added about 10 extra words for every two of hers. Then there are many times when I edit her words to be, shall we say, more accurate.

On some recent technical documents, I was doing the developing and passing it on to three evil editors. The first two were masochistic, butchering the youngling without regard for effect, it seemed. They passed it to the third editor, a very technical person, who must have thought I was completely incompetent when he got the butchered remains of my work. It was an interesting few months of trying to figure out their system. And, interestingly enough, that last technical editor was actually very competent. He never missed a detail, was very thorough and fortunately knew his stuff. The other two butchers were trying to fit the content into a web page design rather than have the web page provide the content.

Editing Adds Time
It is highly likely that your editor is not doing this full time for you. Hence, you need to allow for their scheduling requirements within your schedule. Having lots of lag time is always nice. Giving them clearly stated times and dates for delivery of their edits are other important aspects. Everything takes time, and time gets consumed faster the closer the project deadline is.

When I line up an editor, I make it clear there is some flexibility in their timelines at the beginning especially and I try to ensure that deadlines do not force me, or them, to cut corners. Deadlines really are annoying at times! I also make it very clear what the deadlines are and how they can help me meet them, along with general ideas of what I want them to look for, and how they should send change requests or make adjustments.

Give Them Source or Don’t Give Them Source?
This can be a tricky issue. Should you give your editor the source and let them make changes directly to the document? Yes and no.

If you can have tracking of changes, this is always an excellent idea. What if they change your source document without tracking the changes? If you are working with a competent editor to whom you have given this option and in whose inputs you trust, then this is one way to get it done faster. You should, of course, edit their changes for them!

In some cases, as the editor, you may not get the source code, or as the owner of the document, you may not want to give them the source. In some of my recent projects, I would get a PDF of the document. This was fine for simple grammar and syntax errors but became onerous when major changes were required. I was forced to send in “sticky notes” of changes. This is probably the least efficient method for the editor, but it does maintain total control by the owner of the document. There are probably a lot of good and bad reasons for using this method, I just cannot think of any good ones.

Being an editor is important and can be rewarding. Having a bad system for rendering changes will ruin the relationship. A good project management truism is to retain your best support people, and especially a good editor. They make your project that much easier to complete on time.

Copyright © Global Knowledge Training LLC. All rights reserved.


David Egan, RHCE, PMP,

is an instructor with Global Knowledge Training LLC. This article was originally published in Global Knowledge’s Management in Motion e-newsletter, named Business Brief. 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.