Skip to main content

Getting Back To Basics

Written by Cynthia Low on . Posted in Articles.

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.

In a Google search of business analysis, the results weighed in with an impressive 73,300,000 hits. With all that information out there, where does one begin trying to understand how he or she might be successful in practicing even reasonably good business analysis techniques?  Returning to the fundamentals will enable you to utilize a kind of Occam’s Razor, or law of economy, in your technique.  Occam’s Razor is a principle originated in medieval times, and still used today, which states that entities should not be multiplied beyond necessity.  In other words; the simpler the better. 

There are five key fundamentals that will enable you to wield your own Occam’s Razor and derive great requirements: 

  1. Understand the overall business goals and the desire to build a solution that meets them
  2. Create a common understanding of “vocabulary” to be shared by all
  3. Identify the sources from which you will extract your requirements
  4. Understand which elicitation technique is most appropriate, considering your resources
  5. Understand – with absolute clarity –  what modeling techniques are most appropriate, given the solution(s) to be designed

This article will focus on the first fundamental. Successive articles will expand on the remaining four areas that must be practiced time and again on any BA development and management opportunity.

Be Clear On The Vision

So very often I have had the opportunity to parachute into a project where the requirements development process is well underway or about to get underway. Sadly, in the majority of cases, when I ask team members what the overall vision is for what they are doing, they are unable to answer this fundamental question. Without a common understanding of your destination, how can you and the rest of your team members be clear or confident on what directions you are to take in identifying stakeholders and defining, developing and even managing the requirements process?  No matter how large, how small or how urgently the client “has to have this,” creating a vision statement provides a map, and the BA is the compass that guides the organization in following the map. 

It isn’t my recommendation to write a lengthy vision statement; quality rules, not quantity.  In order to accurately define a vision statement for the project that you are about to begin or are currently adrift in, a simple question may prove to be the guiding light: “Is what we are doing adding value to the organization in that it supports the organization’s overall business goals, values, vision or mission?”

If you or any of your team members cannot answer this question in a short and concise manner, your project is at risk.

Some basic steps can be taken to correct the navigation instrument that will guide you to your destination.  Simply stated, the vision answers the who, what, why, when, where and how of what you are about to embark upon.  Consider this: if you were to get in an elevator at the lobby level and the executive sponsor were with you, could you accurately describe to him or her in one minute or less what it is that you are working on?  That’s right-a vision statement is your “elevator” speech, but from a business point of view.

There is no question that this will often evolve into a project charter or form the basis from which you will continue to refine your business case.  This is the starting point and will continue to provide input into other areas of your project, so above all, be clear on what you will include in your vision statement.  Here are some guidelines that I recommend:

  1. Clearly articulate the reason(s) that stakeholders are seeking to develop a solution
  2. Identify who the consumers of this solution will be
  3. Determine if the solution supports the overall business goals and objectives

Facilitating Consensus Among Stakeholders

If you are clear about the above process, then a facilitated session with key stakeholders and the executive sponsor with the intent of verifying these guiding statements should prove to be a relatively easy task.  Have the group identify the following:

  1. Why is there a need for a particular project?  Are we solving a problem?  Taking advantage of an opportunity?
  2. Who are the consumers of the end result (external customers, internal users, etc.)?
  3. What benefits will the organization realize and the consumer of the solution realize? Can we quantify those benefits?
  4. What is the nature of the solution?  Is it an improvement to an existing system or process? Are we in the hunt for a new product or service? Are we taking on the implementation of a complex system?
  5. If it is a service we are going to offer, will it be competitive or allow our organization to remain competitive in the marketplace?  Will it be a unique offering or service that consumers will actually want or use?

All of these questions can be answered using a variety of facilitation techniques, including

  • Brainstorming, or the nominal group technique
  • Requirements identification
  • Requirements prioritization
  • Consensus building
  • Workshops
  • Gap analysis

Prioritize the results if necessary but, above everything else, be certain that all the stakeholders come to a consensus on the vision statement and that it aligns with the overall business objectives and goals.  Using the steps outlined, one should be able to derive a vision statement. The following example is a vision statement for the development of a travel and expense management solution:

Any individual or business unit  that incurs expenses will immediately realize that automating such things as credit card downloads, approval chains, assigning GL codes, and converting foreign currencies will improve the speed and efficiency with which reports can be written and approved. Unlike the conventional and cumbersome means of filling in a spreadsheet, a Web-based product will not only provide the convenience of accessibility, but will also prove to be a great tool for auditing and evaluating types of expenses incurred, and negotiating travel expenditures with respective vendors.

The Three Ls of Business Analysis

I’m sure you’ve heard the three Ls of real estate:  location, location, location.  It’s the overriding, fundamental principal that every realtor knows.  For BAs, the word (and function) “quantify” is our equivalent mantra.  Here’s the best part about quantifying your findings: it’s empowering. 

Too often BAs abdicate their true role and become order takers.  Quantifying your findings will restore your true role as an objective advisor.  It takes the burden from you of being the bearer of bad news, since the numbers-the expected ROI or Internal Rate of Return (IRR), the amount and value of resources required, the deliverables-speak for themselves.  Quantifying the potential outcome will make the case for either assuredly moving forward or knowing that a project or program is not feasible. 

Take, for example, a retailer whose mission is to be number one in sales in their market.  Does it mean they are going to source the merchandise they sell or manufacture their own as well?  The BA’s role is to provide quantification to demonstrate outcomes for both sourcing and manufacturing options. Eliciting proper requirements is critical at this stage to determine, among other needs, what the target market should be, who the customers are, who is responsible for implementation and product development in its entirety.  

The Fundamental Edge

In a favorite quote of mine by John F. Kennedy, he said, “There are risks and costs to a program of action. But they are far less than the long-range risks and costs of comfortable inaction.”  Heady stuff, but it certainly applies when the success or failure of a business or organization is at stake. 

Time and time again I have witnessed client/customer pressures to produce quality services, and the effects that these pressures have had on a project team and BAs due to “cutting corners” in order to meet these demands.  Failure to get back to basics will result in increased risk, decreased quality and budgets that amount to, or exceed, the number of hits that Google produces when you perform a search for business analysis!

These are just a few of the risks BAs face as they perform their jobs.  However, deploying the fundamentals will ensure that you provide your best counsel for the organization’s success.

This is the first in a five part series of articles by Glenn Brûlé.

Glenn R. Brûlé has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI (www.esi-intl.com), he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis (IIBA), Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

Managing Requirements: Can ITIL help?

Written by Terry Longo on . Posted in Articles.

Over the last six months I have presented to numerous audiences on the topic of how Business Analysis and IT Service Management (based on ITIL) can work together, indeed must work together, to drive the level of quality and cost-effectiveness we are all seeking within the IT solutions space.

Interestingly, there has been a notable difference in the nature of the feedback

  • PM/BA audiences (such as those at the Project Summit / BA World events) have provided fairly positive feedback (and in fact the trend is upward over time)
  • ITIL knowledgeable/experienced audience feedback has been overwhelmingly positive, to the point where they are asking to have the presentation brought to their own organizations!

I am predicting that over time, as BAs look for additional ways to strengthen the rigor of their business cases, they will increasingly rely on the IT organization’s use of ITIL as a basis for defining and driving fundamental BA/IT interactions, including change management and financial characterization of solution development, deployment, and operation.

If you are a BA, do you work within or with an ITIL-based IT organization?  If so, can you identify specific benefits that have emerged from the IT organization taking the ITIL path?

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/sections/pm_bus_analy.html or at [email protected]

Let the Celebration Begin!

Written by Cynthia Low on . Posted in Articles. 1 Comment on Let the Celebration Begin!

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:

First 10 official BA Times Subscribers thanks for taking a chance on us:

  • Janette McGrath
  • Paul Thiara
  • Samuel McGrath
  • Paulina Corpuz
  • Kathy Vezina
  • Jenny Jones
  • Steve Willingham
  • Kate Edwards-Davis
  • Charmaine Jacskon
  • Sherri Marx
 First Content Contributors thanks for trusting us:

  • Kathleen (Kitty) Hass
  • Glenn R. Brûlé
  • Janette McGrath
  • Marcos Ferrer – our first Blogger
Internal team – without their support and dedication, there would be no BA Times:

  • Mike Morton
  • Sean Butt
  • Ollan Delany
  • Jimmy Manuel

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:

  • United States – 50%
  • Canada – 20%
  • India – 8%
  • Australia – 5%
  • South Africa – 4%
  • United Kingdom – 1.5%
  • New Zealand – 1%

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!

Changes You’ll See Starting Today:

  • New site template with a cleaner look and drop down menus from the main menu
  • New event calendar, including the ability of subscribers to post events
  • Custom images for each subscriber and contributor

Here’s what’s coming this year:

  • Content Categories – we’ll be placing all our content into categories to help you better navigate both new and archived content
  • BA Times Sub-Communities – you’ll have the ability to create virtual private sub-communities within BA Times. Great for IIBA Chapter communication, dedicated country communication and networking, or any other reason you can think of
  • Elibrary – where users can submit book titles and comments for reference
  • Online Stats – where you can see stats of subscribers online and connect directly to build your professional network and opportunities

It’s been quite a year! We truly appreciate your support of BA Times and would love to see it continue to grow to support the needs of the Global BA Community. Our initial objectives have not wavered:

  • Provide current educational content and information
  • Create a forum for BAs to exchange ideas and information

We will continue to ask for feedback and improve the site based on your needs! I ask only one thing of each of you: If you like our content and online experience, then tell a friend in the industry about BA Times. Either forward them a current eNewsletter or our URL. We’ve grown over the past year solely by word of mouth and intend to do the same this year. All our resources go back into improving the website, not marketing for new subscribers. We are constantly striving to improve what we offer our current subscriber needs, not hunting for new subscribers. So spread the word!!

Thanks again for a great first year! We appreciate all of you!

Best Regards,

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

Why I Love Being the Vendor

Written by Cynthia Low on . Posted in Articles.

There are two sides to the business analysis community:  The internal business analyst and the external consulting companies or contractors … “Vendors”.  Being the internal BA just isn’t much fun sometimes and often, the internal policies and practices can work against your success.  Sometimes it’s the company itself that has created a requirements analysis gap and the individuals – however strong they might be – just can’t be successful.  Entrenched, hierarchical, corporate cultures will always work against the internal BA unless a company has made the leap to reset the value and position of BAs within this hierarchy.  In spite of all these challenges, I’ve also seen internal organizations transform themselves from being order-takers, to being considered highly valued business drivers.  So often the difference in mindset for those that succeed is they’ve started to think like vendors.

As a vendor, I get to dictate the process or our company does not do the engagement.  This is a strong position – we’ll only do engagements we know will be successful, or we (subtly) take a pass on working together.  Vendors work from a position of strength and build up our “referenceability.”  If I can say “we’ve done over 1,000 of these” and give specific examples, people generally listen when you tell them “this is the way it gets done if you want success.”  Sure, the vendor has to tune the process around the edges to improve the fit with existing internal processes and issues, but the essence of how the work will get done stays the same on every engagement.  By negotiating the process of requirements discovery up-front, by identifying precisely where additional costs might exist, or how to tune their process to meet their specific business objectives, a vendor walks into an engagement with a higher level of commitment to the process than you would see on most internal projects.  A good vendor pre-loads the deck for success by setting out process, roles, and the minimum involvement needed from stakeholders before they take the engagement.  A vendor’s project intake process is far more structured – even where we’re outsourcing and doing 20 large projects for the same client in a quarter.  A vendor can’t deviate from working this front-end because we know that eventually, if we don’t scrutinize it closely, we’re risking failure on an engagement.

Vendors have done their homework on the value they bring.  We also dedicate about 25% of our corporate resources to ensuring that people understand our value in communications and direct sales cost.  Since a decent vendor has done the research, they can prove to management what will happen in time and cost if their process is not followed.  For example, I can show someone hard data from live projects on the reductions in requirements change we bring, the timetable improvements we achieve, and how our process brings value to larger, more strategic projects.  Because a successful vendor has thought long and hard about what it does, they can be more concise and quantified about the value we intend to bring to a specific situation.  We also separate organizational value management (sales role) from value delivery (consulting function) to more deliberately manage client expectations and satisfaction.  For the vendor, high satisfaction is only achieved by a specific path, that starts with setting the right expectations on the value we bring, and ends with help people both see and showcase that they were successful in achieving their objectives.  The thinking is different: Internal analysts tend to focus on task achievement; good vendors think about value management.

A successful vendor’s delivery team has conviction.  Conviction is that deep-seated belief that a process is going to be successful IF an engagement is conducted a certain way.  You can have business analyst training until you are blue in the face, but unless there is the absolute belief that the new techniques will be successful, these techniques will not used.  Vendors make people document the success stories and show these to the new consultants.  At our organization, we make sure that people know that the process has worked over 1,000 times successfully, and we take the cost hit to put our new people on airplanes to observe an engagement done by an experienced team, so that they can success for themselves.  We also get them to co-pilot an engagement with a successful user of the methods before we ever let them go solo.  All this effort is part of building both competence and conviction.  At the end of the day, a vendor can only be successful if every person on the delivery team is able to do the methodology in EXACTLY the same way and get a consistent result.  In our world, there really isn’t a second chance – we do exceptionally well, or we get fired.  Analysts follow the process a vendor dictates not simply because they understand it, but because they absolutely believe that they will be more successful if they follow it.  The path to developing skills is fairly straightforward.  The path to getting consistent execution is much more complex and relies on first building conviction.

I like to relate success and momentum in general within organizations to a big, heavy, flywheel.  A big success gets the flywheel turning a little.  Get a bunch of successes… and the wheel turns a little faster.  The flywheel is an analogy for a cycle of positive change where small, incremental steps lead to momentous change.  If I go back 10 years, our company tended to do smaller engagements of one or two weeks and we really did not pursue large-scale engagements.  Today, it’s the inverse – our teams tend to be engaged on extremely large and complex projects, and the smaller one- or two- week engagements are a smaller proportion of our revenue.   Vendors must deliberately manage momentum.  With positive momentum, the strategic focus of the organization shifts over time.  An organization with no positive momentum offers basically the same value to the organization year-after-year.  A vendor can’t simply say “our strategy this year is to do more BA stuff”.  In the vendor world, clients can be a bit ruthless, so vendors must either show momentum and continuously strengthen the value proposition, or wane in importance as service providers.

A vendor as specialized as we are (we only do business requirements) lives or dies by how we scope and size an opportunity, and how we determine the optimal process, plan and strategy to recommend for a requirements engagement.  We simply cannot miss when doing estimation – ever.  In fact, in the last bunch of years, I can’t remember sliding over-budget on an assignment.  We have to closely manage the number of client days used on an assignment and commit in a statement of work that we are going to produce “X” deliverable in “Y” days.  Most analyst organizations really do not manage client expectations on the number of days required to do requirements.  In fact, a mere 25% of organizations we recently surveyed accurately estimated the amount of time needed from the stakeholders. The rest underestimated by an average of 192% (get the results from http://www.iag.biz/).   How do you expect to maintain stakeholder involvement over time if the team consistently overruns expectations by almost 200%?

Finally, vendors get access to all the neat toys.  It is perhaps one of the bi-products of working with so many clients that you see what is working and what’s not, but more importantly, a vendor has a deliberate R&D focus to continuously look at new methods or technologies and see what makes them tick.  It’s neat to get a freebie copy of the latest and greatest from a tools vendor like RavenFlow and fiddle with it on an engagement.  Having a substantial R&D budget for BA best practices and technologies development means the vendor is able to get ahead of changes in client demands and talk to them about how, for example, agile methods can be made to work well on very large scale engagements.  Having an R&D sandbox in which to play with new technologies and methods may be fun, but candidly, it’s the only way to determine the practical application of these technologies and methods, and help the organization develop the value it brings to clients.  In fact, internal business analysts and vendor organizations both have access to the toys, the question is, is there a managed process to turn that access into value?

Are these lessons from the vendors well implemented in internal business analyst organizations?  Take a little test:

  • Do your BAs take enough time negotiating the process of requirements discovery – especially on strategic projects – to ensure success? 
  • How good is your organization at selling your process internally?  Do you measure or manage the value delivered to the organization?
  • Do you have consistently high quality requirements from all BAs?  Do your people have conviction that they’ll be successful if they follow your internal process?
  • Do you have strong momentum?  Consistently enhancing value brought to the organization – and an expanding budget/mandate?
  • Can you accurately forecast (+/-10%) the number of days needed for conducting business analysis and in creating business requirements?
  • Do you have a practical, managed process for BA process and technology R&D? 

If any of the answers are “No”, ask yourself, “why not.”  Why not force your BAs to do better elicitation planning, or publish your success stories, or benchmark your team against best of breed performance to showcase their strength?  Maybe you already have strong momentum.  But, maybe, you’re looking for ways to build that momentum and acting more like an external vendor is the path to help get you there.

Keith Ellis is the Vice President, Marketing at IAG Consulting (http://www.iag.biz/) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007.  Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the market strategy of the global outsourcer CGI in the financial services sector.  Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

An Eye for Value: What the Business Analyst Brings to the Agile Team

Written by Cynthia Low on . Posted in Articles.

There’s no question about it: agile project management expedites the new product development process. It is a streamlined methodology, based on having only essential people work in tight knit teams for quick and efficient results. Of course, one very important member of the team is the business analyst. Why? Because if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes to help provide guidance, not only during a project, but also before it is invested and after it is delivered.

In traditional project management, which comes from the construction industry, a great deal of up front planning and requirement generation is done. People can then walk away with finished plans in hand to construct a building. Though it is a logical approach for construction, project management has been adapted over time into an agile system for business projects that contain a significant technology component. For such tasks, it is difficult to articulate requirements for a future way of working that has not yet been tested. Agile projects proceed on more of a ‘learn as you go’ premise where small working teams include customers and developers who are co-located and spending 100 percent of their time dedicated to the project. The work is done in increments, and quick iterations are continually evaluated and modified. A project manager and a business analyst each play a crucial role on such a high performance team.

A project manager is essential for overseeing a product development project and making sure it comes in on time, on cost and with full scope. The business analyst is key in managing the evolving business requirements and the business benefits. According to the International Institute of Business Analysis (IIBA), the official definition of a business analyst is a person who works as, “a liaison among stakeholders, in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.” With the advent of agile product development and the constant requirements evaluation and modification within a project’s lifecycle, the business analyst is more valuable now than ever before. 

The business analyst involvement in agile projects, unlike that of the project manager, is not limited to the period of time when the projects are active. Business analysts provide continuity for companies, from cradle to grave, by working with portfolio management teams to make sure the most valuable projects are being invested in, providing oversight during projects, and finally measuring actual benefits after projects are completed.

Chart a Course with Portfolio Management

Portfolio management is a relatively new practice, which is coming into its own as organizations better understand the importance of how choosing the right projects to invest in helps them to achieve their goals. When involved in the early planning stages, business analysts serve a company by providing enterprise analysis. By evaluating the competition and conducting benchmark and feasibility studies, business analysts identify business opportunities and create a list of potential projects to support.

Next, the business analyst puts together a business case in which they analyze the best approach to a particular project and show quantifiable benefits. After all potential solutions are studied and analyzed individually they create concise project investment decision packages for the optimum solutions to present to portfolio management steering groups or governance committees.

Created with the right expertise and tools, these project investment design packages provide the information for proposed projects in a consistent way. Such a presentation allows the executive level decision makers to compare apples to apples, the expected value, cost and risk of one proposed project versus that of others. The decision-making boards can then wisely select and prioritize major project investments.

Stay the Course During Product Development

Once a project is approved and funded, a project manager is assigned to technically manage it. Ideally, a business analyst will continue to oversee and elaborate the business requirements and benefits they originally helped to define. The two professionals have different but complementary roles in the product development process. Through team leadership and collaboration, they successfully guide an agile project that is both efficiently and effectively run, and that has significant long-term benefits for the company.

A business analyst’s main priority, when first attached to a specific project, is to elicit business requirements and categorize them into valuable features or functions. Then each feature is described in enough detail to determine its cost versus its benefits. By knowing what it will take to deliver each individual component of the project, as well as what the return will be to the organization, the development team can then build components or features based on value, and deliver the highest value features first.

As an agile project progresses through its lifecycle of requirements, design, construction, testing and deployment, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction and tests, how much risk there is to the project and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions concerning costs to develop and operate the new solution and business value to see if they are still true.

Working with the project manager and the core team of developers and customers, the business analyst updates the business case at key milestones throughout the project and adds more detail to the project plan. For example, the business analyst may discover that a project is going to take 12 months instead of six, and will cost 10 million dollars instead of eight. The portfolio management team needs to be informed, so that they can decide if the project is still a good investment and if it should continue. The business analyst will make valuable recommendations, such as continuation with some sort of course correction, like a scaling down of the requirements.

Because agile projects often involve upgrading information systems, it can be easy for the technical developers to focus on what technology can do, rather than on how technology can best serve the specific goals of the company. Throughout the constant adjustments in the development process, the business analyst always keeps the focus on the business requirements, the costs and risks involved and what value the project will ultimately return to the organization.

The role of liaison between developers (engineers who may not understand the intricacies of the business process) and customers (business people who may not know what exactly to request technologically) is an important one. Alice Zavala, Senior Consultant for Management Concepts in Euless, Texas, gives the following example: An agile team was working to create a new company website, and the customer asked for a drop down menu with both credit card and check payment options. The developer has the know-how to create what is asked for, which is basic information on an aesthetically pleasing background, but there are business rules that need to be applied to the process that were being overlooked. In this case, the business analyst bridged the gap between what the customer requested and what the developer needed to provide, by proposing a back screen to perform an approval process before the credit card or check goes through. According to Zavala, such a situation requires oversight because, “in order for information to be put on the screen, we needed to know what other business processes are going to be touched.”

By being involved during the development process, business analysts validate that new components are actually meeting business needs. They also take information to other groups outside of the agile team, to further corroborate that the changes have the support of other stakeholders, who will also benefit from revised requirements or at least not have conflicting requirements that need to be addressed.

The Finish Line and Beyond

In conjunction with the cost of the development of a new business solution, the operational component needs to be analyzed and assessed before the project is implemented. With a major new business system, perhaps there will be a need for some reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to insure the organization is prepared for the impact of the changes. That way, when the final system is ready, it can be operated optimally.  

Once the new system is in place, the actual costs of development / acquisition and operation should be compared to its actual benefits to the company. If a business analyst has been involved from the beginning of the process, he or she will have created a business case containing projected quantifiable benefits, which can be measured against the end results. This final analysis shows the organization whether they have received their predicted return on investment. If the performance metrics show that the project was a success, great. If not, the business analyst can investigate to find out where the project went wrong. Was it a bad investment because it was too high risk? Was the project executed poorly, so that the project cost a lot more than expected? Was the organization not prepared for the new system, so that operating costs are much higher than predicted? This type of post-project evaluation is crucial to improving future projects because it allows a company to learn from its mistakes.

Team Players

With all of the opportunities enabled by new technology, businesses are establishing strategic goals to keep up with the times and stay ahead of the competition. To both set and achieve their goals, they rely increasingly on the skills of business analysts, who can not only assist in making projects successful, but help select and prioritize those projects with the most business value, and analyze the effectiveness and worth of a deployed system.

The project manager and the business analyst are both integral in creating a high performance agile team. While the project manager’s role is more technical (keeping the project running smoothly) the business analyst’s role is more strategic (provided the team with a road map). Without a business analyst on board, with an eye on strategic company goals, an agile team can be like a high performance car without a navigator – making good time, but not sure where it is headed.

This article first appeared in PM World Today eJournal. www.pmworldtoday.net 

Kathleen Hass, PMP , is the Project Management and Business Analysis Practice Leader for Management Concepts, Inc. and has more than 25 years of experience in project management, including project office creation and management, business process re-engineering, organizational development, software development, technology deployment, project management training, mentoring and team building. For more than a quarter of a century, Management Concepts, Inc. has provided quality training and performance improvement solutions for the mind at work. For further information, please call 703.790.9595 or visit the company website at http://www.managementconcepts.com/.