Author: Cynthia Low

The Strategic Role of the Business Analyst

Written by Cynthia Low on March 2, 2008. 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 March 2, 2008. 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 Impact of Business Requirements on the Success of Technology Projects

Written by Cynthia Low on February 15, 2008. 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.

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:

Companies with poor business analysis capability will have three times as many project failures as successes.
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.
Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
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.
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:

80% 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

Road to the Perfect Project Part 3

Written by Cynthia Low on February 15, 2008. Posted in Articles.

Limit Formal Process

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

The biggest problem with this approach is that all the process is, at its heart, intended to do is allow average quality staff to reliably deliver “acceptable” systems. And most of the time it delivers. Now, if all you want is an acceptable (read mediocre) system, then by all means go for it. For big process to work properly the project team should come onto the project already immersed in the company’s methodology based on actual prior experience with it. A very real problem with this approach in the government contracting world is that the development contractors do not keep stables of ready and willing people who have been deeply immersed in the company’s methodology on prior projects. When they win a contract they go out and hire mostly new people for the project, who then have to go through a long period of training and adjustment to the company’s methodology.

Big process tends to force big project size – and big project cost. Typically there exist separate sub-organizations for requirements management, systems engineering, software engineering, development, testing, configuration management, quality control, risk management, etc. And all of that process increases the amount of work (much of it administrative in nature), and also increases the communication load on the project. On a project with a smaller team, much can be done via informal channels where formal process would be needed in larger projects. Proper choice of support tools can improve productivity, and those tools come with built-in process. So using them gives you desirable best practice methodology without the need for separate formal written processes to deal with.

The primary uses for project documentation are (a) to allow the system to be developed and fielded, and (b) to support post-implementation system maintenance. I recommend limiting formal documentation to that which is truly needed. I believe a project needs a high quality set of formal system requirements, and a matching system test plan. Some level of design documentation is needed, with the higher level design being more important than the more detailed design. Depending on system complexity as well as security needs, other documents will be necessary. I believe it becomes a waste of money to continue to maintain anything but the highest level documents for purposes of system maintenance. Below a certain level of documentation needed for orientation purposes, maintenance people assume (largely correctly) that the documentation is out of date, and in any event they often prefer to just directly go to the code.

Exhibit Agility

Given that other conditions are extant, namely there is a small project; it is staffed with a solid leadership team; the project team is in a partnership mode with its customer; and the project is not overburdened with formal process, it becomes possible to take the final step to achieving the perfect project. The two most successful projects I have personally been involved in met these criteria, but also exhibited characteristics that now are associated with what is known as the Agile Methodology. The essence of “Agileness” is the ability to let things flow freely, and to operate intuitively versus slavishly following a rigid set of rules. It requires a high tolerance for ambiguity, and a willingness to quickly change direction, perhaps even radically. The team has to be fast on its feet.

Agility can be exhibited in any manner of ways. From the perspective of the project manager, that person may express agility in being able to rapidly shift assignments, based on knowledge of their subordinate team member’s individual experience and capabilities. This might be in response to a technical roadblock, a customer shift in priorities, or loss of a staff member. An individual analyst may need to multiplex multiple assignments, and be willing to instantly shift what they are doing based on project needs of the moment.

Agility also means thinking out of the box about how things are done. Consider system requirements. While I am a big believer in starting out with a solid set of formal requirements, one has to understand that those requirements are just an initial guess at what the system’s users truly need. It is right and proper to put together an early version of the system based on those requirements. But early pre-release user exposure will almost certainly identify various needs for adjustment. There may even be a need for significant rework. The agile team will, quickly and gracefully, make accommodation for them, even if major rework is needed. The users will deeply appreciate it. But at some point, typically after the first system release (but perhaps even earlier), it will make sense to just abandon those original requirements, and any attempt at traceability to them. The agile team then goes into change management mode and allows the system to morph into whatever it wants to become, as user complaints and suggestions for improvement pour in.

Not everyone is capable of what I used to call “go with the flow development”, and not every customer will allow it, but a project team that is able to operate intuitively can produce absolutely spectacular results.

John L. Dean is a seasoned IT professional with 40 years of varied experience, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and is currently an independent consultant. He has a Masters degree in Operations Research from Clemson University. John is the “Project Whisperer”. His depth and breadth of experience gives him an unusual perspective on what does and does not work. If your project is running you, he can use his experience and intuition to diagnose why and apply calm, assertive energy to start corrective action, so you can and regain control! He can be contacted at [email protected].

Leaping Ahead in the New Year

Written by Cynthia Low on January 31, 2008. Posted in Articles. 1 Comment on Leaping Ahead in the New Year

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

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

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

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

All the best.

Adam R. Kahn
Publisher
Ph: 508-309-6900
Email: [email protected]