Skip to main content

Tag: Success

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]

Writing Effective Project Requirements

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.

Importance of Requirements
Requirements are considered by many experts to be the major non-management, non-business reason projects do not achieve the “magic triangle” of on-time, on-budget, and high quality. Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies, have shown that requirements are the biggest problem in projects. Projects fail due to requirements problems, the most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality software on-time and on-budget.

Furthermore, requirements errors compound as you move through a project. The earlier requirements problems are found, the less expensive they are to fix. Therefore, the best time to fix them is right when you are involved with gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The hardest requirements problems to fix are those that are omitted. This really becomes the requirements analyst’s dilemma. The analyst often does not know what questions to ask, and the stakeholder does not know what information the analyst needs. Since the analyst doesn’t ask, the stakeholder doesn’t state requirements.

The requirements phase is also considered by many experts to be the most difficult part of any project due to the following:

  • The requirements phase is where business meets (IT) information technology.
  • Business people and IT people tend to speak different “languages.”
  • Business: “It has been determined that if we convolute the thingamajig or maybe retroactive the thatamathing, our profitability may, if we are extremely lucky, rise beyond the stratospheric atomic fundermuldering.”

In other words, English is an ambiguous language, and we tend to speak and write in a manner that makes it even more ambiguous, convoluted, and unclear.

Building Valid Requirements
The requirements analyst truly is responsible for the failure or success of the requirements on a project. With that at stake, building valid requirements up front is crucial. The four steps to this goal are: elicitation, analysis, specification, and validation.

Elicitation
The term elicitation is the industry-accepted term for getting the requirements from the stakeholders. Elicitation, however, implies much more than just capturing or gathering the requirements from users.

The truth is, one of the surest ways to fail in requirements is to say to your users, “Give me your requirements,” then stand back and “catch” them.

Why doesn’t this work? The stakeholders are experts in their domains. While the analyst probably has more expertise in the IT domain, the two speak different languages. The stakeholders truly do not understand exactly what IT needs to be able to develop an effective system for them.

So the only way for a project to obtain comprehensive, correct, and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them.

The reality is that the quality of the requirements depends on the quality of the solicitation of them by the analysts.

Analysis
Analysis involves refining (or analyzing) the stakeholder requirements into system, then software requirements. Analysis is a critical step, that is too often omitted or bypassed in projects.

Analysis is the critical transition from stakeholder or business terminology, to system or IT terminology. For example, stakeholders talk about “Monthly Marketing Report,” while systems talk about file “MoMktRpt.doc.”

Analysis involves brainwork, but it is not a magic process (nor is any other part of software engineering, for that matter). Analysis is usually done in conjunction with various modeling techniques. Modeling-creating diagrams using standard notations-allows analysts to more fully understand processes and data in a rigorous manner. This understanding allows them to convert the often non-rigid stakeholder requirements into more concise, rigid system and software requirements.

Common modeling techniques include the following:

  • Traditional systems
  • Dataflow diagrams to understand processes and activities
  • Entity-relationship diagrams to understand data
  • Object-oriented systems:
  • UML (Unified Modeling Language) diagrams, especially class diagrams for analysis, but also possibly collaboration diagrams

Specification
The specification sub-phase involves documenting the requirements into a well-formatted, well-organized document. Numerous resources are available to help with writing and formatting good requirements and good documents. For general writing assistance, books on technical (not general) writing should be used. A major resource is the set of IEEE Software Engineering Standards.

Validation
Once a requirements specification is completed in draft form, it must be reviewed both by peers of the author and by the project stakeholders in most cases. If detailed stakeholder requirements were written and signed off by the stakeholders, they may not need to participate in reviews of more technical system and software requirements. This presumes good traceability matrices are in place.

The specifications are reviewed by a group of people to ensure technical correctness, completeness, and various other things. Often checklists are used to ensure all requirements in all possible categories have been elicited and documented correctly.

Validation is actually a quality assurance topic. All documents produced throughout a project should undergo validation reviews.


This information was drawn from Global Knowledge’s Requirements Development and Management course developed by course director and author Jim Swanson, PMP. Prior to teaching for Global Knowledge, Jim worked 25 years for Hewlett-Packard as a business systems developer, technical product support, and senior project manager. Prior to HP, Jim worked as a Geologist for the US Geological Survey.

 

Copyright © Global Knowledge Training LLC. All rights reserved.

Putting the User Back into User Acceptance Testing

Why is getting users involved in User Acceptance Testing (UAT) so challenging? Isn’t it called UAT because the users are the main participants? My experience has shown that involving users in all phases of the project, especially UAT, is the best way to ensure project success.

I recently worked on a project in which a major defect was found after the software application moved to production. This defect caused the users to perform three days of manual processes. Users on the IT project team worked countless overtime hours. The defect also resulted in a frustrated user group and business sponsor. The project team’s morale was low and the business users lost a great deal of confidence in the project team’s ability to deliver quality software solutions. To reduce the risk of making this crucial mistake in the future the project team improved the UAT approach by getting users more involved.

Traditional Approach

Too often, User Acceptance Testing is not taken seriously. For many reasons UAT gets shortened, is not conducted in a way that ensures a successful project or, the worst scenario, is not done at all.

An approach I have used in the past consisted of the project team members—Business Analysts and QA Analysts—writing test scripts and providing demos of the new application to the users. The users would then walk through test scripts step-by-step. In some organizations the BAs write and execute the UAT tests and then present the results to the users for sign-off.

Traditional approaches are often not effective because they are missing a key ingredient—the right amount of user involvement. In the project previously mentioned, there were five major issues relating to UAT that we had to address. These are common problems in many organizations related to lack of user involvement:

• Users may not be fully vested in UAT. In the traditional approach the users are directed by the BA during UAT and are brought in too late in the project to have an impact on the test plans. This results in a lack of ownership by the users and less responsibility on their part for the success or failure of the project.

• Users do not fully understand how the new functions should work when they are asked to test them. Just seeing a demo is typically not enough. This can result in the UAT session becoming a training opportunity and not a true test.

• Tests are often generic and are not all based on real-life scenarios. If the test scripts are written by the IT project team, there is a greater risk for missing real-life scenarios. This is because, unlike the user, the IT project team does not use the application every day.

• Project team members are usually pressed for time. Often a BA has already been assigned to perform requirements activities on another project during UAT. Balancing multiple projects means that BAs have a hard time focusing on UAT, while meeting their other project deadlines.

• High pass rate of UAT test plans. Ironically, this is not a positive thing. Often a BA writes test scripts and tests them himself prior to UAT to ensure the scripts pass. When a BA writes the test scripts the users are not given an opportunity to interject enough real-life scenarios to validate the system.

A Recommended Approach

To address these common issues and increase the chance for project success we need to take a new approach to UAT.

1. Involve key users early

Once Quality Assurance (QA) begins testing, UAT planning should start. Identify users who have a deep understanding of the business requirements and are change agents for the group. Identify all of the tasks that need to be accomplished, the owners of each task, and a high-level timeline. This will help ensure that all the right people are involved.

2. Provide hands-on training of the system for the UAT participants

Providing a demo is not good enough. Once QA feels the application is stable enough, give hands-on training to the UAT participants. It is critical to explain to the users that issues may arise because QA testing is not complete. Ask the users to stay focused on how the application works and not so much on the fact that it is not fully operational.

3. Use facilitation sessions to create test plans

Have the users write their own test plans. This may sound far-fetched, but it is key to getting UAT as close to real life as possible. The BA’s primary role is to facilitate the UAT test plan creation process, but not to write a single test script. Using process workflow diagrams and Use Case documentation from the requirements package, ask the users to determine what processes and system functions need to be tested. Provide the UAT participants with examples of test scripts and explain the need to capture the goal of each test, the necessary steps, and the expected results. The steps become second nature to the users of the system, and they often find it difficult to document each step they take to accomplish a goal. Help them think through their processes in detail to ensure they have documented each task completely.

Review the test plan. Once the test plans are written, the BA reviews the test plans to ensure all the necessary functions and processes impacted will be tested.

Determine necessary inputs and outputs. Once all the test plans are written, ask the users to document the inputs they need to complete each of their test scripts and the outputs that will be generated. Make sure all UAT participants have the necessary inputs to complete their tests based on all of the outputs. If some are missing, enlist other users to create those inputs during testing execution.

Make it as close to real life as possible. To enhance the real life feel, the BAs work with the users to determine a testing schedule. Make sure the schedule follows their daily process. Again, use process workflow and Use Case documentation to ensure the test plans are executed in the order the activities would be done in real life.

4. Ensure users execute the test

The BA’s role is to ensure the test environment is set up and to assist the users as they execute the tests. The user’s role is to execute their tests and document the results.

The Results

Recommended Approach to UAT

1. Involve key users early

2. Provide hands-on system training for the UAT participants

3. Use facilitation sessions to create test plans

4. Ensure users execute the test

Using this approach can help reduce the risk of major defects making it to production and ensures the users are satisfied that the solution meets the objectives of each project. Here are some of the key results from using the improved approach:

• The UAT participants take responsibility for the success of the release. They feel part of the team due to their collaboration with the IT project team and involvement in UAT planning, and test creation and execution. They also help champion the benefits of each release to the larger user base.

• Due to the pre-test training, users are comfortable with new applications. This allows the users to develop real life test scenarios, and the time allotted for testing is not used for training.

• Since the users create and execute test plans, the tests are very close to real life scenarios and the users are more comfortable running the tests.

In addition there are tangible benefits to future projects:

• QA incorporates the scenarios documented by users in the QA test plans for future releases.

• Over time there is decreased use of the BA’s time for UAT. With the BA facilitating the UAT process and not doing most of the work, the BA can focus on other necessary tasks – like launching the next project.

Implementing the Approach

A lack of user involvement in UAT is not uncommon. I urge you to try this approach even if you have not yet experienced a drastic wake-up call, such as major defects in production.

As we are called upon to deliver solutions faster and faster, it is just a matter of time before major defects make it to production. Here are some tips for getting started:

• Start small. To help manage the changes with the new approach, identify a release with a low number of users and/or new functions. This will allow you to test the new process, discover lessons learned, and make the necessary adjustments.

• Plan for additional time. Using this new approach will initially require more time. Work with your Project Manager to plan more time into the UAT phase for your first two or three projects. As you get accustomed to this approach, it will require less time.

• Identify power users and champions of application. They are your best testers and have the most interest in the project’s success.

• Sell the benefits of the new approach to your users. As with any new approach, BAs need to help the users understand what the approach is, and how it will ultimately improve their business.

• Save the user test plans for future releases. Reuse of test plans will help speed up the time dedicated to UAT in future releases and can be used to update your QA test plans. Successful implementation of this approach helps ensure projects meet the user needs. The collaboration of users with the project team leads to a shared responsibility for the success and failure of the project.

What is UAT and Why We Do It?

UAT is the final approval by customers signaling the new system or enhancements can be deployed. UAT is unlike other types of software testing (e.g., unit testing, system testing, integration testing), because during UAT we are looking for conformity. We need to validate that the solution meets the business objectives and works correctly with real-life scenarios. UAT is typically conducted by users with assistance from the BA and other project team members.
UAT is most often conducted before a system is deployed into a production environment. For higher risk projects UAT may continue for a period of time while running the old system and new system in production. This gives the users ample time to become comfortable that the new system meets their needs. For commercial software companies UAT is also know as “Beta” testing. Here the system is launched into a production environment, but only to a subset of customers who will provide feedback on defects and necessary improvements. 

Reducing the Trend of Failed Business

Change is the norm; fierce competition is the driver, and lean thinking is the latest call to action. Organizations in both the public and private sectors are struggling to not only react to the velocity of changes in the economic, political and global landscape, but also to proactively stay ahead of the curve. Organizations bring about change through programs and supporting projects. Projects play an essential role in the growth and survival of organizations today, for it is through projects that we create value in the form of improved business processes, and new products and services as a response to changes in the business environment…

To manage change effectively, organizations need to be good at: (1) establishing business strategies and goals, (2) identifying new business opportunities, (3) determining solutions to business problems, and (4) selecting, prioritizing and funding projects to implement major change initiatives, and thus meet business needs and achieve strategic goals. The major change initiatives that transform businesses may be:

 

  • Business process improvement and/or re-engineering ventures to replace inefficient and outmoded legacy business processes and technologies.
  • Significant change programs to continually tune the organizational structure, capabilities and competencies as the business model changes.
  • New lines of business requiring new business processes, organizations, and technologies to support the new operations.

Since data and information are the lifeblood of virtually all business processes, information technology (IT) systems are often a major component of these large change initiatives. As organizations depend more and more on technology for business communications and operations, software-intensive IT projects are becoming more and more essential to turn an organization’s vision and strategy into reality. Executives across industries and in the public sector have their eyes on the portfolio of business change initiatives and the supporting IT projects to ensure that they: (1) invest in the right mix of projects, (2) develop expert capabilities to deliver flawlessly, (3) allocate their scarce resources to the highest priority projects first, and ultimately, (4) capture the added value to the business that was expected.

How Well Do We Execute Business Transformation Projects? What is the track record for completion of complex business process changes accompanied by software intensive IT systems? We have an abundance of surveys that have been administered during the last decade revealing the rather dismal record of project performance, particularly for significant IT projects. The StandishGroup 2004 Third Quarter Research Report exposed the difficult nature of managing IT projects today: 71% of projects were challenged, meaning over time or budget; or failed altogether, meaning nothing of value was delivered to the organization.1 A public sector source of equally illuminating information is from the U.S. Government’s Office of Management and Budget (OMB), the federal government agency that evaluates the effectiveness of federal programs, policies, and procedures, assesses competing funding demands among agencies, sets funding priorities, and approves funds for major capital projects. This OMB March 26, 2003 study stated that 771 projects included in the fiscal 2004 budget – with a total cost of $20.9 billion – were at risk. The conclusion: the high cost of failure is unsustainable. As a result, the Federal IT Project Manager Initiative was chartered to raise the capability and maturity of project management for major change initiatives in the Federal Government.2

What is the Root Cause of Failed and Challenged Projects? What is the cause of this very disappointing record? It is almost certain that there is no single cause of the persistent state of troubled projects. However, there is a growing notion that poor requirements engineering is one of the leading causes of project failure. Requirements are hard to get right, especially for software – very hard. It is becoming clear that business system development must be treated as a specialist discipline, implementing requirements formed through good requirements elicitation, documentation and management techniques. Existing requirements engineering approaches, methods and tools simply don’t deliver the results that are vital for the success of organizations both public and private. As businesses across the globe rely on successful business transformation projects with critical IT components for their very survival, the stakes are too high to continue in a business-as-usual mode. The question is: what can we do to begin to reverse the trend of failed projects? In a response to the belief that more rigorous attention to requirements management will add considerable value to project team effectiveness and greatly improve project performance, business analysis is emerging as a valued business competency.

Business Analysis: An Emerging Profession In their quest to build the organizational capabilities to select, prioritize and manage projects, organizations have discovered that the core competency of business analysis must be elevated in importance, developed, supported and matured. Most organizations have invested handsomely in innovation and new product development projects, and in IT systems to help operate the business and capture business intelligence about the marketplace. Indeed, over the last ten years or so, organizations have begun to embrace the practice of professional project management. However, businesses and government agencies are just now beginning to understand the importance of the capabilities needed to identify strategic business needs to operate effectively and efficiently, and to act on those needs expeditiously. Those who acquire and master business analysis competencies will more effectively react to and pre-empt changes in the marketplace, flow value through the enterprise to the customer, thus remaining competitive.

The Business Analysis Professional The International Institute of Business Analysis (IIBA), founded in 2003, is an organization dedicated to advancing the professionalism of the business analysis occupation. The IIBA is the independent non-profit professional association serving the growing field of business analysis. The IIBA membership consists of individuals with various titles and filling a diverse set of roles – requirements engineers, systems analysts, business analysts, requirements analysts, project managers, technical architects and developers, and consultants – anyone involved in analysis for systems, business or process improvement. 3 The IIBA has developed the Business Analysis Body of Knowledge (BABoK) for the profession. The IIBA plans to work continually with practitioners around the globe to upgrade those standards through education, research, and the sharing of effective tools and techniques. 4 In addition, IIBA is developing a Business Analyst Certification Program, unique to the profession of business analysis. Establishing a certification for business analysis will go a long way in standardizing and professionalizing the practice of business analysis. The Certified Business Analysis Professional exam is offered in North America in 2007, with an international launch in 2008. The certification will create common expectations on the part of organizations for the knowledge, skills and competencies acquired to become a Certified Business Analyst.

 

NOTES 1. The Standish Group International, Inc. (1999) Unfinished Voyages, A Follow-Up to The Chaos Report. Retrieved Apr. 08, 2005, from The StandishGroup Web site: http://www.standishgroup.com/sample_research/unfinished_voyages_1.php.2. Federal IT Project Manager Initiative retrieved December 27, 2005http://www.ocio.usda.gov/p_mgnt/doc/CIO_Council_Guidance.ppt#425,1,Federal IT Project Manager Initiative3. International Institute of Business Analysis home page http://www.iiba.com/ retrieved December 21, 20054. International Institute of Business Analysis, Business Analysis Book of Knowledge draft version 1.4http://www.iiba.com/pdf/BABok_Release_1dot4_2005Oct27.pdf retrieved December 21, 2005

Building a BA Centre of Excellence.

Where to Start and What to Consider
 It strikes me as odd that, given the number of clients I have dealt with over the years, there remains a constant assumption that, because you provide training to a group of individuals in any given organization, you, by right of passage, become a “mature” practicing organization.   Get them together on an individual basis, however, and any one of them would tell you quite the opposite.  Disarray is perhaps the most fitting descriptor for this case.
We are always willing to acknowledge that which we continuously seek, industry standards. Sadly such industry standards are nowhere near where we want them to be.  Take, for example, the Chaos Report developed by the Standish group.  It maintains that, of all the projects it assesses in North America, only 34% of them would expect to finish on time, on budget and within the original scope defined.  ESI clients have shared with us in a recent survey the fact that the number one challenge in turning requirements into deliverables is poor requirements definition, followed by improper risk management and finally, scope creep.

 Why are our projects in a state of disarray?  It’s likely not the project management practice. Most organizations have a well-defined PMO and all the disciplines have been identified to conduct their day-to-day activities.  It is business analysis and the lack of structure, discipline and rigor around its day-to-day activities that, I believe, is the traceable root cause of project distress.

 It’s the situations where we have no formalized process for eliciting, analyzing, documenting, validating/testing, and tracking our requirements.  I’ve seen it time and time again where great degrees and variations of the above exist.  Organizations have 47 flavors of Business Requirements Document templates and they call this a standard. Their corporate solution development lifecycle gets hacked down, expanded, massaged, and tailored to meet a particular business unit’s need, and again we call this a standard. Methodologies are adopted and then tailored or crafted according to need or thought de jour!

 Another area of weakness: how can our resources possibly be expected to deliver with any degree of accuracy if we are not even clear on the tasks and activities that need to be performed to achieve the desired results?  Even more seriously, there is no linkage to our “standard methodologies.” As such, we insist on sprinkling the “magic fairy dust” over unsuspecting subject matter experts, and with a mighty push out the door in the direction of our stakeholders, who “don’t know what they don’t know,” expect them to achieve great results. Tell me that’s not a problem waiting to happen!  The other very interesting situation that continues to present itself where competencies and career definition are concerned, is that organizations continuously expect that PMs and BAs can perform each other’s given tasks.  Our resources are stressed out, and being asked to do more with less, in a shorter period of time. Clearly this need for speed is not working in our favor.

 It’s interesting to note that, while we would all acknowledge and recognize the errors of our ways, the real error is not being able to identify a starting point from which we can begin the process of maturing our BA practice. In a world where our daily activities are under constant scrutiny, I find myself repeating an old Japanese proverb “vision without action is a daydream and action with vision is a nightmare!”  The question still remains: where do we start?

Three things must be considered. 1) Have a plan, 2) Be patient and 3) Know your capabilities.  To have a plan, a project plan, means that, to some degree, you have considered the scope of what it is you and your team are about to embark upon. You clearly understand the major tasks and deliverables, and the time frame in which to accomplish such goals. Tactically, all tasks and activities that need to be accomplished to fulfill the needs of a developing Center of Excellence (COE) are easy to accomplish. Strategically, a cultural shift will not happen overnight, as a change in business practice must be carefully nurtured over a period of time, so we must be patient. Knowing your capabilities will allow you to understand the scope of what it is you are about to undertake. Being honest about the true level of maturity will allow the sponsoring organization to focus on the priority issues. Not all problems can be solved at once, even using advanced “technologies, thoughts and process.” For example, if it is understood that your organization is in its BA development infancy stage, why apply the most complex formulas to begin your baseline metrics. You must walk before you run.

Any good project manager or business analyst will tell you that, without active support, input and feedback, your initiative may be all for naught. Consider your stakeholders with thoroughness.

  • The Executive Team:  The strategic decision makers
  • Executive Sponsor:  May or may not be the same individual or individuals, but essentially hold the budgetary and resource means by which you will accomplish your endeavour
  • BA Director/Manager or Supervisor:  This individual will serve as the liaison between the tactical and strategic sides of the endeavour; they will be ultimately responsible for managing and maintaining the COE.
  • BAs:  Get them involved! Give them a sense of ownership; have them solve some of the challenges facing the organization; select a team of champions that represent the diversity of the BA group. After all they will be on the frontlines!
  • Project Managers:  Without requirements there are no deliverables. Without deliverables requirements have no meaning. This is a mutually exclusive relationship, and should be treated as such. Not including the project managers will encourage a siloed/ independent approach to the delivery of projects and alienate team members. Also consider that much of the structure and foundation of how PMOs evolved can be used as lessons learned for the development of a BA COE.
  • Functional Managers: There will come a time when the COE will have to engage the functional managers to provide additional resources for the definition and creation of requirements. As such, the borrowing of resources should not be impeded by a misunderstanding or lack of knowledge of what the COE’s purpose is.
  • Customers: Frequently, customers can be heard complaining about analysis paralysis, and are more focused on the outcome rather than the process used to get there.  It is the lack of knowledge and appreciation of this that is important to share with clients. Their feedback and assessment of the performance of the COE will be critical to its growth.

Have a plan, be patient and know your capabilities.

Levels of Maturity: Ask any organization and fifty percent of the time they tell you flat out that they are mature in their BA practices. They tell you they have three standard methodologies, and did some training, “our people are very competent” and, therefore they are operating at a Center of Excellence capacity.  The reality is this: while it may be true that investments are made to develop resources and put into place tools and methodologies this by itself does not constitute excellence.  The sum of all parts and the practice of organized and disciplined business analysis over a period of time constitutes maturity.  For the sake of this article, I have defined three possible levels of BA maturity. The titles themselves are arbitrary and may be changed according to the requirements of the sponsoring organization. It is the classification and characteristics of each level of maturity that will provide the needed assessment and guidance for development.

 

Level I – Community of Practice

Most organizations today are performing business analysis at a community of practice level.  They have recognized the need to develop the skill sets of their BA resources, and may have even gone as far as doing an assessment and evaluation of the level of competency of their BA group. As such they were able to identify any gaps that might exist in both performance and overall competencies and job descriptions.  Other organizations have also begun to put into place a solution development lifecycle and are likely to be in the process of either redefining or developing one.  A common question that comes up is this; what do we develop first, the people or the processes?  My response is go with the egg, eventually the chicken will come!  The processes need to define what needs to be done, and how it will be done, in the context of an SDLC. Job descriptions must define the ability, skill and knowledge necessary to perform the tasks and activities defined in the SDLC. The solution development lifecycle and job descriptions/career paths and competencies must be closely interrelated. They may begin to demonstrate an alignment with the PMO.

An overall acknowledgement by the organization of the role of the business analyst and its importance to the success of overall project deliverables is beginning to form. At this point our services, if sought, perceived as being reactive in response to an immediate need, and generally sought after as a utility. At this point, our accomplishments are only beginning to have any real recognition at the middle management level because of the tactical nature of our services.

Level II – BA Bureau of Maturity

There is no doubt in my mind that many organizations have demonstrated in some capacity their level of maturity given a specific area with the guiding principles in level of maturity. They may include some of or all of the following items, but in order to move from one degree of maturity to another demonstration of the following with consistency over a period of time is necessary.  A direct reporting structure to either the PMO or the CIO may be in place a Director of the BAB is likely to be the leader of the BAs and as such is making strides to present his team as a distinct business unit. The team is clearly a distinct pool of resources.  From a services perspective they are beginning to show signs of credibility amongst the business unit leaders as a result of consistent performance excellence. Business Unit Leaders are seeking out the team to provide assistance when needed, and the recognition of moving from a tactical to strategic role is beginning to form.

Level II – Center of Excellence

You’ve developed partnerships with the executive. Your team is sought after as the change leaders of the organization. You are clearly recognized as a customer service solution. You and your team have demonstrated your discipline both tactically and strategically. Most importantly, you have clearly defined the art of Enterprise Analysis (EA) and demonstrated your ability in the five areas of EA including, Business Architecture, Information Architecture, Application Architecture, Technology Architecture, and Security Architecture. Your team is providing and sponsoring studies to participate in overall corporate advanced and BPI & KPI’s and overall business effectiveness.  Your continuous assessment and evaluation of performance on internal process and customer satisfaction has become commonplace.

There are two keys to clearly understanding your level of maturity with the presented model. Acknowledge that it is likely that your organization may demonstrate maturity at a variety of levels given this framework. Also consider that true excellence must be demonstrated and evaluated as consistent over a period of time. As an example, training may be delivered in order to move the organization into a Community of Practice / level one of maturity. Training and learning do not stop here. Certification, coaching and mentoring, participation in improvement initiatives, and membership in organizations such as the IIBA, are the contributing factors that move an organization from one level of maturity to the next. In short, the sum of the parts is equal to the whole!


Glenn Brûlé, Director of Client Solutions for ESI International, has more than 15 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. Glenn’s background as an educator, communicator and business consultant has served him well through his many client engagements that have focused on understanding, diagnosing and providing workable business solutions to complex problems.In addition to his position at ESI, Glenn serves as a Director at Large for the International Institute of Business Analysis (IIBA). His primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries and government agencies. Glenn has successfully launched eight chapters in major Canadian cities and is currently working on launching eight more U.S. chapters and nine outside of North America. Glenn Brûlé is a frequent speaker at professional association meetings and conferences around the world, including ProjectWorld/World, Congress for Business Analysts and IIBA events. He has authored numerous articles on business analysis and was instrumental in the development of ESI’s white paper titled “Eight Things Your Business Analysts Need to Know – A Practical Approach to Building and Improving Competencies.”  

 
Watermark Learning Reports Increased Demand for Business Analysis Training

 As awareness grows in the project management industry, demand is increasing for business analysis training, since business analysis is frequently cited as a key problem area for providing inconsistent deliverables. As a result, companies such as Allianz Life have established a Business Analyst Center of Practice to ensure that their business analysts have the framework, processes, skills and techniques to excel in their profession.

 “Allianz Life engaged Watermark Learning for training because of its Masters Certificate Program in Business Analysis as well as its practical learning approach based on best practices,” said Lynn Lang, Allianz Life.

 “In today’s competitive landscape, businesses must perform with razor sharp efficiency and productivity,” said Terri Swanson, Watermark Learning, COO. “More business leaders are recognizing the value that business analysis training brings to an employee’s contribution and the effectiveness of an organization as a whole.”

 Since launching the Masters Certificate in Business Analysis in July 2005, Watermark Learning has received hundreds of participants in the program, including Allianz Life, a life insurance company.

 Allianz Life identified the business analysis process as their key problem area providing inconsistent deliverables. They established a Business Analyst Center of Practice to ensure that their business analysts had the framework, processes, skills and techniques to excel in their profession. As part of this initiative, Allianz Life looked to partner with a training vendor who could provide a professional business analysis certification program based on industry best practices, designed to specifically address their business needs.

 “Allianz Life engaged Watermark Learning for training because of its Masters Certificate Program in Business Analysis as well as its practical learning approach based on best practices,” said Lynn Lang, Allianz Life. “Not only will our business analysts receive a Masters Certificate, but they will also gain Professional Development Units through PMI as well as CEUs through Auburn University.”

 Watermark Learning is actively involved in raising industry awareness of the value of business analysis and was named an IIBA Endorsed Education Provider. It’s principals and founders, Elizabeth Larson, PMP, and Richard Larson, PMP, have helped develop the Business Analysis Body of Knowledge (BABOK), a document created to identify the key tasks that a business analyst would be expected to understand and perform