Skip to main content

The Strategic Role of the Business Analyst

Written by Cynthia Low on . Posted in Articles. 1 Comment on The Strategic Role of the Business Analyst

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

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

As organizations shift to become “projectized,” the roles and responsibilities that have supported projects within a traditional matrix structure must shift as well.  Over the years we have seen organizations struggle with the following challenges related to shifts in both structure and culture:

  • Broken or disjointed cross-functional communication channels
  • Uncertainty around roles and responsibilities within the project structure and beyond
  • Quality concerns at the point of project delivery
  • Skewed scope statements and thus implementation plans due to early stage breakdown
  • Overall loss of productivity on project teams due to lack of continuity and methods

The items noted above are telltale signs that several strategic components of a best practice project management environment are missing.

Forward looking or “best in class” organizations have aggressively embraced the concept of the BA role.  And, what sets them apart from the old school thinking associated with this job title is the escalation and expansion of the roles, definition and responsibilities.  Not too many years ago a BA may have been confined to a very technical role within an IT environment working on specifications, functionality and even some quality and testing related to one or more project life cycles.  Today, we are seeing BA positions filled from across the organization and expect that this trend will continue, as it should.

Let’s address these points built in the context of how they can be leveraged to meet the challenges:

Broken or disjointed cross-functional communication channels
A BA should be in front of any project communication produced from the point of team inception to the close-out phase.  This interaction does not mean that the BA takes on the role of project manager (although we have seen organizations combine the two roles), as it is not effective on larger and longer term initiatives.  Our experience shows that an independent BA position can help to promote better communication, align protocol and help the project manager to extend his/her reach into the project teams.

Uncertainty around roles and responsibilities within the project structure and beyond
The BA functions as a tour guide through the project plan ensuring that all of the moving pieces are touching at the right points.  We call these critical communication points and they can be built around time, budget or deliverable expectations.  The BA will be assigned a protocol map within the project structure to enable them better access to expectations and provide for a proactive way to reach team members.

Quality concerns at the point of project delivery
In reality, the BA is monitoring quality points through the project life cycle thus producing a quality product at the close of the project.  Very much like the thinking around proactive quality control, the BA is in front of each deliverable and monitors the progress against the project plan. This allows for immediate communication between the project manager, customer and associated teams.

Skewed scope statements and thus implementation plans due to early stage breakdown
The planning stages of a project are obviously critical to the implementation plan and ultimate quality.  A BA should be assigned early in the process and work hand in hand with the project manager to ensure the highest level of intimacy with the plan.  And, just as importantly they need to have a direct connection to the internal and external customers in order to ensure collaboration and proactive attention to emerging issues.

Overall loss of productivity on project teams due to lack of continuity and methods
A strategic BA assists the project manger and PMO with the execution of best practice within an organization’s project management structure.  The BA has a unique opportunity to guide the process through an existing methodology and essentially help the project to operate in better alignment.  This is accomplished by having a dedicated individual who is consistently working against the deliverables and is not distracted by the operations management associated with the project manager’s job.

By taking the above steps you have begun the shift toward the organizational structure needed to take advantage of the BA position.  With that said, we still have one more change to make in order to secure success.

It is obvious that the BA role as defined in this article will require wider skill sets than the more traditional BA position still driven from the IT departments of yester year.  To that point we have begun to see a trend where the BA position can spawn from either business or IT.  This is an interesting point as it speaks volumes to an organization’s maturity around project management.  Imagine, for just a moment, an organization that has no boundaries within in its functions and everyone on the team collaborates against a common goal.  I like to call this organizational desegregation and cultural morphing.  As we begin the next phase of benchmarking the project management industry and clients, we are beginning to see this shift as a representative of the next wave of advancing thought in the project management space.  It was not too many years ago that I published an article on the emerging role of the project manager as the CEO of his/her project.   I am confident that the BA role will take a firmly positioned spot in the upper hierarchy of any world class project organization within the next few years.

In order to succeed the BA will need to have a competency profile that meets the following criteria:

  • Excellent understanding of both business and technology within the project environment.
  • Be a leader, communicator and professional.
  • Understand the skills associated with internal consulting techniques.
  • Be proficient in project management skills as well as complete understanding of the internal process.
  • Epitomize the essence of a collaborator and team player.
  • Understand and be able to navigate your organization’s politics and structure.
  • Be able to manage, without having authority, via negotiation.
  • Understand true stewardship-based service.

So, the BA role probably looks a little different than a traditional structure may have dictated.  Yet, this is the trend and I believe will become the norm.  As organizations look to enhance productivity and quality while reducing cost they are finding this role to be ultimately important.  Additionally, project managers we spoke to during the research for this article all stated that having a BA on the team made their job easier and allowed them to focus on deliverable based activity.

It is important to note that this type of structure is recommended for mid to large size projects, but on the smaller initiatives we found that these attributes were part of the project manager’s role.

Phil Ventresca, MBA is Founder, CEO and President of Advanced Management Services, Inc. (AMS), http://www.amsconsulting.com/, a full service management consultancy servicing an international client base.  Phil has utilized his extensive background in management and consulting to lead AMS to its current status as a multi-million dollar enterprise with an international customer base.  He has led the organization to recognize several strategic breakthroughs such as developing partnerships with distance education providers, software developers and publishers.  Through these efforts, AMS has emerged as a leader in consulting, training and assessment services.

His entrepreneurial spirit and keen business insight has benefited many organizations through his consultive engagements with clients such as Boston Edison, ADP, State Street Bank, Cabot Corporation, Merisel, Data General, Simplex, AT&T, BIC, Bank of Montreal, Kronos and others. Phil is an adjunct faculty member at Boston University’s Division of Extended Education. He is responsible for the development and delivery of a project management curriculum to varied international client base as well as a contributor to a unique leadership development program. Phil can be reached at [email protected] or 781-828-8210.

Struggling to Define Business Analysis and the Role of the BA.

Written by Cynthia Low on . Posted in Articles.

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

I came across an interesting article forwarded to me by some information architecture friends. The article on the discipline and role of Information Architects (IAs) was written by Jesse James Garrett in 2002 and the issue of defining the roles of information architects that they were struggling with back then, are very familiar issues that we are now facing as BAs. If you enter the phrase “defining the damn thing” in Google you can still find remnants of that debate.

Garrett argued that there is a discipline known as information architecture as well as a role known as information architect and that they evolved hand in hand, but that the time had come for change. Similarly, just as there is the discipline of business analysis, there is the role of the business analyst.

If we define the discipline based on the role then we may potentially be too broad, as the role of a BA varies from organization to organization and encompasses BAs working as commercial, process, financial, technical and systems analysts. Organizations representing business analysts are looking to certification or accreditation as a way of defining the role, and bringing in some level of standardization in order to decrease ambiguity in the marketplace. Garrett, however, cautions that if we go down the track of defining the role we inevitably threaten someone’s sense of identity. If the BA’s role differs from the organization’s job description, then does it follow that they are not business analysts?

Alternatively, if we define the role based on the discipline, then whatever the field of business analysis is, those who are specialists in this field are business analysts. This definition however could, in practice, become too narrow. The potential to be “boxed in” may result in BAs having little influence or control over important aspects of projects, where BA competencies and capabilities are of great value and add strategic value to organization goals and objectives for process improvement.

As a BA I’m more often involved at a strategic level.  Rather than my involvement with projects ending with the delivery of requirements, I’m utilized throughout the project: I bridge the gap between the business and the technology team; review processes and operations; as well as investigating and advising on the project’s impact and dependencies on other systems and programs initiatives across the enterprise.

All this activity means my role is not easily defined. This is not because I’m trying to be all things to all people (the Project Manager, the Business Analyst and the Systems Architect) or take over another project team member’s role, its more a reflection of the discipline of analysis being increasingly seen as a core capability and that the frameworks and tools used for analysis can be drawn upon for expertise throughout the life of the project, and through all the programs across the enterprise.

In short, as a business analyst I do lots of things. Don’t put me in a box or label me and don’t predefine what I do … it limits the possibilities for my involvement to add value within projects, between projects, across programs and across the enterprise.

Garrett suggests that we seem to be at an impasse in the definition debate:

 “Any definition broad enough to encompass the role is too broad to foster useful discussion of the discipline; any definition narrow enough for the discipline is too narrow for the role….basing either definition on the other means one is going to be insufficient. Trying to do both at once isn’t working, producing a classic chicken-and-egg problem”.

This is where our business analysis “Community of Practice” can come together to shape the future of the profession. We should define the scope of what is business analysis as a discipline. Once we achieve this end, this will empower us to look at what the discipline offers in the way of frameworks and tools to interested practitioners, as the specialists in this field.

Ultimately, the definition, role, responsibility, and the future of BAs will be determined not by us, but by organizations that will base their decisions on their resourcing needs. It is therefore up to us as a Business Analysis Community to continue to promote what we do and how we do it, and share our knowledge, understanding and expertise within the community. By doing this as a community, we can go out to organizations and showcase the capabilities and competencies of business analysis. This will show the value of the discipline regardless of the role within the organization.  Instead of prescribing what a business analyst is or isn’t, let’s talk about our frameworks, our theories and what tools are out there to get the job done.

Maria Murphy is an experienced business manager and information and communications specialist. She has over 10 years senior management experience within the commercial environment, medical/pharmaceutical industry, not-for-profit organizations and government. She has experience with managing large federal government contracts and project management of large scale ICT business system reviews, development of requirements, systems planning and change management.

Maria is the Regional Lead for a Business Analysis at SMS Management and Technology and provides advice to her colleagues on developing requirements specifications for appropriate IT systems to support clients’ programs and initiatives. She can be reached at [email protected].

The Hard Skills Precede the Soft Skills for BAs

Written by Marcos Ferrer on . Posted in Articles.

You may have noticed that I value soft skills (BA Fundamentals) very highly. The ability to work with (and at the highest levels, influence and negotiate with) people is a key success factor for senior BAs that the CBAP test cannot measure directly, but the world will always measure first.

I call on IIBA education providers to step up to this challenge – people classes are harder to do well, and look pretty flaky when done well, but they work (witness Dale Carnegie’s ongoing success, in spite of their “flaky” program).

In the meantime, soft skills without BA hard skills do not result in good BA practice. Promotions, recognition, a chance to jump to the next project before the first has collapsed, yes. Good BA practice, no.

This month is pure hard skill (thanks to blogger John Dean last month for an excellent presentation of the “sky level” overview of the problems I am presenting, and the importance of solving them).

In prior months we looked at a stakeholder type of breakdown (i.e., a top down analysis). We got individuals, businesses, governments, non-profit/non-government, and a sense of what they wanted (hire, do business, enforce the law, etc.).

There were still too many questions (what do you do if DNA is planted at a crime scene?) and too many gaps in understanding (all stakeholders need to identify employees when they hire them – what is the same, what is different).

The proposal for a new technical approach (i.e., in this case a bottom up analysis) is to move away from stakeholders for the moment, and consider actual identity transactions. Then we will see if any structure suggests itself when we consider the detailed transactions (did I say bottom up?).

There is no easy precedent for this analysis: it is huge. If anyone can suggest a technique for organizing the following list, I will try it out next month. Otherwise, I will do what I want, so there!

Here is one brainstorm – by the way, I think I’m smarter than my readers – prove me wrong!

How well does your brain compare with mine – what important transactions did we miss? What are the categories or structure we can use to organize this unruly list?

Identify a qualified BA (the CBAP is the current standard – are you helping to set it)?

  • Cross a Hostile Border
  • Cross a Welcoming Border
  • Cross a Border at some level of gradation in between (is there any set of statuses that is simpler than the exponential combinations of relations between individual countries)?
  • Identify a friend in person Identify a friend remotely Identify an enemy in person
  • Identify an enemy remotely
  • Identify family for daily stuff
  • Identify family for inheritance stuff
  • Identify the owner of an object
  • Identify the owner of non-physical property
  • Identify DNA at a crime scene
  • Identify the actual criminal regardless of DNA, which is portable
  • Paternity
  • Maternity (an issue for modern procreation, no doubt)
  • Buy candy
  • Buy cigarettes or alcohol
  • Buy medical marijuana
  • Buy stocks
  • Set up a trust
  • Create a will Identify a conspiracy group
  • Perform Identity theft
  • Counter Identity theft
  • Perform successful witness protection
  • Hide from an abuser
  • Identify an abuser
  • Control or prevent spam, viruses, worms, spyware, etc.
  • Hire a janitor
  • Hire an FBI agent
  • Hire a fast food worker
  • Hire a dockworker
  • Hire a government worker
  • Hire a CEO
  • Hire a doctor/nurse/health provider/hospital
  • Hire a CIA worker
  • Hire a CIA spy
  • Hire a black budget spy
  • Hire a president, congressman, etc.
  • Hire a police officer, detective, TSA screener
  • Buy weapons at a swap meet
  • Trade weapons for drugs on the street
  • Obtain permit to own a weapon
  • Obtain permit to carry a concealed weapon
  • Obtain permit to use a weapon in public with backing from law enforcement (this is NOT just cops)
  • Give blood
  • Give sperm
  • Adopt a child
  • Put a child up for adoption
  • Be convicted of a crime
  • Be acquitted of a crime
  • Be left in limbo re: a crime (mistrial, hung jury, never charged, never caught) omigod.

What are the categories, if any?

What did I leave out (participate in a one night stand? – follow-up one night stand if VD is detected?).

If you can’t think about this, you may be struggling with what you are working on – test yourself! ©

©2008 Marcos Ferrer

Fill-in-the-blanks: A Process / Content Framework

Written by Terry Longo on . Posted in Articles. 1 Comment on Fill-in-the-blanks: A Process / Content Framework

If you’ve read the previous entries in this blog, you have seen that we’ve been building up to something, and this new entry will hopefully bring us to our first conceptual plateau, upon which there is much more to build.

What we’ve done so far is to reorient our view of requirements and the BABOK, by going from this (based on BABOK 1.6):

Fill-In1.gif

to this (based on IIBA guidance on BABOK 2.0 direction and the concepts from the three previous blog entries):

Fill-In2.gif

Following the previous blog entry about content vs. process, we are naturally led to the above structure which manifests that distinction and also provides a framework within which we can indicate the appropriate methods, tools, techniques, and standards for the corresponding process phase, within the corresponding language domain.

For example, in the Software Development x Elicitation cell, we would typically find UML, prototyping, consideration of legacy systems, etc.; while in the Enterprise e-Learning Infrastructure x Elicitation cell, we might find multimedia complexity requirements analysis, consideration of training data privacy laws, task analysis, etc.

This view brings up some interesting questions about

  • Ownership of the process itself (process design, continual improvement, and governance)
  • Whether this view contributes to or hinders senior management’s ability to obtain a dashboard view of the benefits, costs, and risks related to current requirements management efforts
  • The potential benefit to the enterprise as a whole should this view be adopted by managers and individual contributors involved in managing or meeting requirements

We’ll tackle one of those in the next entry. Meanwhile, I, and I am certain your colleagues, would love to hear your comments.

The Impact of Business Requirements on the Success of Technology Projects

Written by Cynthia Low on . Posted in Articles. 1 Comment on The Impact of Business Requirements on the Success of Technology Projects

Findings Review

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

The Business Analysis Benchmark Report presents the findings from surveys of over 100 companies and definitive statistics on the importance and impact of business requirements on enterprise success with technology projects. The survey focused on larger companies and looked at development projects in excess of $250,000 where significant new functionality was delivered to the organization. The average project size was $3 million. The study has three major sections:

  • Assessing the Impact of Poor Business Requirements on Companies. Quantifying the cost of poor requirements. 
  • Diagnosing Requirements Failure. A benchmark of the current capability of organizations in doing business requirements and an assessment of the underlying causes of poor quality requirements 
  • Tactics for Tomorrow. Specific steps to make immediate organizational improvement.

In addition to the full text report, these sections have also been published as stand-alone white papers for ease of use. All can be accessed from www.iag.biz. 

The study provides a comprehensive analysis of business requirements quality in the industry and the levers for making effective change. The following issues are addressed in the report: the financial impact of poor quality requirements; the information needed to identify underlying issues critical to success; and, the data necessary to target specific recommendations designed to yield performance improvement.

The report finds two basic scenarios for companies:

a) Scenario 1: Project success is ‘Improbable’. Companies might be successful on projects, – but not by design. Based on the competencies present, these companies are statistically unlikely to have a successful project. 68% of companies fit this scenario.
b) Scenario 2: Project success is ‘Probable’. Companies where success can be expected due to the superior business requirements processes, technologies, and competencies of people in the organization. 32% of companies fit this scenario.

Impact1.gif

Almost everyone understands that requirements are important to project success. The data above demonstrates that, while people understand the issue, they did not take effective action in almost 70% of strategic projects.

Effective Business Requirements are a process – not a deliverable. The findings are very clear in this regard – companies that focus on both the process and the deliverables of requirements are far more successful than those that only focus on the documentation quality. Documentation quality can only assure that investment in a project is not wasted by an outright failure. The quality of the process through which documentation is developed is what creates both successes and economic advantage. To make effective change, companies must rethink their process of business requirements discovery.

The following are a few key findings and data from the study:

  1. Impact2.gifCompanies with poor business analysis capability will have three times as many project failures as successes. 
  2.  68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of: 
    • Taking over 180% of target time to deliver. 
    • Consuming in excess of 160% of estimated budget. 
    • Delivering under 70% of the target required functionality. 
  3. Impact3.gifCompanies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects. 
  4. Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization. 
  5. The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.

Almost 70% of companies surveyed set themselves up for both failure and significantly higher cost in their use of poor requirements practices. It is statistically improbable that companies which use poor requirements practices will consistently bring projects in on time and on budget. Executives should not accept apathy surrounding poor project performance – companies can, and do, achieve over 80% success rates and can bring the majority of strategic projects in on time and on budget through the adoption of superior requirements practices.

Making Organizational Improvement

The survey findings made it clear that there is no single silver bullet for making organizational improvement. CIOs must look at making improvement across all the areas of people, process, and tools used to support processes to gain organizational improvement. Only a systematic change to all areas of people, process and enabling tools yields material improvement. 80% of projects from the companies which had made these broad-based changes had successful projects.

The findings of the Business Analyst Benchmark describe both the poor state of the majority of companies surveyed, and, a path to performance improvement. To assist the executive reader, this report also analyzes the data for alternative actions which could be taken to make improvement to separate myth from actions that create benefit. The top three findings in this area can be used to change business results: 

  • Impact4.gif80% of projects where successful from companies with mature requirements process, technology and competencies. 
  • Auditing three 3 specific characteristics of business requirements documentation and forcing failing projects to redo requirements will eliminate the vast majority of IT development project failures. 
  • Elite requirements elicitation skills can be used to change success probabilities on projects.

These above survey findings and the underlying statistics are described in detail within the report. Overall, the vast majority of companies are poor at both establishing business requirements and delivering on-time, on-budget performance of IT projects. Satisfaction with IT and technology projects wanes significantly as the quality of requirements elicitation drops. This report is both a benchmark of the current state of business analysis capability, and, a roadmap for success.

The Bottom Line

The challenges in making quantum improvement in business analysis capability should not be underestimated. Organizations understand conceptually that requirements are important, but in the majority of cases they do not internalize this understanding and change their behavior as a result. The most successful of companies do not view requirements as a document which either existed or did not at the beginning of a project, they view it as a process of requirements discovery. Only companies that focus on both the process and the deliverables are consistently successful at changing project success rates.

For companies that have made the leap to the use of elite facilitation skills and solid process in requirements discovery there are significant benefits. Not only were these projects rarely unsuccessful, these projects are delivered with far fewer budget overruns and in far less time. The report describes the use of poor requirements process as debilitating. Using this word is perhaps unfair, since companies do not collapse as a result of poor quality analysis. In fact, IT organizations and the stakeholders involved will overcompensate through heroic actions to attempt to deliver solid and satisfactory results. However, ‘debilitating’ is an accurate word to describe the cumulative effect of years of sub-optimal performance in requirements analysis when results are compared to competitors who are optimal. Even leaving out the effect of high failure rates and poorer satisfaction with results, the capital investment in information technology of the companies with poor requirements practices is simply far less efficient than companies that use best requirements practices.

To illustrate this inefficiency of capital expenditure on technology at companies with poor requirements practices, use the average project in this study ($3 million):

  • The companies using best requirements practices will estimate a project at $3 million and better than half the time will spend $3 million on that project. Including all failures, scope creep, and mistakes across the entire portfolio of projects, this group will spend, on average, $3.63 million per project. 
  • The companies using poor requirements practices will estimate a project at $3 million and will be on budget less than 20% of the time. 50% of time, the overrun on the project both in time and budget will be massive. Across the entire portfolio of successes and failures, the companies with poor requirements practices will (on average) pay $5.87 million per project.

The average company in this study using poor requirements practices paid $2.24 million more than the company using best practices.

If overruns are common at your company, or if stakeholders have not been satisfied with more than five of the last ten projects larger strategic projects, there is definitely a problem and your company is likely paying the full poor requirements premium on every project.

Keith Ellis is a Vice President at IAG Consulting, specialists in eliciting and managing business requirements for technology initiatives. Mr. Ellis was co-founder of the elicitation company Digital Mosaic (merged with IAG in 2007) and has extensive experience in technology research, business analysis issues. He regularly publishes articles, white papers and other research findings in these areas. Mr. Ellis can be reached at (905) 842-0123 x228. Email IAG by accessing www.iag.biz and selecting contact us or call our North American Toll Free line: 800-209-3616