Business Analyst Blog

Gap analysis is a well established technique for business analysts working on COTS (Commercial off-the-shelf) package implementations. It is amazing that this simple technique can be helpful with so many analysis challenges. Most gap analysis is done in a matrix or table where the analyst can keep track of the business needs in one column and note the package support for each business need in another column. Consider a few of the common uses:

The most common gap analysis is a comparison of required business data elements to the data elements supplied by the package vendor. This analysis can be as simple as "Does the needed data element exist in the package? Yes or No" or can be very complex including do the characteristics of the data match (e.g. CHAR vs. INTEGER), do the lengths of the data elements match, and do the validation edits match the business needs?

Another useful gap analysis is between terminology. Your business area may call its customer organization COMPANY while the CRM package that you are installing calls them ACCOUNTs. A table cross referencing these terms along with notes about how the package definition differs from your organization's definition is very useful throughout the project and after implementation.

Business processes can be matrixed against package features to make sure that all critical processes are supported. Notes in this matrix can explain how package features will be used or modified to support the busienss activity along with which role in the organization will utilize each feature.

Expand your use of gap analysis for COTS, department mergers, and even internal software development projects. Whenever you have an AS IS and TO BE system, there is a risk of gaps.

Recently I participated in an interesting discussion about software development projects. There was an underlying assumption by some that using a consistent software development life cycle (SDLC) on all projects is a good thing and someone asked how to best enforce it. For me, enforcement is a morale killer. In working with many companies over the years developing software, some had methodologies and used them with great success, others used them but projects still failed. Some organizations, who did not have any standards, wasted a lot of time starting over for every project and still others without too many standards remained nimble and innovative with break-through and cost saving results. Training teams to make confident choices is more essential than dictating a methodology. I have argued with many quality assurance people when my judgment calls were in violation of a methodology step that did not add value to our efforts. Organizations should concentrate on teaching their employees approaches to handle different types of projects and challenges.

With training and project experience one can balance variables such as risk, cost, complexity, and importance of the project to determine which deliverables and efforts are beneficial. Does that mean you have to create a lot of paper documentation? It really depends on the project. Are lives at stake? If not, less formality and rigor is my preference. My mantra: Only work tasks that add value. Beware that most SDLCs are written for complex projects. If your effort is small in scope, has clear requirements, and minor business impact you do not need tons of documentation. Requirements may be confirmed informally. These are important considerations for a business analyst when planning.

I recommend organizations adapt a small number of easy- to-use development life cycles, provide people training and make the lifecycle options visible and available. I appreciate the overall structure, templates and reference that most development lifecycles provide to a project team, especially as a communication tool. Trained teams can benefit and develop efficiencies by having standards that work for different types of projects. Talented, experienced people can be creative and use good judgment to tailor the SDLC to what is important on their projects.

In other words, I know what I like to eat but it is also nice to select from the menu of my favorite restaurant. I can make my choices more easily, request menu adaptations as needed, and get to the fun part faster which is enjoying a good meal. Using software lifecycles for guidance, consistency and flexibility, need not constrain, delay, or negatively impact the project results or the team. They just let us get to our dinner faster and so we can enjoy the meal. I would love to hear your stories about methodology implementations at your organization.

Business analysts are rarely allowed enough time to elicit, analyze, and confirm requirements. Why? One reason may be that we don't ask for it. An important BA skill is the ability to accurately estimate the amount of time required to perform analysis work and be able to explain and justify it to project managers and sponsors. Often they don't know why requirements take so long to "gather" because the word "gather" implies a BA with an Easter basket walking along the grass scooping up brightly colored eggs! It looks so easy!!

The best way to request and receive enough time is to build your case. You must be able to explain to the sponsor what you will be doing during that time and why your work is important. My suggestion is that you develop estimates by breaking tasks down into very small pieces. The smaller the task, the easier and more accurate the estimate. This detail also helps you justify the time. Let me give a small example - if one of my requirements deliverables is a Use Case diagram my task list might be:

Review project initiation documentation and draft UC Diagram   3 hours

Schedule stakeholder meeting (find room, call participants, prepare agenda)   1 hour

Conduct stakeholder meeting (present draft UC, get revisions)  2 hours

Revise UC diagram based on meeting  1 hour

Consult with IT architect to confirm feasibility   1 hour

Schedule review meetings with key stakeholders  2 hours

Conduct review meetings and ask for approval of UC Diagram  4 hours

By listing everything that you will have to do (including setting up meetings, etc) you will get an accurate picture of the time required. Remember these are work times - not lapse time. This is the amount of time that you would need if you were not working on ANYTHING else. Be sure to built in reviews and revisions as they will always be necessary. The less confident you are about the expected outcome of elicitation meetings, the more reviews/revisions cycles you should build it. Once you estimate, keep track of your actual work time so that you can learn and estimate even more accurately in the future. Take a look at our new course: Developing a Business Analysis Work Plan for more information. 

I presented a webinar for Catalyze (www.mycatalyze.org) on February 14th entitled Designing a Sure-Fire Stakeholder Strategy. The presentation touched on the importance of business analysis planning, specifically planning for stakeholder communications. We had 150 attendees and I was not able to answer all of the questions that were submitted. I will answer the remaining questions in upcoming blog posts.

How do I manage a stakeholder that changes his mind and these changes cause large amounts of re-work. Any rules of thumb such as an extra 20% longer?

Great question. When we are planning and thinking about how best to communicate with our stakeholders we need to consider each stakeholder's ability to provide requirements in a timely fashion. This includes considering stakeholders who may tell us one thing one day and something different the next. If you are fortunate enough to have personal experience with your stakeholders than you can plan for their individual idiosyncrasies (this is not a judgemental statement, we all have some percular ways of thinking and communicating!). If you don't personally know a stakeholder, try to find someone who does. Ask questions informally to get a feel for the person's style.

When building your task list and estimates, you should not explicitly say that you need more time with John because he changes his mind frequently, but you might build in more formal reviews and re-reviews with that particular stakeholder because you know this issue will come up. You also should alert the project manager that when dependencies are built into the project plan - beware that dependencies on John may be risky. The PM can also plan better with this knowledge.

We don't always get the dream stakeholders - the people who are always availabile when you need them, always patient when explaining their needs, and always sure about what they want. We have to learn to plan for and work with whoever our stakeholders are and remember than variety is the spice of life. If all stakeholers could clearly articulate their needs, there would be no need for a business analyst!

2008 promises to be a great year for business analysis! We have finally hit our stride - lots of people in our companies are beginning to understand what we do and the value that we bring to the organization. The IIBA has certified over 200 CBAPs in it's first year and is working to make the exam more accessible for everyone.

And there are suddenly many training, consulting, and software companies who now actively advertise their business analysis products. They have all recognized what we have known for years - business analysts are smart, focused, creative, and enthusiastic about helping their business run smoother and be more successful. Maybe we should declare 2008 The Year of the BA!!

Even though development tools and techniques have improved drastically I still hear from corporate application users that the systems their IT department built or purchased for them lack usability.  We all know that projects are still failing or challenged based on the triple constraint (Time, Budget, Scope).  I wonder if the addition of a fourth element, usability, would put more numbers in the failed category. Teams often claim all the features were delivered.  True, but if ease of use is missing was the feature really successfully delivered?   

Would Apple profit as much if they did not incorporate usability requirements and testing in their iPod and iPhone product development?  Let me answer that for you. No! Successful companies around the world conduct focus groups and usability testing to help differentiate their products from their competition.   

At our last IIBA meeting in Atlanta, the speaker, Dave Altman, asked how many people work in an environment where there is a usability lab or any usability activities taking place.  1 person out of 40 raised their hands.  These 40 people represented 10-15 large companies in the Atlanta area.  As IT professionals why are we not focusing more on this important step?  In my opinion money and time is wasted if we implement solutions that lack usability even if the triple constraint is met.   

There is a lot of talk lately on why business and IT are disconnected.  Most of the talk is around aligning strategies which I believe is the first step.  Provide usable solutions and you’ll see that gap shrink even more.

As BAs and UX professionals we need to push for more time and money for usability testing.  It is our job to help provide workable solutions to meet the business need.

Traceability is a necessary component for complete and accurate requirements. Traceability is used in many aspects of requirements development and management. A simple definition is that "tracing requirements" means that we show relationships or links between different requirements components. Examples include:

Which data requirements are used in each process?

Which business objectives are supported by each business rule?

Which technical requirements are derived from each business requirement?

This is one area where a requirements development or management tool can be very useful. But even with a tool, tracing requirements can be complex and time consuming. An effective BA plans for the types of relationships that are going to be documented and maintained before getting started with requirements elicitation. It is easiest to "trace as you go" and the only way to accomplish this is to know ahead of time what type of tracing you are planning to perform and maintain.

I attended a Certified ScrumMaster training class this year delivered by Lithespeed.  The class was very valuable, and I want to share a tool, trade-off matrix, to help set customer and team expectations.  In my opinion this is a tool that should be used on all projects early in the planning stage.  Here is an example of a trade-off matrix.

By documenting this at the beginning of a project, the project sponsor and all project stakeholders (including project team members) have a clear view of what project success looks like.  In the example above success is implementing all features, within a budget close to $500k and somewhere within 3-6 months.  In addition the sponsor is OK with 2 large bugs a month. 

You may find that a project sponsor wants everything “Fixed.” By using this matrix to illustrate the triple constraint it helps drives your discussion explaining why there needs to be a trade-off. 

I plan on using this to help define success.  Please share any tools you use.

Some people cannot understand why data requirements are important. There are a lot of Business Analysts who say they have never collected data requirements and do not understand why they should.  Here is one small example from my experience. I was doing some business analysis consulting at a state agency that was just beginning to use the RUP methodology and the Business Analysts were busy using use cases to document most of their requirements.

One story I heard when I first arrived on my assignment was that they had written all their uses cases in great detail and had an approved prototype. The developers had done their testing, and they were really trying to rush to get everything ready to go to production when someone discovered a big problem that delayed the project for several months. During User Acceptance Testing, it was discovered that new data was now being collected from the users of this application but this new information had no where to go. The database did not know about the new data requirements. No one had collected the data requirements for the application - only the use cases. The data could not be stored. No one had modeled anything for the DBA.

To keep the project from being delayed, the IT group suggested that the business keep track of the data manually. Another option they suggested was that they could just create notes in the application with the new information until such time that the data requirements could be collected and the data models designed. The business folks were livid that such a silly mistake could be made. The project was delayed and no one was satisfied. Do you have any stories about why capturing and modeling data requirements is important for requirements elicitation?