How Business Requirements Impact the Success of Technology Projects

The Business Analysis Benchmark report, conducted by IAG Consulting in late 2008, presents the findings from surveys of over 100 companies and definitive statistics on the importance and impact of business requirements on enterprise success with technology projects. The survey focused on larger companies and looked at development projects in excess of $250,000 where significant new functionality was delivered to the organization. The average project size was $3 million.

The word "gather" does not truly communicate the nature of the Business Analyst's (BA) job. You do not gather requirements-they are not just lying around on the ground waiting to be picked up.

The word "elicit" more closely matches the job, because it connotes a more active role for both the BA and for those with whom the BA works. The dictionary defines elicit as:

1. To draw forth or bring out (something latent or potential)
2. To call forth or draw out (as information or a response)

I recently worked with a virtual team that was developing and rolling out a new product across many European countries. One colleague in London refused point blank to cooperate with another colleague who was based in Amsterdam. When I asked why, I was told that my English colleague found his Dutch counterpart rude and offensive-even though they had never actually met or spoken. When I dug deeper, it became clear that the real issue was about culture and style: the Dutch team member, for time management reasons, only checked his e-mails once a day, used a far more direct form of speaking than his English counterpart, and wrote his e-mails all in capital letters. His English colleague felt he was being ignored and, when he did get a response, that his Dutch colleague was SHOUTING AT HIM!

Virtualization technologies have graduated to the big time, but it didn't happen overnight. While early virtualization application experiments can be traced back to the 1960s, it is only in the past decade that there has been growing acceptance of this cost-saving technology.

Co-authored by Rebecca Burgess

Ten Steps to Becoming a Bad-Ass Business Analyst

Do you want to take your professional capabilities to the next level? Do you want to add more than just techniques to your tool kit? Wanna become a Bad-Ass Business Analyst? Here are ten opportunities to apply "intelligent disobedience" and judicious audacity to your environment to earn those bad ass stripes.

Solution Assessment and Validation

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 moves forward, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the final 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.

Requirements gathering techniques include the easy to send, but sometimes hard to develop, survey method to obtain data from a wide variety of people located anywhere. Surveys, however, are notorious for many faults such as ambiguity and a lack of response.

But surveys can produce a large volume of information for the gathering parties to peruse and collate, so developing good surveys is important for both the respondents who have to understand the questions and for the collators to get useful data.

Do you find yourself suddenly being asked to do more with less? Was there once someone in the office beside you whose job responsibilities have suddenly become yours? Are you feeling pressure from your boss to deliver, deliver, deliver?

It isn't as if you were slacking off before. Between the meetings, the email and just doing your job there wasn't a lot of time left over. So how, exactly, are you supposed to manage now? Here are five success strategies for getting more accomplished with the time and resources you have.

Last month, we talked about Requirements Definition for Outsourced teams. In this article, we are going to explore a new dimension to requirements definition challenges that looks at the reality of today's distribution of departments, personnel, and company locations. While there have been many drivers behind today's distributed workforce, much of it has been driven by the record number of mergers and acquisitions in the past five years. IT teams are finding it "normal" to engage with peers and internal customers located in different buildings or even in different time zones. Gathering and defining requirements can be quite a challenge in this environment.

We know that men have a different workplace communication style than women - but does "different" mean better?

Well, yes.....and no!

There are obvious strengths and weaknesses in the communication styles of both genders. Based on a recent research project, in which I collected responses from 387 employees and managers in the United States, Canada and Europe, I found that both sexes identified the same set of strengths and weaknesses in themselves and each other.

The late Lew Platt, former CEO at Hewlett-Packard once stated, "If only HP knew what HP knows, we would be three times more productive." This is a typical situation in large organizations, where far too often, disasters arise from lack of awareness. Critical information is available in the organization, but goes undetected, is not communicated or is blatantly ignored.

How many times have you been in a meeting discussing a set of requirements, a methodology, or a project plan etc and someone has gotten up from their chair and said "where's the whiteboard let me draw what I mean"?

Busting a Requirements Document Planning Myth

Writing a requirements document - where does the time really go?

Have you noticed that requirements documents always take longer than expected to complete? Even when we follow the best practice of planning the activities, the reality is that even the most experienced of us blow our schedule. But why? There's a perception that the BA is "in control" of all the events, and in control of the document's progress from start to finish. We know that's a myth. Let's be bad-ass BAs and bust the myth.

How would you measure your efforts to involve the entire workforce in resolving problems that inhibit productivity and their ability to succeed? Although there are exceptions to every rule, it is a relatively safe hypothesis that most people want some control over how they perform their jobs each day. A key factor in the success of teams assembled to analyze problems, define requirements and offer solutions is how management responds to those suggestions. If those suggestions are accepted and acted upon, this is often the catalyst for motivating the team to reach for, and achieve, higher levels of quality.

Transitioning from ITIL V2 to V3

Not to long ago, the ITIL community was collectively starting to breathe again after the long wait for the publication of ITIL Version 3. The word before publication had been that V3 was an incremental update to V2, so we were told not to worry too much.

But what an "increment" that turned out to be! While we knew that V3 would be based on a service lifecycle that was a distinct (but welcome) change from ITIL V2, what we didn't know was the extent of new material in V3. The old tried and true material was still there (appropriately updated), but two completely new aspects were included in V3, namely Service Strategy and Continual Service Improvement.

Communicating upward in any organization can be difficult and stressful for associates who are passionate about their message. This scenario is even more difficult when the associate is trying to communicate his or her own value in conjunction with a growth or financial development plan.

In today's economic environment, business organizations are demanding focused attention to fiscal discipline. IT organizations are finding themselves asked to support in-production applications on flat budgets, and new development is largely being approved only by the rule of efficiencies. Software applications are the focal point of improving efficiencies, as consolidation and integration projects can both reduce support costs of multiple siloed applications and streamline business processes for end users.

Business cases are arguments for or against making a specific decision based on economic considerations. They are tools for decision-making. A business case describes the economic consequences of a business decision and makes a recommendation.

The importance of technology architecture, that is the relationship which exists between hardware and software used to produce the end result desired, continues to elude the 21^st century company. This is unfortunate, as it is a fact that the proper implementation of technology architecture can help business skate over the new and extremely challenging dynamics, such as cost cutting, global demand, and the fierce competition we all face.

Part one in this series described how to prepare, plan, and select a requirements management tool. Selecting the tool is usually the easy part. Implementing the tool without causing mass chaos brings a greater challenge. Now that a tool has been selected, what is the best way to gain acceptance and adoption of the tool within your organization? Change rarely comes without some resistance. This article will address how to maneuver through the resistance in order to successfully implement a requirements management tool by recruiting early adopters, marketing the tool, and communicating the change early and often. Finally, I will address some lessons learned while implementing a tool at several organizations.

Every organization is affected by change. Still, organizational change initiatives fail at an alarming rate. This is because most initiatives fail to consider how changes affect the people in an organization.

To successfully implement change initiatives, organizational leaders must identify the need for change and communicate it throughout the organization. They must also engage people at all levels of the organization by involving them in the design of the implementation strategy. Lastly, leaders must actively involve the people most affected by the change in its implementation. This will help ensure employees at all levels of the organization embrace the proposed changes.

Have you ever experienced this? Management attends a trade show and discovers the greatest requirements tool since the bread slicer. It will solve all your requirement issues and produce happy, satisfied business customers - or so the vendor claims. The manager purchases the tool and suddenly it's your job to implement it throughout the organization. "Go forth and do great things." your manager mandates. You walk away dumbfounded wondering, "Where do I go from here?" Experience tells you there is more to it than just purchasing the software; some analysis is necessary in order to successfully launch a new tool at your organization.

Weasel Words Will Send You to the Requirements Dog House

The holy grail of writing requirements is for the requirement to be validated before the application or system is released. Quality Assurance analysts inherit the work of Business Analysts. QA analysts are looking for something they can measure. All too often we business analysts are guilty of allowing what I call "weasel words" to nest in our requirements. Just as catching a wriggly weasel is hard, so is trying to validate a requirement that has no boundaries.

Equipping and Empowering the Modern BA

The principles of agile development were proven before agile - as a defined approach - became vogue.  Agile principles were being practiced to varying degrees in most organizations as a natural reaction to the issues surrounding a rigid waterfall approach.

If I may state the obvious, high productivity is good; low productivity is bad. That applies both to individuals and to projects. A number of factors affect individual productivity. Internal factors such as a person’s basic sense of self worth and the amount of discipline they bring to the workplace directly affect their output. Workplace environment and their supervisor’s management style can directly affect personal productivity.

The path to building great software goes through requirements management.  It's easy to forget some times, but the world relies on great software.  Software operates the cars we drive, the planes we fly in, the cell phones we can't live without and the tools we use every day to get our jobs done.  Software is everywhere.

Decision-making errors exist within all levels of organizations. Some common examples include:

• focusing on the symptoms instead of on the problem; 
• having no clear picture of the desired outcome; 
• becoming fixated on only one option; 
• making decisions that do not align with the overall goals of the organization; 
• missing opportunities to set decision criteria; and 
• failing to evaluate enacted decisions.

Demystifying "Return on Investment" (ROI) and Business Benefit

One of my managers, Denny Brown, used to say to me, "It's all analysis". He was talking about projects, so I was confused. It took me years to figure out that he was talking about "end-to-end" execution of a project. First we analyze the business need, then we determine the requirements, then we design a solution, then we implement the solution, then we measure the results to analyze how well the solution is meeting the original need.

It's no surprise that the certification of business analysts is more sought after today than ever before. Worldwide the demand for qualified practitioners, and the ability for them to quickly demonstrate their capabilities in requirements management and development, continues to grow.

The new role of the BA is far more strategic in both the organizational sense as well as at the project level. In fact, I would go as far as to say that the BA, when appropriately leveraged, represents a liaison between business, project and customer teams. This shift in responsibilities identifies two areas that need to be addressed by any organization seeking to expand this role:

• The organizational structure must support the actions of a “strategic” BA position. 
• The BA candidate must have wide skill sets, encompassing many general management competencies.

A telecommunications company in a hotly competitive market needs to deliver the next generation of cell phone to its customers quickly, and at the lowest possible cost. The company wants to adopt a baseline set of requirements for the next generation project, but must make necessary modifications to leap ahead of the competition.

The English romantic poet John Keats wrote in the poem Ode on a Grecian Urn ‘"Beauty is truth, truth beauty," - that is all/Ye know on earth, and all ye need to know.' This article proposes that, by recognising and reflecting on how a business behaves, we can find, cultivate and hone its beauty by clearly seeing the culture and behaviour that will make that business uniquely successful in its chosen field.

When times get tough, when people get stressed, and when they are faced with a crisis, it is interesting to observe how many people seem to suddenly become skilled in the Art of Blamestorming. Loosely defined Blamestorming is a meeting of like-minded people who enjoy sitting around in meetings, deciding who or what they are going to blame for their current plight.

Recently I was reminded that only 10 percent of conflict is extreme and that 90 percent of conflict is acceptable. In working with a client, I noticed some needs that were not being met. Those needs erupted into what we would call conflict between several people on the team. It was interesting to observe what took place. Mostly it was a flight situation. The people in the conflict situation left the area. This is not a bad thing as sometimes you just need to get out of Dodge. When it comes to conflict we all need to take some common thinking into consideration.

BAs Tend to Have a Narrow Focus on Project Related Work

All too often, the BA is unable to focus upon the right areas during a project due to a lack of enterprise analysis prior to the project. Because of this lack, the BA is forced to do requirements elicitation at too many levels at once rather than having focused requirements analysis at the business level leading to requirements elicitation and subsequent analysis at the functional level. This leads to several dangers.

Projects play an essential role in the growth and survival of organizations today. It is through projects that we create value in the form of improved business processes and new products and services in response to changes in the business environment. Since data and information are the lifeblood of virtually all business practices, projects with significant IT components are often the key mechanism used to turn an organization’s vision and strategy into reality. Executives have their eye on the project portfolio to ensure that they: (1) invest in the right mix of projects, (2) optimize their resources, (3) develop expert capabilities to deliver flawlessly, and ultimately, (4) capture the expected added value to the business.  In the 21^st century we are bombarded with constant change brought about by the Internet, the global economy and the prevalent use of technology. As a result, there appears to be a never-ending demand for new business solutions supported by IT products and services.  Executives across the spectrum are adopting the practices of superior project management and business analysis to increase the value projects bring to their organizations.

Guidelines for Interviewing Candidate BAs

You have just been told by your manager that you will be interviewing a candidate for a mid-level business analyst position on your team. "We can't hire full-time employees right now, but we can bring on contractors for this project. Make sure they have the skills we need, okay?" is the only direction you receive in the email other than the candidate's resume.

In a competitive job market, a polished professional reputation can make or break someone's chances of landing a coveted position. And since the word google became a verb, that reputation includes information that can be found online. This is particularly true for IT professionals who are evaluated on their technical savvy.

It's often been said that "you can't manage what you don't measure," which is still true to this day. Without purpose and a course to follow, the destination is uncertain and almost always unpredictable. Many management books have been written on this subject, ranging from personal development to organizational leadership. They all agree in principle that a purpose, goal or destination must be determined in order to chart a course and path to achieve them. Once the path or roadmap has been defined, the journey must be carefully planned to guide the traveler safely to the desired destination in the prescribed time within planned costs.

The Agile approach to managing software projects has been getting a lot of play recently. Why are people talking about it so much? Is this just the latest "new thing"? Or is there some real value to it?

The last Business Analyst Times of 2008, reviewed some of the important trends to look for in business analysis, or requirements management and development (RMD) in 2009. A global panel of experts from ESI International has its predictions about trends that will impact business analysis this year. These trends, listed below, acknowledge the growing importance of business analysis as a strategic, cross‑enterprise discipline, essential to the success of systems development, process improvement and change, especially in today's volatile economic environment.

Discovering a list of requirements and then not linking them to design, construction and testing often results in the delivery of a system that may not fully support the business process which it was intended to automate. Only through traceability can the project team ensure that all requirements are implemented. Traceability assures the business stakeholders that the developed system supports their original requirements.

Plus Four Fundamental Principles

Principle #1. Leave your ego at the door

• You are a business analyst - you have a license to ask dumb questions; it is your responsibility and your job! So ask the dumb questions, admit you don't know, ask for input, show work at early stages, don't let your own ego-fears-pride get in the way of problem solving.
• Put your team in the spot light, put yourself behind the curtain.

After 40 years of serious business software development, the issues involved in dealing with legacy systems are almost commonplace. Legacy applications present an awkward problem that most companies approach with care, both because the systems themselves can be something of a black box, and because any updates can have unintended consequences. Often laced with obsolete code that can be decades old, legacy applications nonetheless form the backbone of many newer applications that are critical to a business's success. As a result, many companies opt to continue with incremental updates to legacy applications, rather than discarding the application and starting anew.

A study by James Martin, An Information Systems Manifesto (ISBN 0134647696) has concluded that 56% of all errors are introduced in the requirements phase and are attributed primarily to poorly written, ambiguous, unclear or missed requirements  Requirements-Based Testing (RBT) addresses this issue by validating requirements to clear any ambiguity or identifying gaps. Essentially, under this methodology you initiate test case development before any design or implementation begins.

The close of the year tends to make one reflect on the past and ponder the future. Here we ponder some trends in the business analysis and project management fields for 2009. We invite you to read some of these trends and ponder for yourself our views about what project professionals can do about them.

The Greek philosopher Socrates said "In the world of knowledge the idea of the good appears last of all, and is seen only with effort". This article proposes that as business analysts we must have the audacity to seek out the good of a project using thought and effort to find the real business goals early on.

Integration is burdened by a lot of misconceptions. The uncertainties of an integration project can be deep enough to evoke hundreds of questions, specific to a company's back-end systems. This article will focus on five common thoughts where we have seen Integration sales reps dance around one or more questions, possibly because of either shortcomings in products or a lack of knowledge on how Integration really is implemented.

"Embrace change" is a useless platitude mouthed by managers or motivational speakers who have not thought through its full implications - or they are masochists who enjoy suffering. Changes that bring new opportunities or propel us forward are easy to embrace. But many changes look quite negative and are tough - if not impossible - to welcome. This list might include loss of a relationship, a loved one, health, job, money, and such.

When I was a Boy Scout we had a simple motto; “be prepared”. The same motto applies to facilitating discovery sessions with your stakeholders. In general, people are tired of attending meetings and discovery sessions. In the business world, business analysts, project managers, senior managers and all other stakeholders are busy people who deserve to have their time leveraged wisely. Here are some of the techniques you can use to get participation, gain consensus and leverage your stakeholders in discovery sessions and meetings.

Does leadership have an effect on project success? Is there a difference between management and leadership? Can leadership be learned? The answer to all these questions is yes. In this article, I will look at six attributes of project leadership. This is certainly not a complete list, just a start. One that I believe can help project managers achieve project success.

As human beings we created language and learned to classify objects in the world around us so that we could share concepts and ideas. Then we learned to write ... and we haven't yet learned when to stop! Often, repeated refinement of our customer's problem and need statements are seen as measures of quality and completeness of requirements. It's almost as if the greater the weight of the document the higher the quality!

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework, and as a result, over 80 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality.

It's a software development business analyst's nightmare - that doesn't seem to end.

Ten Core Design Principles

Leadership development workshops are very expensive. And I'm not just referring to the cost of facilities, materials, trainers, and bagels. When a company takes 20 or so managers out of the organization for several days, it is making a significant investment in their development. Those of us who are the architects of these workshops need to ask ourselves the question: Have we designed a workshop that is worthy of this investment? We at Bluepoint have been delivering leadership workshops for over twenty years and have learned that there are 10 core design principles that lead to a great learning experience. I would like to share these with you.

UML (Uniform Modeling Language) is a significant technical advance in the ability to formally specify, visualize and document existing and envisioned improvements to business processes and systems.   UML was established by the collaborative efforts of three software engineering leaders each of whom had his own formalized methodology:  Grady Booch, James Rumbaugh, and Ivar Jacobson.

Transformation. If the topic was not in the last Board briefing, it was in the one before that. A Celent review of the websites of largest 20 property and casualty and life/health insurers found the theme of business/operational/company transformation featured prominently on 40% of them. Major investments are being made in new technologies across multiple areas-policy administration, rules engines, predictive modeling, workflow managers-to change the way business is currently performed.

Requirements Summary

In this series we have provided an overview of requirements management, a description of the requirements management plan and its components, and some tips on how to negotiate for realistic time frames that include just enough time for the appropriate amount of requirements management.

Once again we have a mix of the latest part of a continuing series requirements management plus plenty of other new and interesting contributions about the business analysis world – what’s going on now and what to look for in the future – that are sure to give you something to thinks about. Plus we have an update about what’s new at the IIBA. And, of course, our bloggers are back, including one new one.

• I Don’t Have Time to Manage Requirements: My Project is Late Already! Part III. In this, the third in their series, Elizabeth and Richard Larson discuss the appropriate requirements management process for different projects; too much can be as bad as too little. 
• Creating Motivation through Discovery. Richard Lannon talks about the importance of motivating people. He says it’s all about asking the right questions, listening and understanding – and then taking the appropriate steps. 
• Will the First CBAPs Be a Credit to the Profession? Well Will You? Marcos Ferrer bills his blog as one of the world’s shortest blog. But he puts a very important question to all CBAPs. We hope you’ll answer him! 
• The Cost of Validation. New blogger, Jonathan Malkin takes a look at how much is invested in developing systems but often nothing to ensure the system works, yet, as he points out, Solution Assessment and Validation is an important area in BABOK.
• IIBA Launches Computer Based Testing of the CBAP Exam and a Letter from the President September 2008 are two important information pieces from The IIBA section of this site.
• Defining Roles in the BA Life Cycle. Terry Longo asks if a single BA can be skilled in all aspects of the solution life cycle. He thinks single BA ownership makes sense but finding the right individual can be tricky – but not impossible.

Also don’t forget to check out our webinars and the Business Analyst Times book shop. And let us know what you think about this edition of BA Times.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

I am often asked by business analysts, consultants, supervisors, managers and leaders, how do you motivate people? Motivation is an endless process. People, teams and organizations are motivated for different reasons. Your job as business analysts, supervisors, managers and leaders is to leverage your own business skills to understand what motivates the people around you.

Getting to the Right Amount of Requirements Management

Choosing appropriate requirements management processes is critical. It is important to find the balance between the extremes of a burdensome process and no process at all. All levels of rigor can be appropriate, depending on the project and the organization where the process is followed. On some projects, following a great deal of rigor is required; on others little is. Scott Ambler, a proponent of the Agile approach, stresses the importance of “just-in-time JIT requirements elicitation.” Alan Davis supports “Just Enough” approach.

Summer tends to become a bit of a habit, doesn’t it? And it’s a habit that’s often hard to kick. But no excuses! We have some articles that we feel sure will provide food for thought and help get you back into the business swing of things. I think you’ll find them a mix of pretty sophisticated business analysis ideas and techniques coupled with some getting the job done in general. Take a read and let us know what you think because that’s what helps us continue to run a website that is for and about you and your profession. And, talking of reading, don’t miss our new Bookstore that we set up just last month. It’s got a wealth of great BA books by leaders in the field.

• Implementing Business Analysis; Three Distinct Phases. Victor Teplitzky believes that introducing business analysis to an organization is something that has to be carefully planned if it is to be effective. He write about the three phases involved.
• I Don’t Have Time to Manage Requirements; My Project is Late Already! Part II. In the first article in this series, Elizabeth and Richard Larson looked at the framework for requirements management. Here, they discuss the relationship between the requirements management plan and the project management plan.
• Random Thoughts on Service Management. Regular blogger Terry Longo gives us his take on service–oriented management and business analysis – and other random BA thoughts.
• Labor Day is Here. Publisher, Adam Kahn, is sad that Labor Day 2008 has come and gone and the dying days of summer with it. But he’s also looking forward to winding up to take on everything that business can throw at him in the coming months.

And we hope you had a great summer and that you’re ready for and looking forward to new BA challenges and achievements in the busy days ahead.

Implementing business analysis (BA) in organizations needs to be a planned and organized project. It consists of three phases with each one having many sub steps. Phase 1 determines the organizational target and primary group that will be primarily responsible for BA and who will be given initial training in the skills and knowledge needed to implement BA including Quality and Continuous Improvement methods. Phase 2 consists of training the personnel and in Phase 3 BA begins to be applied.

Now that we have looked at the framework for requirements management, let’s delve deeper into requirements planning.

The Requirements Management Plan 

Planning the business analysis work effort is part of the overall effort to plan the project, and the resulting Requirements Management Plan becomes part of the project management plan. Below is a table with some of the key planning activities, the sub-processes associated with each, and the final deliverables that are produced. As stated earlier, these deliverables are rolled into the requirements management plan, which in turn, is a subsidiary plan within the overall project management plan.

An Overview

For those of us who have been given imposed deadlines that often seem arbitrary and unreasonable, managing requirements is one of the last things we want to do on a project. We worry about getting the product built and tested as best as we can. And we feel fortunate to gather any requirements at all. However the lack of a well-managed requirements process can lead to common project issues, such as scope creep, cost overruns, and products that are not used. Yet many project professionals skim over this important part of the project and rush to design and build the end product.

Many organizations today are looking inward to streamline their processes and increase efficiency. Traditionally, much of their emphasis has been focused on developing or acquiring high tech business automation solutions, while improvements regarding business processes and the documents that flow through them have been largely ignored.

People, processes, paper and technology must work together in an environment that promotes collaboration and accountability in order to maximize effectiveness and efficiency. Most organizations forget to include all relevant information involved in a business process while working in a digital environment.

More interesting and informative articles and blogs again, this month! A couple of new articles, one of which is the first in a new four-part series. Our bloggers are back and there are a couple of news items in our IIBA section we’re sure will get your attention. 

Introducing the new BA Times bookstore and library!

We are pleased to announce that the BA Times bookstore and library is now live! You can review and buy books, suggest new ones to add to the library, and write reviews and ratings!

• I Don’t Have Time to Manage Requirements; My Project is Late Already! Elizabeth Larson and Richard Larson take a look at how imposed deadlines can really have a negative affect to requirements management and, ultimately, the project itself. 
• Documents; The Neglected Side of Business Information Automation. Many companies are working to acquire or develop high tech business solutions. Mark Crandall believes that people, processes, paper and technology must work together to achieve success. 
• The Need for Speed. Adam Kahn worries about the fact that so many of us are having to do more with less, but he offers some practical tips to make your time go further.
• Will PMI Agree that BA Must Precede Projects? It’s a lot easier to make project estimates and plans if a BA has been there first. That’s the view that Marcos Ferrer shares with us in his blog.
• The Value of CBAP Certification and IIBA Monthly Webinars Start August 26, 2008. Two important announcements from IIBA that are well-worth checking out, especially if you’re considering CBAP certification.

This is the seventh and final article in this series. The first six articles were:

#1 Is It Time for the BA and the PM to Get Hitched?
#2 Effective Requirements Gathering and Management Needs the Skills of both the BA and PM
#3 An Examination of the BA and PM Skills Profiles
#4 A First Pass at Defining the BA/PM Position Family
#5 A First Look under the Hood of the BA/PM Position Family
#6 A Second Look under the Hood of the BA/PM Position Family

In April, I began a series of articles devoted to the basic practices of business analysis. With so much information now available, I felt it was important to go old school and make a case for the core principles of the discipline and why they represent the best path to success. 

Since beginning the series, I've talked about understanding business goals, creating a common vocabulary, identifying sources and choosing elicitation techniques.  Now, in this final installment, I'll be discussing which modeling techniques are most appropriate for a given situation.

The two final episodes in the long-running series, Back to Basics by Glenn Brûlé, and Bob Wysocki's examination of the possibility of merging the roles of the business analyst and project manager somewhere down the road. In this issue:

• Getting Back to Basics: Fifth Fundamental - Choosing the Best Modeling Technique for Success. Glenn discusses the importance of modeling in the business analysis process and, the importance of selecting the right technique for a particular situation.
• Where will BA/PM Professionals Come from? Next Steps. Bob Wysocki winds up his debate about the link between the BA and PM roles and makes a final plea for them to be combined.
• ITIL v3 Service Management. In his blog, Terry Longo examines ITIL and ITIL v3 in particular, wonders how prevalent it has become - or is becoming in organizations.
• IIBA Launches Worldwide Computer-based CBAP Exam. The International Institute of Business ANlysis provides details of its computer-based testing beginning in September of this year.

We hope you find this months articles useful and informative and that you'll explore some of the other features on our site. And we hope to hear from you with your ideas for future articles.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

We've got another line-up of timely articles examining the field of business analysis and surrounding areas. I feel certain that you're going to find some interesting and provocative ideas and we look forward to your responses, both positive and negative.

• When is the BA's Work Finally Finished? Many people think (some BAs and PMs included) that the BA's work is done when they've signed off on the requirements document. Jill Lilles points out that BA's role in the project is far from over.
• A Second Look under the Hood of the BA/PM Position Family. Bob Wysocki continues his series about the over-lapping roles of the BA and PM. In this article he takes a deeper look at the relative prominence of the two roles in different phases of their careers.
• IIBA. Check the IIBA section for the 2008 Annual Report and some comments.
• This issue's blogs. Marcos Ferrer revisits the challenge he threw out last month and asks why BA s don't have the same level of empowerment as many other professionals. Terry Longo talks about the side-by-side roles of the business analyst and the business manager. And I'm heading for a long weekend away from all forms of electronic communication ....I think. I promise not to....

All the best and I hope you're managing to enjoy the summer without too many interruptions.

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

This is the sixth article in the series. In the previous article (A First Look under the Hood of the BA/PM Position Family) I defined the BA/PM position family and the career path sequence. Then I wrote the generic position descriptions of the six-position family. The structure and ordering of the six positions in the BA/PM landscape is now defined at the generic level. Each of the 36 cells in the BA/PM landscape has now been generically defined with respect to the BA/PM position family.

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.

As 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
akahn@divcomevents.com

When it comes to choosing a company to work for, Gen X and Y are looking for advancement opportunities.

That was the number one incentive for 96% of respondents in the Gen Y demographic and 90% for Gen X according to a massive survey of almost 3000 Canadian workers conducted by David Aplin Recruiting. And while the survey didn't specifically address business analysts, there's no reason to believe that BAs in these age groups are different from the groups at large. Gen Y was defined as those born in 1980 and after; Gen X as those born from 1962 to 1979.

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.

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.

In this Business Analyst Times, we cover different sets of dynamics and it's probably fair to say that they all end up connected to groups in one way or another.

Richard Lannon examines the affect that different individuals can have on a group and invariably the affect is negative. In Group Dynamics and Requirements Elicitation, Richard identifies different character traits that can hinder requirement gathering in a cohesive group or in scattered groups. And, very important, he draws on his lengthy experience to offer very practical tips on how to deal with the different characters and situations.

The ongoing discussion about the BA and PM overlap continues in Bob Wysocki's current article, A First Pass at Defining the BA/PM Position Family. In this outing, he outlines some of the possible levels of positions that might exist, should the two disciplines ultimately merge into a new family of professionals.

Our regular bloggers John Dean and Terry Longo are back with their always thoughtful views on the business analysis world. We hope you'll find them not only thoughtful, but thought-provoking too, and that you'll share those thoughts with the rest of us.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

In the previous article I set forth and compared the skills profile of the Business Analyst and the Project Manager. That was a very high level comparison. In order to get down to the practice level proficiency, it is necessary to define the BA/PM Position Family. That is the intent of this article. Recognize that this is my opinion and has not been discussed with any of my business analyst or project manager colleagues.

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 April, I began a series of articles devoted to helping professionals wade through the sea of available business analysis information currently flooding the marketplace and focus on just the essentials. I like to think of it as Business Analysis Unplugged, my own personal back-to-the-basics world tour. 

Glenn Brule and Robert Wysocki continue their series of articles on BA basics and the morphing of the BA and the PM into a single professional. Both series have stirred a lot of comment, both pro and con.

In this issue Robert Wysocki lines up the BA and PM skills side-by-side based on what he found in the PMI’s PMBOK and the IIBA’s BABOK in his article, An Examination of BA and PM Skills Profiles, and his findings make very interesting reading indeed. In Getting Back to Basics: Third Fundamental – Identifying Your Sources, Glenn Brule takes a look at something that is often overlooked in the BA process: identifying the correct business requirements sources. Two thought-provoking pieces and we hope that you, our readers, will add your considered comments to the discussion. It will be interesting to see what the consensus is as both series continue.

On the blog front, regular contributor Marcos Ferrer takes his ongoing discussion of identity systems and adds five issues that, he believes, will be critical BA issues over the next 10 years. Our other regular, Terry Longo, is on a literary quest this month. He wants recommendations on which BA books he should add to his library – and which to avoid. And we hope you won’t avoid us. Please get in touch with your comments and suggestions.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

In my previous article, Is it Time for the BA and the PM to Get Hitched? 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 title. Along with that I promoted the idea of a World Class Business Project, Program, Portfolio and Process Office or BP⁴O, for short, to support this new professional.

Over the last few years I have facilitated several Information Technology Service Management (ITSM) work sessions within the oil and gas and utility industries. The challenge was to build consensus through identifying what is important, making recommendations and decisions, and establish direction that would enable the IT organization to improve processes and services offered to their customers. This article briefly outlines a number of lessons learned that came from our experiences.

In the last Business Analyst Times, Bob Wysocki suggested that, in this day and age, the business analyst and the project manager have much in common with major areas of overlap. He pointed out that the skill and competency profiles of the effective BA and the effective PM are virtually identical. He argued that possibly a new role will emerge combining the competency of both. Boy, did that set the fur flying! As a result, we've created a dedicated discussion forum for you to participate in. To go there now, click here.

Part two of Bob’s series, Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM, is in this issue and we invite you to read it and react by contributing to what is an ongoing and, at times, heated discussion.

Contributor Richard Lannon brings his experience in facilitating Information Technology Service Management (ITSM) work sessions in the energy sector to helping IT organizations improve processes and services. He stresses the importance of looking at situations from a broad business perspective rather than a narrower IT viewpoint. In his article, ITSM Work Sessions: Lessons Learned, Richard shares the lessons he’s learned over the years and how to put them to work.

Bloggers John Dean and Terry Longo are back. John shares his views on setting up identity systems, while Terry wonders should the BA be part of the IT department or have a broader role within business.

I know you have your own views – I’ve heard some of them on the road. Please share them with other Business Analyst Times readers.

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

CIO Survey Reveals Most Effective Retention Methods

In the information technology (IT) industry, money talks, but it's not the only employee-loyalty tool, a new survey shows. When chief information officers (CIOs) were asked to identify the most effective ways to keep IT staff, compensation (27 per cent) topped the list. Providing flexible schedules was close behind, cited by 21 per cent of respondents; another 17 per cent said opportunities for professional development helped to improve retention rates.

1. Plan the message before you write it. Before writing, ask yourself, “Why am I writing this – what do I want my reader to know and/or do?” When you have the answer, state it at the beginning of your message – this is your main point. 

Second Fundamental: Creating a Common Vocabulary

Right now, there is more information available than ever before about business analysis.

As someone who has dedicated his career to this essential discipline, I find this fact both exciting and a little frightening. On one hand, it demonstrates that business leaders have embraced business analysis as a key element to success. However, on the other hand, I worry that such a mountain of information, opinions and tools may simply be too overwhelming for those looking to bring business analysis to their organization.

9:50 AM Wednesday, April 16th, 2008 ProjectWorld * BusinessAnalystWorld Toronto 2008 Thank you for being part of this!

To view a slideshow of photos from the 2008 Toronto event, click here.

It's been a hectic couple of weeks with ProjectWorld * BusinessAnalystWorld in Toronto in mid-April and Project Summit & BusinessAnalystWorld in Philadelphia this week. But it has been an enjoyable couple of weeks meeting new and old associates, hearing great speakers and being exposed to exciting new ideas.

And we have another exciting Business Analyst Times for you. Glenn Brûlé continues his Back to Basic series with episode two, Second Fundamental: Creating a Common Vocabulary, in which he discusses the old bugbear - communication and the positive or negative impact it can have on the project. Robert Wysocki wonders if it might be worth considering merging the BA and PM functions into one. Always sure to make people sit up, he puts forward his ideas in Is it Time for the BA and the PM to Get Hitched? Sandra Lavoy looks at what it takes to retain good IT people and Natasha Terk revisits the subject of e-mail with Ten Tips for Writing Effective E-mail Messages.

Our bloggers are back in fine form with their distinctive views - and not always agreeing! Check them out and take sides or sit on the fence. Either way, let us know what you think.

Best Regards, 

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

They shouldn't. of course, especially if they're important business correspondence. In The Perils of Poorly Written E-Mail, Natasha Terk points out that e-mail has become the primary method of business communication with the potential of wrecking careers, undermining companies' reputations, and even making company secrets available to the competition - and that's no laughing matter. Business e-mails should be taken as seriously as any other company document.

Glenn Brûlé gets back to basics with his article Getting Back to Basics. He sees the year 2008 as the year to return to the foundational principles of business analysis to help cope with the vast volume of information pertaining to business analysis - 73,300,000 Google hits! This is the first of five articles by Glenn that will run over the next couple of months.

Nilesh Raje paraphrases Benjamin Franklin, the father of time management in his article Failing to Plan is Planning to Fail. He emphasizes the importance of planning as a key area critical to meeting the timelines for project deliverables. He stresses the importance of ensuring that all parties know exactly what is to be achieved.

John Dean is back with another of his blogs. Once again he's responding to Marcos Ferrer's blog from earlier in the month about identity systems.  Terry Longo takes an insightful look at how business analysis and IT service management can work together.

I hope to bump into you at Business Analyst World in Toronto but, if we don't, I hope you find plenty of good reading in this latest BA Times.

Best Regards.

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

First Fundamental: Understanding Overall Business Goals

I have noticed themes emerge during each of the last few years, which I believe embodied overall trends during the year.  For 2008, I believe "getting back to basics" is a theme that deserves great attention and consideration.  With the tremendous growth in both the acknowledgment and the embrace of the profession of business analysis, it's hard not to imagine BAs being simply overwhelmed by the vastness of information that exists. Returning to the foundational principles of business analysis will make the vastness more navigable.

Thank-you! Thank-you! Thank-you!

We are officially one year old today! Without your involvement, it would have never happened. When we launched BA Times a year ago, we had two simple strategies to achieve our goal of serving the global Business Analysis community:

1. Provide current educational content and information
2. Create a forum for BAs to exchange ideas and information

Our internal goal was to have 2,000 subscribers by the end of the year! Well, I’m happy to say that we’ve successfully accomplished that goal and then some…

I’d like to recognize a few people who helped us along in our first year:

BA Times has emerged as the industry’s leading BA portal and eNewsletter. We’ve grown to 5,726 subscribers worldwide! Here is the breakdown:

Subscribers Come from 86 Different Countries – Highest Subscriber % from:

We’ve continued to refine the site and offerings over the past year and will not stop improving. Thanks to all your feedback and suggestions, we’re building more features!

Great line-up of articles and blogs for this issue! From proper language of alignment to CBAP Soup to Nuts and everything in between, including a Letter from the IIBA President in the IIBA Insight section. I know that you’ll really enjoy this issue’s content.

I want to personally thank not only YOU, our subscriber, but all of our content contributors. We truly appreciate your insight, thoughts and overall contribution. Now – I’ve got one request to YOU – let’s here your feedback.

We have had a few suggestions to our new suggestion box, which we have quickly acted upon. Please utilize this new opportunity for you to offer ways to improve the site, suggest content, or offer new discussions forums you think we should add. We can not continue to improve without hearing from you so keep the suggestions flying!

Stay tuned for our 1 year anniversary celebration! Happy reading!

Best Regards,

Adam R. Kahn

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.

The business analyst (BA) role has become essential in today’s workplace as a vital component of a successful project. The business analysis field has been accelerating at a rapid pace, and this acceleration has caused some understandable growing pains. Among the challenges are a lack of standardization, inconsistent terminology across organizations, and difficulty in assessing knowledge and skills of BAs.

We are constantly striving to provide relevant content to promote your professional success. This issue's theme seems to center around Strategy.

What does it mean to be strategic and how does that make or break the BA role? These key questions will be discussed and analyzed in two key articles by Phil Ventresca and Maria Murphy.

Additionally, Marcos Ferrier continues to challenge the BA community. Be sure to read his blog and see if you measure up?

What can we do to improve BA Times? We want to make sure that every time you visit our website you find something new and useful. I'd like to see more dialogue among members in our forum section. What do we need to do to make it easier for you to connect with your virtual peers? Are there features we don't currently offer that you think would increase value to our site? We can't continue to improve without your valuable insight and feedback. Please let me know. We'll be adding an online suggestion box to the homepage, so please post your recommendations and ideas as often as you like or feel free to contact me directly.

Thanks so much for your support over the past 11 months. Can you believe that our next issue will be our one-year anniversary? WOW! How time flies! Do you have any suggestions for our first anniversary?

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

The new role of the BA is far more strategic in both the organizational sense as well as at the project level.  In fact, I would go as far as to say that the BA, when appropriately leveraged, represents a liaison between business, project and customer teams.  This shift in responsibilities identifies two areas that need to be addressed by any organization seeking to expand this role:

• The organizational structure must support the actions of a "strategic" BA position
• The BA candidate must have wide skill sets, encompassing many general management competencies

There is still a lot of debate in business analysis circles around what our role is, and what is offered by the various organizations, representing and supporting business analysts. Is the role all about requirements analysis? Are we just interested in IT and systems analysis or are our practitioners focused on the broader business and processes? Is certification of business analysts the answer?

I couldn’t resist working that figure into the headline. That’s 5,000 working business analysts that receive this newsletter twice a month to see what we have to offer. And we try - as the marketers say – to have something new and exciting for each visit. I think we’ve done it again with this posting.

First, we’re carrying an overview of a new study, Business Analysis Benchmark Report, undertaken by IAG Consulting. In this overview, Keith Ellis talks about some of the significant findings of the report, including the observation that companies with poor requirements definition overspend dramatically on major projects. Go to the article for some alarming facts and figures.

John Dean concludes his series Road to the Perfect Project. In this final episode he takes a look at what he calls “big process.” He describes this as a process that follows the company “cookbook” to ensure that projects come out well, but not great! He says, the problem with an ingrained system is that the project team must be thoroughly familiar with the system. If they’re hired for the project there’s a long period of training and adjustment.

Our regular blogger Terry Longo is back, and continuing his discussion about content vs. process, this time with the addition of a framework to tie things together, and which also provides the conceptual plateau from which to move on. John Dean (Yes, that one. See above) joins us in his first outing as a regular blogger. He’s picking up on and adding some views to Marcos Ferrer’s blogs - about Identity Systems - that he’s put his mind to over the last few issues. Also, visit the IIBA section to find out what they have in store for 2008.

Hope you enjoy this issue and that we hear from you. No, not all 5,000 at once!

All the best.

Adam R. Kahn
Publisher
Ph: 508-309-6900
Email: akahn@divcomevents.com

Findings Review

Business requirements serve as the ultimate blueprint for IT project success. That’s no big surprise. What might surprise many are the contents of a first-of-its-kind Business Analysis Benchmark Report by IAG Consulting. Among other things, the report found that companies with poor requirements definition and management spend on average $2.24 million more per project on their major projects.

Limit Formal Process

Many projects today, especially the larger, ones are run based on what I call “big process”. Development organizations get their systems and software engineering processes and procedures CMM/CMMI certified. This means that anyone working on their projects lives in a world controlled by a myriad of plans and processes covering all aspects of that project. Projects in these organizations will also be documentation heavy – typically based on IEEE standards. There are very good reasons for the existence of big process. These processes represent best practices distilled from decades of corporate experience. Big process does provide order and consistency to projects. The intention is to ensure consistent results. The project team just follows the system cookbook and all comes out well.

We're just into our second month of this Leap Year with our "once in four one day more" 29 day February and already we're up to our necks in activity, getting each Business Analyst Times online, planning for the next one and organizing a year's worth of Business Analyst Worlds.

We've managed to pull together a pretty good Business Analyst Times for the first week in February. John L. Dean continues his highly interesting and informative series, Road to the Perfect Project. This time out he takes a look at the importance of having a high quality set of senior analysts on any project. He also discusses how the PM and BA team can work effectively with the customer. Jim Swanson identifies the requirements phase as the point where business meets IT in his article, Writing Effective Project Requirements.

Our intrepid bloggers Terry Longo and Marcos Ferrer are back with their distinctive views on different aspects of our business. I'd also like to point you to our poll question from the last issue: we asked: Can the roles of Business Analyst and Project Manager be effectively combined? The results were: sometimes 45.8%; yes 32.2% and no 22.0%. Only 22% of you said categorically "no" while 78% felt they could be combined. Do you agree? 

As usual, I hope you enjoy this issue and please give us some of your ideas for future issues. It's the kind of input we need to keep our site truly relevant to you, our readers.

All the best.

Adam R. Kahn
Publisher
Ph: 508-309-6900
Email: akahn@divcomevents.com

The most important person on a project is the project manager. A good project manager with a supportive management style can make a project, and a bad one with an aggressive management style can single-handedly cause it to fail. I have seen both happen. As an ideal, the project manager will have personal technical experience that matches functionally the work being performed on the project. For instance, if it involves requirements elicitation, he/she should have personally done that kind of work. In a cradle to grave development effort, the more technical breadth that individual has the better. They absolutely must have excellent writing and presentation skills, and must be able to interface with both the customer and their own line management. The project manager has to have had management experience, some of which should be at the level required for the project.

Requirements are (or should be) the foundation for every project. Put most simply, a requirement is a need. This problem, this need, leads to the requirements, and everything else in the project builds off these business requirements.

Last year was the first year of life for Business Analyst Times, and what a lively year it was. We got going in the Spring of the year and by the time Summer arrived we were well on our way with a growing subscriber list. And much of our success is due to our contributors who provide us with the thoughtful, insightful content we bring you in each issue.

Of course without you, our subscribers, there would be no BA Times, or even need for it. But I’m pleased to say that you supported us right from the start. Like any start-up we crawled for a while, then walked and now we’re up and running. At last count our subscriber list stood at 5,927 and I’m quite confident that it easily tops 6,000 now, and is still growing.

I’ve already met many of you at Business Analyst Worlds and I look forward to renewing these friendships - and making new ones - at this year’s events in Toronto, Philadelphia, San Francisco, Boston, Vancouver, Chicago and in Montreal. They were outstanding events last year and promise to be even better in 2008. Click on the Events tab to get dates and other details.

And visit some of the other pages, too. Our Job Postings page is a fairly new feature, but already showing results. If you’re interested in changing jobs, getting contract work or you need to hire good people, check it out. Join the Discussion Groups and give us your two or more cents worth. And don’t miss our Bloggers, who are rarely without an opinion – and always willing to consider others’ views, although they don’t always agree with them!

Finally, please do let us know how we’re doing. BA Times is published for you and your input will help us make it more relevant to your interests. Are there any particular areas you’d like us to cover more frequently or in greater depth? Please take the time to send us a Top 5 list of articles you’d like to see in BA Times during this coming year? Send them to info@batimes.com.

Welcome to 2008 and please join us twice monthly through the year.

Many thanks and Happy New Year.

Adam R. Kahn
Publisher, BA Times
Ph: 508-309-6900
Email: akahn@divcomevents.com

Building The Right Thing

One problem with software development methods these days is that there are a lot of different ideas on the right way to build things, but we don’t have too much guidance on how to make sure we are building the right things. There is plenty of advice on the best techniques to develop quality software, but all of this guidance is based on the assumption that the team already knows what they are supposed to be building. When it comes to how to find that out, just about every methodology has the customer/stakeholder/product owner prioritize the features/use cases/user stories.

Welcome to the December 3rd edition of BusinessAnalystTimes.com.

As we go to ‘press’ our subscriber list is rounding the 4000 mark – we are growing like mad! From our team to you, thank you for joining us. We hope you will continue to pass the word and help us all to help each other grow this community of BAs.

This issue runs the range of interest to the new comer and the expert. I love the title “How to Become a Business Analysis Hero.” I think this captures a typical reaction from many outside our ranks these days. So many projects have struggled for years without the support of a BA. Hopefully these times are soon over. If the work is performed well – you can certainly become a BA Hero!

Infusing the BA into projects can be very delicate. Political and risky but continuing along the same line… the rewards can be immense.

And the IIBA piece on “What is a BA” is a perfect excuse to pass this issue along to those in your life who don’t get it.

We wrap this issue up with Marcos’s blog – always good reading.

Best Regards,

Adam R. Kahn
Publisher, BA Times
Ph: 508.309.6900
Email: akahn@divcomevents.com

In business today, any project is ultimately measured by one thing: return on investment. There are dozens of metrics to be measured along the way, from budget and deadline to scope and stakeholder satisfaction. However, at the end of the day, ROI trumps all.

Remember the movie Titanic? It overshot its budget by a nautical mile and took much longer to make than originally scheduled. However, a lifeboat full of Oscars later, the movie grossed about a billion dollars around the world.

JAD is an Important Technique for Iterative Development

An important aspect of the iterative development approach is the Joint Application Development (JAD) process. JAD is used as a technique for developing business system requirements. The purpose of JAD is to bring together IT and the business community in a structured workshop setting to extract consensus based system requirements. This is accomplished by using a trained JAD facilitator and customized, planned agendas to assist the participants in arriving at complete, high quality requirements. Experience has shown that the JAD process substantially reduces development time, costs and errors.

Part 3: Recommending Solutions that Address Expectations

As discussed in the first two parts of this article, project professionals realize that projects fail when customer requirements are not clearly defined and customer expectations are not met. The consultative questioning presented in the earlier parts is essential to understanding the business problem and its limitations. The project manager or business analyst can then analyze root causes of the problem or opportunity, and will be able to recommend a solution to solve the business problem at hand. If the recommendation is accepted, we can then recommend the most effective implementation approach. The major steps involved in the consultative approach are:

1. Asking questions to uncover problems and synthesizing the responses
2. Analyzing those problems
3. Advising clients by recommending solutions.

This article focuses on analysis and recommendations.

Dividing the Application into Versions

When assembling the project plan it is important to decide how you want to divide the applications into manageable “buckets”. This is an iterative process and will be refined later in the Requirements Analysis, Analysis and Design phases.

Part 2: Using Consulting Skills to Uncover Expectations

As presented in Part 1 of this article, project professionals realize that projects fail when customer requirements are not clearly defined and customer expectations are not met. Project managers and business analysts face a number of challenges in developing the kind of usable products that customers expect.

Editor's Comments

I do a lot of traveling in my job, and this year is no exception. It used to be that every where I’d go, I’d run into project managers, get involved in discussions about different aspects of the discipline, and generally get the feeling that the project manager was the beginning and end of the project life cycle.

This year, I noticed a big change. Sure, there was still plenty of chat about project management. But the big change was how much I heard about business analysis and the number of business analysts I ran into a long the way. And what an interesting bunch they were; full of great ideas and enthusiasm, and a determination to do their part to ensure that the projects they were involved in were all big successes.

Then I got back to the office and the whole picture began to come together. The Business Analyst Times subscriber list has just cracked the 3,000 mark, which more than exceeds our expectations for this point in time. What I like about this figure is that it tells us we must be doing something right, because these people are interested enough to keep coming back.

Then I heard from one of my friends at the IIBA that there are now 138 Certified Business Analyst Professionals in the field. Not too long ago the figure was less than 20, and there are, right now, worldwide, countless more aspiring BAs on their way to accreditation. And IIBA chapter are springing up around the globe, further attesting to the importance being placed on the BA profession. If getting your BA certification is something you’ve been thinking about, but done nothing about yet, check out the IIBA feature in this issue…and get moving!

And if you want to find out more about what’s going on in your profession, I hope you’ll take some time to read the contributions we’re bringing you in this issue. And just as important, I hope you’ll let us know what you think and what you’d like to see in future issues.

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

Editor's Comments

Welcome to the unofficial beginning of Fall and the new and improved BA Times (yet again)! If you’ve been a subscriber since our first few issues, then you’re seeing a theme develop – regular enhancements! It’s with great pride that I let you know about new and exciting developments:

1. A new Logo – with the key tagline, “the online community for business analysis.” The new logo and tagline further solidifies our commitment to provide the global community with a monthly eNewsletter, discussion forums, blogs, association communication, and industry news & information for business analysts of all levels.
2. I’m sure you already noticed the new layout and format. I hope you’re as pleased with it as we are. The new format will provide easier navigation of the content in each issue.
3. Industry Job Posting: We’re pleased to announce that starting today; we’ve added a job board to the site and are accepting employer posting for Free thru October 15th. After that date, there will be a small monthly fee to post positions. Stay tuned… as we’ll continue to enhance the features of this area (like we do with everything else).

As always, we continually strive to meet your professional needs. Nothing is written in stone and we will continue to adjust, add, and/or delete as necessary to best meet your feedback and suggestions. This month’s articles and blogs are informative and extremely useful. I hope you enjoy them as much as I did.

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

The construction of workflow models (aka business process models) is an essential technique that the business analyst (BA) needs to master. The Business Analysis Body of Knowledge (BABOK) defines a workflow model as "a visual representation of the flow of work in a business area. Workflow models are used to document how work processes are carried out, and to find opportunities for process improvement." (BABOK, v1.6, Section 5.13.7.1) The BABOK does not prescribe a specific notation for workflow models, although the use of a standard notation is suggested. For the past decade, the Unified Modeling Language (UML) has emerged as a de facto industry standard for the visual representation of analysis and design artifacts. Therefore, it is essential for the practicing BA to understand how workflow models can be represented in UML (Booch, Rumbaugh, and Jacobson, 2005).

Editor's Comments

What an exciting summer it’s been for BA Times! Over the past two months, we’ve introduced our Social Networking components and have now added comments and ratings to all articles and blogs on the site, as well as streamlined our Discussion Forums to create better categories and easier subscriber interaction.

Starting with this issue, we’ve updated the Discussion Forums to reflect industry categories, instead of actual topics. We feel this will create more freedom for you to post whatever you want to the site. Pretty much anything can be posted on the following categories – and we encourage you to do so:
New Discussion Forum Categories are…

• General BA Questions
• Certification
• Training & Software
• Professional Development
• Industry News
• Tips & Tricks

In addition to the above categories, you’ll see something else new and exciting on the BA Times site; comment and rating opportunities. I encourage you to freely comment and/or rate the content on the site. Your feedback will benefit both you and your fellow subscribers.

Lastly, I’d like to introduce Marcos Ferrer and his monthly blog. I’m very excited about his blog. His goal is to challenge your thinking to see the ultimate value of the BA. The title of his blog, “BA Rising” speaks volumes about that opportunity.

As always, we continue to strive to meet your professional needs. Nothing is written in stone and we will continue to adjust, add, and/or delete as necessary to best meet your feedback and suggestions. This month’s articles are informative and extremely useful. I hope you enjoy them as much as I did.

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

Editor's Comments

First, our apologies for sending the July issue a week late. We figured it was better to wait till the second week in July due to high vacation weeks in North America. We normally send the monthly eNewsletter on the first Wednesday of every month.

As I mentioned last month, we are excited to announce the addition of Social Networking to the Business Analyst Times website. If you haven’t already checked it out, please be sure to click on the following tabs on the updated website: Forums and/or Blogs.

We may think we know what the community is interested in discussing, but you are the professionals on the front lines! Therefore, we need you to contribute to the overall success of what we’re trying to create. Social networking is all about connecting with the community. We are delighted to provide the forum! Without your participation, it’s all for nothing; we need you to provide feedback, your thoughts and the interaction. Please enjoy the process and be sure to let us know your thoughts along the way.

For starters, we have created five Forums to get things rolling:

· Seasoned BA professional advice for new BAs

· BA Core Competencies- What should they be?

· How does a BA add value at the Senior Level?

· The BA Career Path - How did you get here and where are you going?

· Enterprise Analysis - Where do you fit in?

In addition, I have started an official Blog that I will attempt to update on a regular basis. Please feel free to post your comments to my entries. Additionally, if you’d like to create your own BA specific blog - or have ideas for additional blogs - we would be more than happy to add them to the website.

More exciting news! As of today, we have officially passed 2000 subscribers! We’re glad the global Business Analysis community has embraced Business Analyst Times and we look forward to achieving future milestones. When we launched four months ago, my goal was 2000 subscribers after one year. How exciting that we’ve met that goal is such a short time! Thanks for all the suggestions and kind words along the way. We can’t do this without your support and guidance. It truly is a community endeavor.

As always, please feel free to contact me with any feedback, ideas, or content you’d like to contribute.

Best Regards,

Adam R. Kahn

Publisher, Business Analyst Times

Editor's Comments

It’s been 3 months since the launch of Business Analyst Times! What a wonderful 3 months it’s been. As I mentioned in the very first issue: “Our goal is to keep you abreast of what’s going on in the world of business analysis, and to be as topical as possible.” Your feedback has been outstanding and I think we are well on our way to supporting that goal.

However, there is still much we can do to better support you. When we started, we had zero subscribers. I’m proud to report that in just 3 short months, we have grown to almost 1400 subscribers – all from industry word of mouth! If you like our model and feel your gaining value from subscribing, please help us grow by forwarding the eNewsletter to your colleagues and peers.

Please be sure to check out www.batimes.com over the next few weeks, as we’ll be adding some exciting features to the website. All of the features support the community of subscribers via Social Networking. We’ll be adding blogs, discussion forums, PodCasts, and VideoCasts to the site and we welcome any ideas, comments, or content you’d like to contribute. These new features are being added to provide you with the highest quality experience.

We are committed to supporting the international Business Analysis community and look forward to growing together to create meaningful ways to assist your professional endeavors.

Please feel free to contact me with any feedback, ideas, or content you’d like to contribute.

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
akahn@divcomevents.com

A recent survey conducted by Evans Data Corporation, The New Business Analyst: A Strategic Role in the Enterprise, found that business analysts are key players in making strategic decisions. "A clear line in the corporate sand has been drawn as to the importance of the business analyst. The BA plays an increasingly integral and strategic role in organizational success," said Evans Data Corporation President John Andrews. Business analysts are emerging as the central business competency of the future. Different from systems analysts or project managers, business analysts (BAs) not only manage project requirements, they also contribute vital information to strategic planning, goal setting and strategy execution. It is in this capacity that BAs can have the greatest impact on the long-term success of the enterprise.

Editors Comments

Isn’t that one of the primary roles of the business analyst? To help business do business better. To help organizations improve, innovate and continue improving and innovating, knowing that there’s always another few steps to go on the road to success.

Great business analysts recognize that asking the right questions of the right people is crucial to eliciting requirements that are on target and actionable. They know that sometimes they have to go back to the source a number of times to ensure mutual understanding. And sometimes, new sources are necessary to frame a complete picture. Ultimately, it’s how the smart business analyst interprets and uses the information they’ve gathered that goes a long way to ensuring the success of a project. And that’s what we’re trying to do at Business Analyst Times; to build on the success of our first issue and improve as each new issue is posted.

It’s a process of continuous improvement. And it’s a process we’re asking you to be involved in by telling us what you want to see in Business Analyst Times as we go forward.

A highlight of this spring issue is an insightful article,The Top Nine Requirements Misconceptions: Why Aren’t YOU Doing Requirements Right? by Ellen Gottesdiener. The article highlights many of the rationales and excuses for NOT doing the requirements job properly. Many of you will probably be able to count off many of the points with a certain sense of déjà vu. But the article is truly worth a visit. You’ll also find IIBA exam locations and dates; news and views from the industry and BusinessAnalystWorld updates.

Finally, we want to make Business Analyst Times a must visit venue for all BAs. To do that we need to provide you with content that interests you. And that means we need your input. Please get in touch with us and tell us what you would like to see in future issues.

As always, we welcome your perspectives. Please forward your ideas and comments to editor@batimes.com for inclusion in the next issue of Business Analyst Times.

“We don’t need to explore requirements—we know what we need!” “Hey, we’re using agile methods—we don’t need to define requirements!” “Oh, we don’t have time for requirements!” And so it goes. You’ve probably heard—and perhaps yourself offered—any number of excuses or rationales for not doing requirements right. No matter who makes these excuses—technical staff, the business sponsor, the project manager, or even business analysts—failing to carefully define your project’s requirements will put your project in peril. In my twenty years of working with projects, I’ve heard them all. Here are my top nine requirements misconceptions—and how you can refute them.

“The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don't play together, the club won't be worth a dime.”  Babe Ruth

When I was ten, I played softball for a local community league with my friends and neighbours, and my dad coached. I loved it. I loved hanging out with my friends. I loved playing third base. And I loved the feel of finding the sweet spot on the bat and scoring a run.  Of all sports, the one that I identify with most as a team sport is baseball.  It is an internationally recognized and played sport, that annually attracts viewers by the millions.  The players are respected and admired by legions of fans – what a great role model for any occupation!  

Completing information technology projects on time and on budget is both essential and a struggle for most organizations. Business analysts can help shepherd projects through to successful results by gathering requirements from a business area and presenting them in ways that are understandable and actionable by the organization. Unfortunately, the business analyst's job description is often vague. While many organizations know what needs to be done, they don't know how to identify and develop the skills necessary to meet these needs.