Skip to main content

Stories from the Front!

We have received REAL news from CBAPs at the front!  Check these samples out, and send me an email ([email protected]) letting me know which one(s) you relate to the most, and sharing YOUR story.

Story 1

I wrote and passed my CBAP in April of this year.  In February I was assigned to a new project and since I was deep into study mode, I was able to apply some new stuff I had learned to the project I was on.  I continue to refer to the BABOK regularly, refreshing my existing skills and utilizing new knowledge wherever I can.

In July, my manager interviewed a number of people for my mid-year performance review.  The Business Service Owner of my project told her that until now he had never really understood what it was that a BA did, and that I had raised the bar for the other BAs in the company.

Wow!

Story 2

Up to the moment I was certified I was convinced that I was pursuing a worthy goal.

Most people in the profession have been quite supportive but . . . those outside it seem bored or threatened by it.

After receiving my certification, there has been some resentment felt by me from other analysts and from IT architects.

There has been a certain amount of derision and mockery – one fellow began teasing me about my use of the CBAP designation (in my e-mail signature for example) as if I was trying to assume airs.

I think we have a LONG WAY to go to achieve any appreciation for what the designation means.

Story 3

Here are a few observations and experiences since certifying:

A better perspective on the big picture, maybe this is just my “proudness” of being a CBAP!

I have a better approach to BA work; from the high-level business  requirements to functional.

I have read more articles about PM/BA and about BA with Agile (we currently use Scrum).

In my travels, I still see the need to educate people on what a BA can do for a project!

I have gained more appreciation to work towards Enterprise Analysis and how BA can really make an impact with this.

NEXT MONTH

YOUR story here – or I will be forced to tell mine!

Thanks to my gentle readers for their frankness and willingness to share.  More shall be revealed.

Have fun!

Designing Great Leadership Development Workshops

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.

1) Research-based Content

A colleague of ours once mused that many leadership workshops appear to have been created by two guys in a bar in Milwaukee and recorded on the back of a beer coaster. The truth is that anyone can cobble together some interesting exercises and experiences, but to what end? We know the outcomes of great organization leadership…alignment, engagement, retention, productivity, teamwork, agility, to name a few. There is little mystery here. What many designers ignore is all the research that tells us what specific leadership behaviors, practices and approaches will create these outcomes. A good leadership workshop is grounded in this research and, as such, will equip participants with the capability to make an immediate, positive impact on their organizations.

2) Engagement

The frenzied pace that most managers face today has turned the otherwise calm and thoughtful participant into a skittish, distracted bystander, infected by a self-imposed form of ADD with one eye on his or her Blackberry and the other eye on the door. It’s not that these managers are disinterested in their professional development; they are simply products of today’s frenetic organizations. To get their attention, they must be entertained. While describing a good leadership workshop as entertaining may sound like a call to design a boondoggle, unless the workshop can successfully compete with the myriad of distractions facing today’s manager, we will simply be hosting adult day-care. The famous communications guru, Marshall McLuhan, made the connection even more direct with this statement: “It’s misleading to suppose there’s any basic difference between education and entertainment.” Videos, stories, games, debates, physical experiences and colorful materials all play an important role in participant engagement.

3) Story-telling

Every participant comes to the workshop with their own unique leadership story that has grown out of their experiences, beliefs, fears, biases and aspirations. A great workshop challenges the participant to create a bigger story for him or herself and the people that they lead. This can only happen when the participant has the opportunity to tell his or her current story and have it honored in the classroom. Once this happens, a new story can be crafted. The greater the story, the greater the development.

4) Feedback

No workshop ingredient is more potent than feedback. Whether it be multi-rater assessments or direct one-on-one communication, feedback is a powerful stimulus for personal change. And that’s what leadership development really is…personal change. What limits the use of feedback in leadership workshops? I believe it is largely our own arrogance. Too often we feel that the participant cannot handle the feedback. They are too fragile. They will somehow be irreparably damaged by our words or those of fellow participants. Or it may be our own insecurities. We will lose control of the workshop. Emotions will run rampant. We will not be able to handle the resulting carnage. Remember, the workshop is not about you; it’s about the participant. Be bold in creating a feedback-rich environment. The participants will thank you for the gift, maybe not now, but someday.

5) Appreciation

The problem with many leadership development workshops is that there is an underlying assumption that the ideal leader needs to develop a predetermined set of corporate competencies while becoming some fantastic amalgamation of Mother Teresa, Martin Luther King, Gandhi and Jack Welch. Let’s leave that idea to the boys at the bar in Milwaukee. We do not discard these elements entirely from the design process. Corporate culture and strategy rightly have a bearing on workshop design, and there is also much we can learn from the great leaders of the past. However, the best workshops are based on the assumption that all participants come uniquely gifted for the challenge of leadership, and the role of the workshop is to help them identify and cultivate these gifts. It is not our job to help them become the next Steve Jobs, but rather someone much more potent…the best leadership version of themselves. A workshop that is designed to help the participants accelerate the development of their natural strengths is much more potent than one designed to fix the participant or change him or her into the model corporate leader.

6) Intense Experiences

I have asked thousands of workshop participants to reflect on the following five items and select the one that had the most influence on their development as a leader.

(i) Reading and Research
(ii) Performance Appraisals
(iii) Coaching and Mentoring
(iv) Challenging Experiences
(v) Formal Training

Challenging Experiences” was selected by over 90 % of the respondents. (It’s interesting to note that Performance Appraisals always comes in dead last, but that’s a topic for another day.) Even though most designers are keenly aware of these findings, there is a great temptation to fill the workshop agenda with content that is largely extraneous such as succession planning models, managerial competencies, and corporate values. While the intention to provide material that can be applied back on the job is laudable, this information is largely ignored. People can read. Give them the content beforehand. Use the workshop as a learning laboratory where the participants are confronted with real leadership situations. Challenge them to lead at higher levels. Create a curriculum that exposes participants to intense experiences, and allow them to experiment with new behaviors and approaches. This will accelerate their learning and development. (By the way, most savvy managers have read all the corporate tenets and many of the important books on leadership anyway.)

7) Peer Coaching

In my ongoing survey, Coaching and Mentoring always comes in second. One-on-one learning processes are very powerful because, for a period of time, it really is all about me. Because coaching requires no content knowledge, any participant can coach another with a little guidance. For those of us who make our living standing in the front of a classroom trying to be insightful, witty and sage-like, it is difficult to accept the fact that the average peer coaching session is much more effective than our most brilliant lecture. Whenever possible, get your body and ego out of the way and let the participants talk to each other.

8) Self-awareness

It has been said that leadership development is an inside-out game. I like the way Manfred Kets De Vries puts it: “Healthy leaders are passionate…They are very talented in self-observation and self-analysis; the best leaders are highly motivated to spend time in self-reflection.” (Harvard Business Review, January, 2003) The leadership development workshop provides the perfect opportunity for the leader to step out of his or her chaotic schedule, put it in neutral, and take a long, fresh look inward. After all, the only thing participants can work on to improve their leadership is themselves. Put sufficient white space into the workshop design so the participant can personalize the learning. Most managers cannot remember the last time they took 15 minutes in complete silence to contemplate their own leadership journey. Give them the 15 minutes.

9) Performance Breakthroughs

The most frequently voiced dissatisfaction with leadership workshops is the lack of application on the job. It’s not because workshop participants do not want to change; it’s just that real change is so difficult. The pressures of the job, lack of support from their manager, no time…the list goes on. Significant improvement in leadership effectiveness rarely occurs in one big leap. We don’t see the freshly-trained leader walking through the hallways wearing saffron-colored robes, musing about shared community values and throwing rose petals on others (metaphorically speaking, that is). Change occurs incrementally and is fueled by short-term successes – a process that needs to start in the classroom. Bar the classroom door and let no one leave until they have demonstrated at least ten performance breakthroughs (again, metaphorically speaking…I think). Real change starts in the workshop, not back in the office. Start the habit of experimentation and incremental change in the workshop.

10) Learning Accountability

I kick-off many of my leadership coaching assignments with the eternally irritating question: “So, Sally, if nothing changes in your performance what is likely to happen?” Besides the mischievous delight I take in tormenting my clients, I have learned that I can serve them best by insisting that they take full responsibility for their actions, decisions, learning and future. Unless they take personal accountability for their development, there will always be someone else to blame…their board, their staff, their customer, their mother. So too with a leadership workshop. The question that needs to be oft asked at the workshop is “So, George, what have you learned about yourself and what are you going to do about it?

Our clients often report that the two or three days spent in our leadership development workshops were some of the most important days of their careers. Is this because we have great facilitators? Most certainly. A great facilitator can turn almost any curriculum into an important learning experience. But it is also because we try to adhere to the above design principles which, in essence, tell us that the workshop is not about us…it’s about the participant.


Gregg Thompson is a principle of Bluepoint Leadership Development (Canada) and the author of Unleashed! Expecting Greatness and Other Secrets of Coaching for Exceptional Performance. He can be reached at [email protected] or 604-313-5357.

Nearly Painless UML

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.

They were able to create a common set of formalized concepts, diagramming conventions and methods to foster clear and efficient communications that are effective for both traditional and the modern needs for object-oriented programs, database systems, and web-based applications.  UML has since evolved into an industry standard for software engineering best practices that is supported by tools such as Microsoft Visio and others. 

While UML concepts have had much potential for improved communication of existing processes and business requirements with business management and staff, their potential is often difficult to realize in implementation.

Conventional wisdom suggests a multi-day UML class to train the key business users in UML similar to that done successfully for technical staffs.   However, motivating and training already busy executives, business management and staff in a “cram UML course” often is overwhelming and ineffective plus it can easily instill a pervasive negative attitude toward UML and the requirements definition processes due to its perceived complexity and actual rigor.

The “Painless” UML Alternative
Business Analysts that have attained a good understanding and command of UML can identify current business processes and issues as well as communicate a vision for business improvements using UML.   By using some extra imagination and ingenuity they can create effective diagrams, charts, ROI analysis and functional specifications to communicate meaningful business concepts in UML that can be easily understood by business management, functional-area staff and technical staff without mentioning UML.  

These specifications and presentations can often be based on UML concepts, diagrams and methods without subjecting the business community to the rigors and “Pain” of formal UML training.    The primary goal of the Business Analyst and their Business Clients is to establish effective communication – the particulars of what type of arrow is used in which diagram is only important when all are trained to use the same exact conventions or when communicating with UML-Trained and practicing technical staff.

In many organizations, UML is often not of interest and not a priority for executives, managers and non-technical staffs – nor must it be.   In the author’s experience, effective UML and non-UML diagrams can be used to communicate efficiently to subtly begin introducing advanced UML concepts such as object-oriented inheritance, use-cases, functional swim-lanes and business process flows as ways to better understand and communicate business concepts.   In this way, such advanced concepts are efficiently introduced and learned gradually in a more natural way, as discussed below.

In many cases the innovative Business Analyst can consolidate a big picture of how the business is supposed to work, actually works or should work better into a single picture that is “worth a thousand words” to clarify, communicate and help make the right business and/or technical decisions (as illustrated in the example below).

painless1.png

The concepts communicated in high-level diagrams, such as shown above, can be further decomposed into functional components and detailed specifications that are easily painless2.pngunderstood by technical and non-technical staff alike.   Because staff members are already familiar with their business, they can now better see the complete picture and readily grasp new and advanced concepts such as inheritance (IS-A Relations) in the diagrams.

The staffing for the warehouse is clearly depicted in the object-oriented UML inheritance diagram (on the right) that shows the different roles assumed by warehouse workers. 

Likewise, the same approach can be applied to define other types of objects such as products or equipment to clearly specify the general types and subtypes.

The functional vision for a proposed system can be introduced at a high level (as shown below) and then subsequently shown in more detail as the functional design approach is further detailed.

painless3.png 

The functional design for a system as it affects different departments and functional organizations as well as the primary input and output information sources are shown in the example below,

painless4.png

The three separate vertical areas are called “Swimlanes” in UML.  The diagram above clearly shows the functionality and high-level process flow among: Sales Automation, Production Management and Dispatch & Routing whether you know UML or not.

As business processes are defined at additional levels of detail, “Use Cases” are a very effective way to identify business objects and the business operations that must be supported in the application for those objects as shown in the example below.

painless5.png

Use Case diagrams provide additional detail by showing which operations may be performed by each type of worker that was defined in the prior inheritance diagram. 

Use Case diagrams also employ inheritance relationships that are easy to understand by both technical and non-technical staff. 

The clarity provided by these diagrams and methods allow functional users to catch omissions and mistakes such as:  allowing the packing and shipping tasks, but forgetting that you must also provide tasks to accept and process returns as a part of project reviews and discussions.  

Use Case diagrams are especially important to object-oriented software development projects since they typically become a guide as to how the objects and programs are designed and structured.

As the business analyst continues to understand the new manual and automated processes that will be integrated, a new functional organization for the many different warehouses begins to emerge as a diagram that aids in efficient discussion, review and innovation by the functional, technical and management staff involved (as shown in the diagram below).

painless6.png

These examples are just a few ways a business analyst’s skill at understanding and creating effective pictures of your current process and the vision for your improved manual and automated business processes can be evolved methodically as a progressive series of steps.

Clear and effective communication of business facts and needs serves to get both technical and non-technical staff on the same page as well as leads to better project results. 

In Summary
This “Painless UML” case study has supplied examples as to how UML and even sophisticated concepts can be gradually introduced and discussed with business staff in a natural way by presenting their own business requirements and processes in a understandable format and making the extra effort to ensure that staff comprehends it.

The full UML (Unified Modeling Language) is quite extensive and many of its features, diagrams and nuances are primarily of concern to the technical staff – “Under the Hood”, so to speak, in the mechanic’s and engineer’s world.   Similarly, you only need to understand a car’s controls to drive it just as only a portion of the UML is needed for effective Business Analyst to Business Staff communication in the requirements definition and review processes.

The Business Analyst is the key to effective application of “Nearly Painless UML” for excellence in specifications for the technical community plus keeping the business community focus on effectiveness in the communication, review and gathering of business requirements information without mention of UML.


Byron Claghorn is Director of Corporate Development for Point North Consulting.  In this role he is able to leverage his broad experience to both develop and support the various Point North Consulting practices and our service offerings.  He has had a long and varied computer science, engineering R&D and consulting career with Burroughs and Unisys Corporation, Vice President of Engineering and Manufacturing for Microcard Technologies and as an Air Force data-automation officer. Much of his career has been focused upon the development of software products and application development tools, client-specific integration of document imaging technology with existing computerized applications, databases and host systems. Byron can be reached at [email protected] or 407-514-2651

Defining Requirements within a Short Time Frame

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework. As a result, over 60 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality. Without a clear idea of how to set requirements, most software development projects will face either significant rework or fail altogether.  Over the past few years,  Agile methodologies appear to be helping reduce this problem.  This whitepaper will explore techniques of capturing requirements within Agile teams.

Wikipedia says that, “The term Agile Software Development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project.”

So, if we apply a sports analogy, using Agile methods to develop software is like a series of sprint races. Developers are focused solely on successfully completing the next iteration, which is often due within a matter of weeks, and they zero in on defining their requirements to achieve that short-term goal.

In other words,  Agile teams don’t produce any requirements specifications that are not absolutely critical to making it clear to the team what is expected of them in the short term. So, the question becomes: How do you decide what requirements are “just enough” to complete the next iteration? 

There are a number of factors that need to be considered, when deciding what techniques and how much level of detail to provide when defining requirements for an Agile team.  These considerations should include: 

  • Team size and the proximity of team members
  • Skill and experience of the team
  • Has the team worked together before?
  • Complexity of the requirements
  • Complexity of the software.

Keeping the above considerations in mind, you will need to decide which techniques you will want to use and how much detail you will want to provide while using these techniques.

Common techniques include:

Verbal Communications. Verbal communications, perhaps using a whiteboard to capture key thoughts, is typically the fastest way to define a requirement.  However, what this approach makes up for in initial speed, it doesn’t ensure that all stakeholders are in the loop. Plus, participants may not all remember exactly what was decided after the meeting breaks up.  It is all too easy to have a different recollection of details that were discussed two weeks ago.  This can lead to misunderstanding of requirements during development and testing, and will be reflected in inaccurate product user guides and training material. So you may have saved time initially, but wasted more time in the long run.

So when is verbal better than written communication?  Agile methods promote face-to-face interactions, but that can be impractical in cases where teams are scattered across the globe or even across a city.  Relying only on verbal communications is a last resort, to be used only when short-term time gains are worth more than the longer term problems this approach can create. 

Story Cards.  A popular and valuable technique within Agile development teams is to create a story card.  These story cards tend to provide a text-based description of who wants to do what and why, along with perhaps a picture of the screen and some test scenarios.  This technique works well for very small features but may not scale well for larger or more complex features that integrate and depend on other features. 

Requirements Lists. Often a common place to start from a product scoping point of view is to create a hierarchical “Requirements List” which captures in text form an organized and grouped list of functional requirements, technical requirements, business drivers etc.  Often these text descriptions can be enough to clearly articulate what the requirement is  For example a technical requirement such as, “The application must support IE 6 and IE 7,” does not really need any additional explanation.  However a requirement such as “The application must be able to define which users can have access to specific functionality and data” will need much more detail.  The point is to only expand on requirements that truly need more details. 

Use-Case Flows. Sometimes to truly understand the overall flow of a more complex requirement use-case flows or simulations are required to capture “just enough” requirements.  However from my point of view it typically is not a good idea to use “use cases” to document complex logic or business rules such as authorization logic. These types of requirements are often better documented in text or tabular formats. For example, a simple 2×2 table showing the roles on one axis and what they can do on the other axis is a much more efficient way to convey authorization business rules than embedding alternate flows into use cases.

Simulations. Simulations can add great value to really bring a concept to life, but adding every single detail into the simulation can take too much time. And, frankly, it is sometimes difficult for developers to reverse-engineer a simulation and extract a discrete set of requirements.  It is much easier for an Agile team member to read a simple table showing who can do what, than to run through a simulation and reverse-engineer the same information. Also, it is possible to spend too much time doing elaborate simulations that don’t add enough value for the time and effort they can take to develop. 

Everyone will have their personal preference as to when to use what technique for communicating requirements, but the key is for the team to work together and agree upon when it makes sense to use different techniques and not “force” a technique when it clearly can be done more easily another way.

General Repository. No matter what techniques you decide to use to document requirements, keeping these requirements details/artifacts in a central repository and linking them to each other in an organized manner is critical to the collective success of your Agile team.  Relying on people to keep track of endless email trails and simple document repositories with manually maintained links is not the answer.  People are too busy to do it, and, most likely, the data repositories will not be kept up-to-date.  Because of that, any repository needs to do whenever possible to automatically create and maintain these links based on how the artifacts are organized. For example, if a use case refers to a screen on a given step, then that screen should be automatically linked to that step in the repository.

So how do you know what is enough detail?  Your team will let you know when things require more details.  Part of working within an Agile team is to expect the need for requirements clarification throughout the project.  In traditional waterfall, this was almost discouraged and under the good intentions of change management.  However, within Agile, it is expected and embraced, which takes some getting used to for Agile newbies.

Recap

This topic is much deeper than can be covered with this small article, but the key points are

  • Make a conscious decision on the level of detail you want but expect to tweak that during development.
  • Choose the right technique for the requirement you are trying to describe.  
  • Make sure you keep an integrated central repository that links together the multiple requirements artifacts. 


Martin Crisp is CTO of Blueprint Systems. He can be reached at [email protected]

 

Business Analyst Development in the Insurance Industry

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.

Enterprise change happens on multiple levels and with the effort of many individuals. It cannot happen without modifications to business processes at the transaction level, as committed employees work with business owners to analyze changes to the way work is done. Once that analysis is complete, support areas such as IT, HR, and Operations must work to implement the new methods. In most insurance companies, the people responsible for identifying, facilitating, documenting, and communicating the new business requirements are the business analysts.

In the Celent report The 18 Month Rule: Avoiding The Endless Project, (November 2006), it was noted that “between 30% and 80% of all large projects fail, with most estimates coming in on the higher side of this range.” The definition of failure is a project that is not fully implemented on time and does not meet the original requirements.

With this in mind, what is the state of development of the critical business analyst function in the industry? Celent researched leading insurance firms and found that the professional development of business analysts lags that of other functions. In many cases, the job lacks clear definition and boundaries. Skills are often learned “as and when” through individual effort and initiative. BA development has been described as an “afterthought.” In contrast to the underwriting (CLU, CPCU, IIA), claims (AIC), and project management (PMP) designations, there is no industry-wide accepted certification of business analysts.

The good news is that disciplined, structured development programs in the insurance industry exist and have been recently implemented. These initiatives have been justified by a disciplined examination of the role and the contribution of BAs.  This report examines these initiatives and also outlines the business case.  Additionally, action steps to move business analyst development to the next performance level are detailed.

What is a Business Analyst?

The business analyst operates at the intersection of business users and information technology. (Note: Since so much business analyst work is IT-related, in this report IT is used as a placeholder for all of the support groups necessary to implement new/revised business requirements.)

Core business analyst (BA) tasks deal with requirements definition, acceptance test case development and execution, and client communication. Defining requirements can include business process design, use case development, and user interface specification. In companies without a dedicated Quality Assurance area, BAs play a prominent role in acceptance testing and may be involved in other test activities (system and or integration testing) as well.  The BA is also recognized as a subject matter expert, having earned this designation through many years of experience with a specific business function or transaction system. Project management tasks can also fall to the BA, especially in smaller organizations or for implementations of limited scope. Emerging duties of the BA include the creation and maintenance of automated rules in rules engine applications, responsibility for business process management (BPM) tools, and the use of automated requirements generation tools.

Table 1: BA Duties

Always

Sometimes

Requirements collection, definition, and communication

Other testing (system,
integration)

Acceptance testing

Subject matter expertise

Client liaison

Project management

Creation and maintenance of automated business rules

Business process management automation

Use of automated requirements tool

Source: Celent

Organizational responsibility for business analysts varies. In some companies, the BA is part of the business. In others, the BA is firmly within IT. More than one insurer shared the fact that, in their company, reporting relationships for BAs periodically move from one side to the other.

The notion that wide-ranging tasks and changing reporting relationships create problems for BA development is a recurring theme in discussions with companies. One of the first tasks that leaders take is to build a fence around the duties of their business analysts. Bringing focus to the function is a key success factor in the leading development programs.

On the other hand, it does not seem to matter whether the BA resides in IT or in the business. What is critical is a corporate investment in the group and sustaining it over time.

When asked, BA managers describe the “ideal business analyst” using descriptors of both skills and personal characteristics. The skills required deal with a keen attention to detail, a “real world” knowledge of the business (especially company-specific operations, systems, and workflows) and effective verbal/written communication. However, because requirements gathering can be so relationship-focused, the best business analysts employ large amounts of empathy and influencing skills. Celent believes that the need to be able to “walk in a user’s shoes” and to exhibit an appreciation of their challenges at the coal face level tip the scales in favor of sourcing BAs from the business rather than from IT.

Table 2: Business vs. IT Sourcing of BAs-Skills Prevalence

Skills / Characteristics

Business       

IT

Attention to detail

Systematic thinking

Structured analysis

Deep understanding of the business

Communication

Empathy

Influencing

Source: Celent

Clearly, BA development is complex and sophisticated. This is not a “just add water and mix” HR exercise.

The Business Case

How do advocates champion the cause within their organizations? Most of the reported justifications are qualitative, but a quantitative case can also be made to justify investment.

Drivers of the change in companies already pursuing a more rigorous approach to development were varied:

  • Desire to support an outsourced IT model with more rigorous analysis by internal resources
  • Sponsorship at a senior leadership level
  • Need to backfill for an aging employee population
    (demographic trends)
  • Recognition that the requirements development process needs improvement
  • Adoption of new tools such as business rules engines

In some cases, a more financially based approach may be necessary to motivate investment. One method is to approximate the dollar value that is dependent on quality BA execution to deliver the full benefits estimated for a project delivery.

For example, assume the net benefit from a system build and implementation is US $6.25million. Using a typical life cycle framework (SDLC), estimate the percentage of the total work effort attributable to each phase. Multiply this phase percentage by the total benefit to arrive at a benefits-by-phase accrual. Then estimate the BA contribution percentage for the each phase. Multiply the BA contribution percentage for each phase by the benefit contribution for that phase, and the result is the BA dollar contribution by phase.

The BA contribution is highest in the requirements phase (80%), and very important in acceptance testing (65%) and implementation (50%) efforts. Using these assumptions, the model calculates that 41% of the total benefit of the entire project depends on the performance of the BA resource on the project ($2,546,875 / $6,250,000). The costs of a BA development program compare very favorably to the income from only a single project.

Conclusion

Successful transformation efforts will invest in the skill development of business analysts. The bad news is that this function has historically not received the attention it warrants. The good news is that there are companies with formal, disciplined programs that are in their second or third year of operation and are beginning to deliver results.

If improved delivery of transformation initiatives is part of your company’s strategy, Celent recommends that you:

  • Identify a senior leader to champion the effort of business analyst development.
  • Establish a certification program for business analysts in the next three months; get the program up and running immediately and perfect it later.
  • Pay for any registration and exam fees for employees pursuing the certification.
  • Implement bonus award recognition for employees who successfully complete the certification.
  • Commit to a goal: If there are no certified BAs in your organization, commit to completing certification of 5% of the BA population in the next year; if there are employees certified, issue a challenge to the company to double the number in the next six months.
  • Create a professional career path for BAs; if feasible, establish a. AVP or VP level business analyst leadership position.

If your company is investing in BA development, redouble your efforts and maintain your lead. If it is not, it is time to begin.                                                                                   


Mike Fitzgerald is a senior analyst in Celent’s (

www.celent.com) insurance practice and is based in the firm’s Chicago office. He has particular expertise in property / casualty automation, operations management and insurance product development. His research focuses on underwriting and policy administration, business process and operations, billing, and project / program management. Prior to joining Celent, Mr. Fitzgerald was Vice President of Enterprise Underwriting Solutions of Zurich North America, where he led the evaluation of technology alternatives to support a new underwriting product development process. He was a business architect at HCL Technologies America, and held a number of positions at Royal & Sun Alliance, including a regional operations executive role.  Mr. Fitzgerald began his career as a business analyst. Mr. Fitzgerald has a B.A. in economics from Davidson College in North Carolina and an MBA from the Fuqua School of Business at Duke University in North Carolina . He is a Chartered Property Casualty Underwriter and a certified Project Management Professional. He can be reached at [email protected]