Business Analyst Blog

I did a little sniffing on the web to find out what the acronym stands for, exactly. Silly me. I actually expected a cogent, coherent, standards-based answer.

According to webopedia.com and Wikipedia , the acronym variously stands for "System Development Life Cycle" (or "System Design Life Cycle") in most cases, and "Systems Development Life Cycle" by the DOJ (why lawyers have any say in this, I don't know).

Note the singular "System" in most uses (Wikipedia has a re-direct to the plural from the singular, so I presume they are considered to be of equal validity for that reference). Most modern, rapid/agile/fast/whatever methodology references I could find (see here , here , here and here for examples) refer to it in the singular, although that's certainly not univerally true (hit the link to the last example above for a real quandary). There are a ton of other, software-focused sites that call it, predictably, the "Software Development Life Cycle."

I couldn't find the Yourdon book to verify his Delphinic definition of the acronym. OK, actually: I threw up my hands in dismay after so many un-attributed opinions. I will probably never really care whether Yourdon refers to it in the singular or plural. Based upon what I can find, my gut says that "System" is conversationally interchangeable with "Systems" in most general-purpose cases.

In other words, people call it what they want.

Wait! What about "PLC" (Project Life Cycle)? Isn't that valid, too? I mean, what if there is/are no "System(s)" involved? Or software? Don't BAs just care about the "Project?"

I think you get my drift.  To cut to the chase:  There's no substitute for a good glossary. No matter how many arguments other people are having about terms, if they are defined in your company's glossary for all to see, then you can do business.

Isn't that what it's all about? Correct me if I'm wrong…

One of the knowledge areas included in the IIBA BABOK is Enterprise Analysis. I have noticed that when BAs review this knowledge area for the first time, many exclaim "BAs don't do this!". Honestly I must say that I had the same reaction the first time that I looked at the detailed tasks outlined. The knowledge area includes things like Strategic Planning, Business Architecture development and Business Case development. For those of us who have worked at large companies, these tasks are usually owned by a separate group called Strategic Planning or Corporate Planning.

However, the more that we talk about these tasks, the more than I see BAs doing this kind of work every day. We don't do it formally and often do it unconsciously but we do it. Experienced analysts are always questioning why we are doing a particular project or task, we are always thinking about how to spend our time in the most effective way for our employer and we are always considering how does this work fit with other groups in the organization. If a business stakeholder asked for a technology change that would negatively impact another corporate group, we would discuss the ramifications and brainstorm for another solution!

I would encourage BAs to become more aware of how much you do think about strategic issues for your organization. When you talk with a business stakeholder about how to improve their process you are thinking strategically and you are doing informal business case or cost benefit analysis. Don't sell yourself short - BAs are very strategic and perform Enterprise Analysis all of the time.

There are a number of requirements management tools on the market that can help Business Analysts and project teams more efficiently document, communicate, and manage requirements.  Most have integration points with modeling, development, and testing tools allowing teams to trace requirements through the project lifecycle. 

I want to stress that these tools will help you increase your efficiency.  This implies that you have already implemented a requirements management process/methodology that teams are effectively using.  Requirements management tools will make you more efficient only if you have a methodology that everyone understands.  Here are some steps to take before you start looking to purchase a tool.

1. Create and document a requirements management methodology.  Know what your needs are before finding a technical solution.  The methodology should include what your requirements package looks like, how you categorize requirements, what attributes you track, how you trace requirements, and who does what and at what point in the project.
2. Implement this methodology using tools like Microsoft Word which mostly everyone has access to and knows how to use. 
3. Use this methodology on pilot projects, identify lessons learned, and make the necessary adjustments.
4. Establish a support structure where project teams can get assistance with using the methodology and provide feedback.  The support team should be responsible for making adjustments to the methodology and communicating the changes.
5. Roll out the methodology to all teams in your organization.
6. When the methodology (process) is in place and the people using the methodology are effectively implementing it, you can begin looking for a tool to increase your efficiency.
7. Use your requirements management methodology as your requirements for the tool. 

If you do the above successfully you have a great chance for a successful tool implementation.  The good news is that some of the tool vendors don’t shy away from the fact that you should have a methodology in place.

I would love to hear from others that have implemented or are planning to implement a requirements management tool.  Please share your thoughts and experiences. 

I am not sure why so many people seem heated with the mention of agile development. Most of the concepts of agile development are not new. Anyone who has worked on any Rapid Development (RAD) projects in the past 10-plus years has followed many of the agile principles. The RAD process is considered the forerunner of agile methods (such as XP and Scrum). In those old days many of us followed the advice of Steve McConnell (Rapid Development: Taming Wild Software Schedules. Redmond, WA.: Microsoft Press, 1996) and we found that when project innovation was needed, we had great people both from the business and IT side who were co-located. We had access to good case tools, and we followed a strict time-boxed project plan for delivery, and the process actually worked great and produced some darn, good software.

Now it seems that many Business Analysts worry that agile means no process, no documentation, and no Business Analysts will be needed to participate. I disagree. What I see as one major difference between agile development and traditional waterfall development is one of documentation; how much is needed, why is it being done, and when it is done.

Traditional development processes such as waterfall are very prescriptive and have a set of required document deliverables. This type of development process has been working great for years on many large, complex projects. It still works, but it is not my favorite approach. Agile development stresses full involvement by the business, early prototyping, purposeful documentation and continuous evolution and delivery of prioritized working features on a software product.

Great Business Analysts are still in demand on agile projects. Seasoned Business Analysts don't need a prescriptive process to figure out what to do. In an agile environment, what will be needed is an experienced Business Analyst who understands different techniques and how they can be used to take advantage of an opportunity or to help solve a problem in the most efficient way. It is hard to argue with any of the fundamental principles of the Agile Manifesto. Waterfall or agile: Either can be effective in certain situations and each process is only as good as the person applying it.

We talk often about Product Managers and believe that their role is very similar to that of a Business Analyst. Like all job titles, Product Manager is used differently by different organizations. Generally they are responsible for eliciting requirements from customers (who may be internal or external), analyzing and documenting the requirements. They also assist with prioritizing requirements and work with the technical solution team to get the requirements implemented properly. Often Product Managers are located within the Marketing and Sales functional areas in a company.

In terms of skills needed to be a Product Manager, they are many of the same skills that we look for in a BA. I would list the ability to see the big picture and also be able to be very detail oriented. They must be good listeners, help customers articulate their needs, and ensure the product is built right and meets customer needs. In many organizations they also manage requirements changes, and are responsible for prioritizing requirements by their importance to many customers. Product Managers often have to make choices about which customers will get their requests first. This is a delicate balancing act! 

I was at the driving range this weekend, enjoying the weather and the feel of my 8 iron and it occurred to me that golf is like business analysis (of course if you love golf, it can be a metaphor for just about anything!).  Seriously, if you think about the game of golf, the player prepares, practices, studies and trains for a game where he or she never knows what challenges will arise. Every shot is unique, even if you play at the same course over and over. One shot lands in the sand, one in the rough, one on the left of the fairway, and the next one right in the center. And in addition to the landscape challenges, a windy day might change the yardage on a hole, a humid day will prevent the ball from flying as high, and a rainy day will require a firmer grip on the putter so that it doesn't get away from you.

An experienced golfer approaches every shot just as an experienced BA approaches every requirement: with a set of tools and knowledge about how to use each tool. The golfer makes a decision about which club to use, how hard to hit the ball, which direction to aim; just as a BA makes decisions about which questions to ask, which presentation format to use, how best to confirm the requirements. Sometimes the shot is perfect, hits the green and rolls toward the hole. Sometimes we hit the ground too hard and the ball dribbles a few feet. The experienced golfer assesses what adjustments need to be made and works to improve the next shot. The experienced BA assesses what adjustments need to be made and works to improve the next project.

Great golfers get that way because they practice, practice, practice. Great Business Analysts get that way by using the same approach!

Since we are a Business Analyst training company we talk a lot about how Business Analysts are trained and developed. We have BAs of various levels attend our training classes and even the most experienced or senior BA always finds some additional tricks or techniques that he or she has not used before. Some of our potential customers ask why do we not have junior level classes and senior level classes? This leads me to the question, what is the difference between a junior BA and senior BA?

There are two necessary ingredients for competency in business analysis: knowledge and skill. Knowledge means that you know something, for example you know what data is, or you attended a class on how to build an entity relationship model. Skill means that you have the ability to do the task, in other words, you have actually built a data model for a real project. In our training we try to give students both - we teach knowledge and then our workshops give you experience or skills. But we know these workshops are very different than doing a project in the real world.

I would say that a more senior BA has more experience working on projects. Is that fair? But how do you measure experience? Number of years? Number of projects? Accuracy of requirements? Number of defects found in the final solution? I think it is much more complex than simple metrics. A BA who has worked on many different types of projects (i.e., data warehousing, software package implementation, maintenance, new development) is probably more senior than a BA who has only worked on one application - even if the latter BA has more years of experience than the former. 

Many of our customers are developing 2, 3 or 4 levels of BAs to recognize that the skills of a BA can increase with time and experience.

In addition there is another dimension to the business analysis profession. I hope that we are going to see BA positions/titles represent the breadth of experience and project types that we work on. Some BAs work at a very strategic level, helping to identify projects, write business cases and develop business architecture plans - the IIBA calls this Enterprise Analysis. Experienced BAs in this area might be called Business Consultants. Other BAs are very technical, often holding the title of Business Systems Analyst or Systems Architect. They work very closely with the development organization and help to design the software, in addition to gathering the requirements.

The first opportunity to take the new IIBA Certified Business Analysis Professional (CBAP) exam is November 10, 2006, in Orlando, Florida. The announcement was made on the new IIBA web site on Friday, September 15, 2006. The eagerly awaited exam will not be a pilot. It will be the first opportunity to obtain a CBAP award from the IIBA.

The exam was scheduled for November 10, following the World Congress for Business Analysts conference. The conference facilities will be used for the exam and 50 candidates will be tested. Candidates must meet the IIBA criteria for certification which includes experience doing business analysis for 5 of the last 10 years and recommendations. See the IIBA certification page for all of the details. Candidates will be scheduled on a first come, first serve basis once their qualifications have been evaluated.

If you are interested in taking the exam in November, visit the IIBA web site and send a message to the certification team that you would like to apply.

Future exams will be scheduled in the coming months. Stay tuned to the IIBA web site or this BA Blog for news!

In Real Estate the mantra is Location, Location, Location.  If Requirements Management had a mantra it should be Prioritize, Prioritize, Prioritize.  From the highest level requirements down to the detail requirements, Business Analysts should work with the stakeholders to prioritize each requirement.

Prioritizing Project Objectives
When you are initially scoping a project, prioritizing the project objectives will help guide the team in understanding what is most important to the stakeholder.  This process and dialogue may even lead to the stakeholders realizing some of the objectives are not needed for the project.   At this stage in the project, estimates may be given to the stakeholders.  By having prioritized objectives, the stakeholders can decide to eliminate some of the lower priority objectives if necessary.

Prioritizing the Detail
As you move through the project and gather business, functional, and design requirements you should continue prioritizing.  In some cases, the priority may be the same as the project objective it is traced from, but the priorities can be different.  As the team has more detail requirements, better estimates are given and again the priorities give the stakeholders a basis for removing or postponing some requirements if the cost and/or duration of the project is longer than they would like.

In addition to aiding the stakeholders, the priorities guide the team on which requirements are most important.  Teams are often crunched for time in all stages of the project.  The requirement priorities are a tool that the team can use to determine where they should focus their attention. 

The prioritization of requirements will be needed during a project and you’ll be glad you did it!

As a Business Analyst we are dependent on our communication skills and our experience with handy analysis techniques to elicit excellent requirements. A successful interaction with our business and IT stakeholders involves choosing the right technique to fit the project, the problem, and the stakeholders. The choice will definitely influence a facilitated session outcome, the amount of stakeholder participation, and the quality of your requirements. With the right technique, you can gain critical insights into your business problem whereas picking the wrong one may lead you down the wrong path, or get everyone stuck debating trivial problems and requirements. Even worse - if the technique is confusing, requirements errors may not be discovered by the group. A good technique is understood by all necessary stakeholders and clears the path toward the required solution.

Do you have a technique that has worked well with your stakeholders? Share your success story. Here's one that I like:

The Context Level Data Flow Diagram is an example of a great technique to use at the beginning of a project to give everyone a high-level, shared understanding of what will be included in the project. The Context Level DFD is visual and uses only three symbols, and so it is easy to explain and understand. The process of drawing a Context Level DFD involves a logical step-by-step procedure where you will ask the stakeholders certain questions which will drive how you draw the diagram. Ultimately the group determines the boundaries of the project and all the external systems, organizations, or roles that interact with the project. While building the diagram, you guide the group through questioning to identify and prioritize critical information, reconcile any differences, and finally gain their consensus on the business areas to be further investigated. The technique also helps the stakeholders quickly identify whether the project is too large. A diagram that looks confusing and complex usually indicates that the project is too big and may pose a business risk. A good Context Level DFD illustrates in a clear, unambiguous birds-eye view the scope of the project, its boundaries and interfaces. The process of reaching stakeholder consensus results in much more than the simple diagram. The best thing about this technique for me is when I am done; I have a great starting point to focus my investigation and my stakeholders have a shared understanding of what the project is about.