If you receive errors when attempting to view this white paper, please install the latest version of
Adobe Reader.
"On our engagements, IAG consultants use a consistent approach to
requirements definition and management that is a
key reason for our achieving superior work products and successful project and business outcomes for our clients.
The bottom line is faster results with higher quality and a better overall return on investment."
Source : IAG Consulting
Diagnosing Requirements Failure: A Benchmark Report
Requirements Failure is also known as :
Benchmark Report,
Benchmark Report Home,
Reports Compare,
Benchmark Report Work,
Reports the Findings,
Performance Benchmark Report,
Collaboration Benchmark Report,
Benchmark Report on Professional Services,
Software Vendor Benchmark,
First Benchmark Report,
Benchmark Results Scanner,
Report Measures,
Index Benchmark Report,
Benchmark Report Sample,
Lean Supply Chain Benchmark Report,
Gap Benchmark Report,
Benchmarks Project Report,
Spending Benchmarks Project Report,
Benchmark Report Introduction,
Product Design Benchmark Report,
Engine Marketing Benchmark Report,
Supply Chain Benchmark Report,
Report Benchmarks Key Metrics,
Customized Benchmark Report,
Documentation Benchmark Report,
Report Benchmark Data,
Risk Benchmark Report,
Systems Benchmark Report,
Benchmark Report Improving,
Benchmark Report Targets,
Design Benchmark Report,
Best Workplaces Reports,
Captive Risk Benchmark Report,
Report Lists Performance,
Reputation Benchmark Report.
Executive Summary
This report presents the findings from surveys of over 100 companies and presents definitive
findings on the importance and impact of business requirements on enterprise success with
technology projects. The survey focused on larger companies and included an average project
size of about $3 million.
This white paper is one of three extracts of the study: Business Analysis Benchmark, the Impact of
Business Analysts on North American Business, and Technology Projects. This volume focuses on
uncovering why businesses fail to do a good job on business requirements. There are two parts
to the report:
- Benchmarking the current state of organizations and their capability in completing
business requirements
- Diagnosing organizational and project risk factors to determine effective risk control
measures for project managers.
Major conclusions of this study include:
- Over 50% of organizations surveyed do not have even basic pieces in place to be
successful at business and software requirements
- 70% of organizations do not have the fundamental competencies within business
requirements discovery to consistently bring in projects on time and on budget.
- Companies can achieve success rates in excess of 80% on a consistent basis. The
greater the organizational focus on the combined aspects of business requirements
(people, process and enabling tools), the better the expected project outcome.
- The focus of companies must shift to the quality of Requirements Discovery as a process
and away from "Business Requirements" as a thing that either happened or didn't at the
beginning of a project if they hope to consistently deliver successful projects.
Perhaps the most critical findings of this report: Point changes to organization and deliverables
don't yield meaningful change to results in and of themselves. Only when elements associated
with the process of requirements discovery are considered in combination with these other
organizational elements is meaningful change to performance realized. It is this finding that
leads IAG to conclude that many companies simply do not visualize business requirements as,
first and foremost, a process rather than a document. The focus of companies must shift to the
quality of Requirements Discovery as a process and away from "Business Requirements" as a
document that was either completed not at the beginning of a project if they hope to
consistently deliver successful projects.
Diagnosing Organizations
Most organizations surveyed were larger corporations which have an inherent level of
complexity which may not be experienced by very small companies. The IAG survey focused
on companies spending in excess of $250,000, with the average project surveyed being
$3,000,000. This type of project is strategic to the company, and the findings would be
applicable to the larger projects of a mid-sized company, or many projects of a very large
multinational.
Further demographics:
- Median number of people impacted by the solution: 250. Because of some very large
projects, the average is skewed to ~1,300
- The median number of stakeholders involved in defining requirements: 15. Again,
because of some very large projects the average is skewed to 35.
- Nearly 70% of companies have more than 5 locations or are multinationals
These results are descriptive of Fortune 1000 companies or the very large projects of mid-size
companies within North America.
In general: most organizations are not well set up to be successful in getting business
requirements right ' over 50% of them do not have even basic pieces in place to be successful
at business and software requirements and 70% of organizations do not have the fundamental
competencies within business requirements discovery to consistently bring in projects on time
and on budget.
The chart to the right
illustrates a significant
underlying problem:
- The red line
indicates the
average
competency
score for
organizations
that were +/-
10% on budget
and time for
projects was 70
(read from the
horizontal axis).
The blue line
indicates the proportion of organizations that have the given skill level meaning that only
30.8% of organizations have this skill or roughly 70% of organizations lack the requirements
discovery competence needed to deliver predictable project success.
- 40% of organizations have significantly less competency than is needed for predictable
success (1 standard deviation is the left edge of the blue shaded are). These
organizations will have significantly more trouble bringing in projects on time and on budget. In fact this group fails 3 times more often than succeeds and reports an
average budget overrun of 195%.
Source: IAG Business Analysis Benchmark, 2008
The findings here map closely to Scenario 1 and Scenario 2 findings presented earlier.
Business Implications in the Data
Having a competency score of 70 is critical to predictable IT performance. There is the further
implication that if an organization is consistently better than most of their competitors in this area,
there should be a noticeable performance difference in the company as a whole versus its
competitors. Capital dollars in information technology for Scenario 2 companies are simply
better allocated.
Companies should realize that the competency bar for achieving sustained performance
difference is quite high. This performance gain is not realized by simply implementing a tool, or
training analysts for a few weeks. Achieving change will require a holistic approach to
developing people and processes. The level of effort and investment needed should not be
underestimated.
Snapshot of the Current State of Organizations
The data table below shows that more than 50% of companies do not have professional, trained
staff dedicated to the function of getting requirements, and the vast majority view the process
of getting requirements to be inefficient. In general, the current state of capability in
organizations in requirements discovery is poor.
| Snapshot of the Organization: Do you agree with the
following? |
Per Cent of
Respondents
that Agree with
Statement |
| Business requirements are traceable, and well integrated into testing at our organization |
47% |
| Our organization treats business analysis as a profession and has trained staff dedicated to
this function |
46% |
| Our organization has a formalized approach to doing business requirements which is
consistently followed by business analysts on projects |
42% |
| Our organization is excellent at transitioning requirements from business departments into
the information technology department |
36% |
| Our organization has defined standards for business requirements documentation quality, and
assess the work of analysts against these standards on projects |
34% |
| Our organization can predict how much stakeholder time will be needed, and which
stakeholders will be involved in the requirements phase of a project |
33% |
| Stakeholders feel that the process of extracting and documenting requirements is efficient at
our organization |
29% |
Source: IAG Business Analysis Benchmark, 2008
One observation about the above table: IAG believes that it is unlikely that so many
respondents had traceability through testing. Probably this should be interpreted as "47% of
respondents use the requirements documentation in testing". To achieve traceability (what
requirement is linked to which process and strategic objective of the project, AND, assuring that
the code delivered matches up to the requirements) a fairly high quality requirements document is needed and the data clearly indicates that companies are not producing the
requisite quality level.
In another interesting observation, IAG's analysis found that not one of these organizational
improvement variables is individually highly correlated with successful project outcomes. In the
table below, only the top two variables stand out as something a CIO could implement on a
stand-alone basis and expect to get improvement on individual projects as an outcome. In the
Tactics for Tomorrow section (following), IAG will review these two areas in more detail.
| Area of improvement |
Correlation
1 is perfect
0 is no relationship |
| Our organization has defined standards for business requirements documentation quality, and
assesses the work of analysts against these standards on projects |
0.38 |
| Stakeholders feel that the process of extracting and documenting requirements is efficient at our
organization |
0.32 |
| Our organization treats business analysis as a profession and has trained staff dedicated to this function |
0.25 |
| Our organization has a formalized approach to doing business requirements which is consistently
followed by business analysts on projects |
0.24 |
| Our organization can predict how much stakeholder time will be needed, and which stakeholders will be
involved in the requirements phase of a project |
0.23 |
| I believe the automated business analysis tools that we currently have in place are excellent at helping us
manage requirements and requirements change |
0.23 |
| Our organization is excellent at transitioning requirements from business departments into the information
technology department |
0.21 |
| I believe the automated business analysis tools that we current have in place are excellent at helping us
elicit requirements |
0.20 |
| Business requirements are traceable, and well integrated into testing at our organization |
0.17 |
Source: IAG Business Analysis Benchmark, 2008
The conclusion from the above: 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. It is an almost a linear
progression ' the greater the
organizational focus on the
combined aspects of business
requirements (people, process
and enabling tools), the better
the expected project
outcome. We describe this
approach of focusing on all
areas of business requirements
"Integrated Investment" and
show the project success ratios of 4 groups from lowest to highest in the chart above. Every increase in the level of investment
brings about a meaningful result.
Significance: a difference will be found in performance 99.97 times in 100
Source: IAG Business Analysis Benchmark, 2008
Business Implications in the Data
This data demonstrates that point changes made to organization and deliverables doesn't yield
meaningful improvement. Only when the process is considered in combination with these other
items is meaningful improvement to performance realized. It is this finding that leads IAG to
conclude that companies simply do not visualize business requirements as, first and foremost, a
process rather than a document. The focus of companies must shift to the quality of
Requirements Discovery as a process and away from "Business Requirements" as a thing that
either happened or didn't at the beginning of a project if they hope to consistently deliver
successful projects.
Organizing Business Analysts ' Uncovering the Myth of Business Requirements
Leadership
Who should have primary responsibility for business requirements ' non-IT business management
or Information Technology? The question is essential to knowing how to effectively organize
business analysis skill sets and position them optimally into an organizational structure. IAG asked
which area had primary responsibility for business requirements, and looked at how successful
each group was in bringing applications in on time, on budget and on target function.
The data here was insightful:
- Non-IT business analysts: On average, applications based on analysis by non-IT business
professionals came in at almost 200% of budget and over 245% of time, while delivering
beyond the original functionality specification.
- IT-managed requirements analysis: Generally performed better on budget and time
than the non-IT business analysts, but delivered less functionality than was expected by
the business.
- Jointly owned requirements analysis: This was found to be the optimal approach, with
the lowest overall time and budget expenditure and generally on-target application
delivery.
| Who Owned Primary
Responsibility for
Requirements? |
Budget
% of target |
Time
% of target |
Functionality
% of Target |
Stakeholder
time
% of Target |
| IT Organization |
162.9 |
172.0 |
91.4 |
172.9 |
| Non-IT Business |
196.5 |
245.3 |
110.1 |
201.3 |
| Jointy Owned |
143.4 |
159.3 |
103.7 |
163.4 |
Source: IAG Business Analysis Benchmark, 2008
The characteristics of each grouping suggest that the 'process of requirements' changes
depending on which organization is has primary responsibility for the activity. This process
change is positive when business requirements are considered a joint activity involving the
business, and negative when business does requirements without contribution from the IT
organization. Success rates are almost exactly the same for all organization types. This means
that while budgets and timeframes can be better managed by implementing either IT or joint
ownership of business requirements, success rates are governed by a completely different and
independent variable. The data presented earlier in this report demonstrates that success is
driven by the competency of the business requirements team.
Business Implications in the Data
These findings indicate that enterprises would be best served by
creating an independent Center of Excellence for business
requirements which is jointly owed by business and IT. Institutionalizing
joint ownership appears to positively influence the cost and timeliness
of application delivery, while a correctly established center of
excellence can be charged with maintaining the appropriate work
standards and be effective in this role. Only when both structure and
high levels of competency are brought together are superior resource
efficiency and superior success rates achieved.
The idea of a center of
excellence for business
requirements is gaining
momentum particularly
for larger companies with
a need to deal with
complex projects. In the
absence of this structure
it is harder to manage
the requisite
competency base of the
corporation, and
optimize the use of elite
analysts across the
enterprise.
Assessing Organizational and Project Risk Factors
This report is designed to help the C-level executive take action to improve results. To meet this
need IAG focused on diagnosing various types of project risks to analyze underlying issues
impacting project failure rates. The analysis looks at three major areas:
- The impact of project objective types on project success.
- The impact of project size and budget on project success.
- The impact of adopting packaged versus a custom build approach on project success.
The findings indicate that success rates are changed by some of these variables, but perhaps
not in the way people might think. In conclusion to this section, IAG presents a project risk
assessment tool designed to help project executives proactively identify increased potential for
failure at the start of a project.
Assessing the Risk Associated with Complex Project Objectives: The Downfall of
the Average Practitioners versus the Elite Practitioners of Requirements Discovery
Companies have been grappling with getting requirements right for a long time. More mature
companies often have large business analyst teams tasked to working projects. The ratio at a
few companies IAG works with is 1 analyst for every 2 developers. The challenge is that many of
these people will simply not be effective in certain roles. Data from this project underscores the
real issue: the "average" business analyst team will fail to get successful results in over 60% of
projects where a significant change to the existing approach to doing business is needed.
IAG investigated the connection between the competencies of the business analysis team and
certain business outcomes expected by the business such as cutting costs, launching new
products, regulatory compliance, reengineering the business, etc. The results demonstrate a
remarkable difference between the performance of 'average' analysts and elite practitioners
where process change is an expectation of the project. The elite analyst MUST be following a
different process than the average analysts to create their success. There is no other
explanation for elite being successful in achieving objectives on 80% of projects, while in 60% of
cases the average analyst fails to achieve the same objective.
IAG speculates that the underlying variable driving the discrepancy is the degree to which
analysts can rely on their personal industry or company understanding versus relying on the
requirements discovery skills of a professional analyst. To elaborate ' take the insurance industry
example:
An insurance company adding a new product (a coverage) is a fairly well
established process. There is a well established business pattern and information
set needed (rating rules, exclusions, terms, etc); the analyst can simply "fill in the
blanks". Most new products do not have significant process or processing
changes so the average analyst with a high degree of industry or company
understanding would perform the task very well.
There is limited process change in the above example ' therefore the average
analyst should perform quite well. If the new product had significant process
change, then the analyst would not perform well.
Dealing with compliance issues in insurance ' the average analyst may perform well since
changes tend to effect how the company rates rather than its business process ' while in
pharmaceutical industries the average analyst probably performs poorly since regulation
changes tend to significantly effect operation and distribution processes.
Business Implications of the Data
In business requirements, there is a difference between the "elicitation" methodology used by
companies that achieve expectations when there is a significant degree of process change
expected in the project and those that don't. Analysts must be able to bring consensus
amongst stakeholders on requirements even when the business processes are totally different or
they will fail.
Assessing the Risk Associated with Project Size
It is a common belief: large projects have large risk and small projects have small risk. While this
may be true from a financial perspective, there was no correlation or meaningful pattern that
exists in the data between overall budget and project success rates. The risk ' regardless of
budget ' lies in the number of stakeholders impacted by the solution and secondarily, by the
number of people required for requirements gathering, rather than specifically project budgets.
The data here is unusual, and revealing.
In the data presented to the right,
projects which impact a small
number of employees can be as
risky as massive roll-outs that affect
thousands or tens of thousands of
employees. IAG's expectation
prior to the survey was that there
should be a simple relationship
between the size of the
stakeholder group and the success
rate of projects (the larger the
group, the lower the success rate).
Looking under the data, projects
that impact a small number of stakeholders have expectation management problems.
Specifically:
- The amount of time needed to implement the solution versus expectation
- The amount of personal time consumed versus expectation
Source: IAG Business Analysis Benchmark, 2008
Business Implications of the Data
There are three key messages in this data for both business and IT executive:
- Simply because a solution is small, or impacts few stakeholders, does not mean that this
project is pre-disposed to success. The data shows quite the opposite.
- Companies need to do a better job of scoping smaller projects which have process
change to better set time expectations and control costs. The project governance
frameworks at many companies may not be placing enough scrutiny on these smaller
project types to make them more efficient.
- For larger projects, there is a vast difference in performance success rates between the
average analyst, and highly skilled analysts. Companies need to reconsider the wisdom
of using the same people to perform all project types.
Success of Commercial Packaged Solutions and Business Requirements
There is an unusual belief that pervades the industry that an organization can simply pick a
package and implement it ' and they will be successful so long as few modifications are made.
The idea is that the 'best-of-breed' processes within the application displace the existing
processes of the
company. The
data finds that this
is simply not true.
| Which best describes the solution deployed? |
Proportion
On Time On
Budget, on
Function |
Proportion
Considered
Successful |
| Developed ourselves |
32% |
46% |
| Based on Custom Software - Outsourced
Development |
9% |
36% |
| Based on packaged with no modifications |
45% |
47% |
| Packaged: with high degrees of customization |
28% |
36% |
While commercial
off-the-shelf
(COTS)solutions
with few
modifications are
more frequently
delivered on time,
budget and function than other approaches to development, there is very little difference in the
success rate between companies that developed the solution themselves and the packaged
solution approach. Secondly, neither the average success rate for COTS nor the proportion of
projects delivered on time and budget is better than 50%. Focusing on unmodified COTS
implementation will not bring about a systematic predictability in success rates or time/budget
performance of projects.
Implementing a COTS solution without a solid foundation of business process and information
flow understanding will most often lead to a marginal project implementation which is deemed
"neither a success, nor a failure". This projects, for example, have the expected functionality
delivered, but business benefits anticipated are not realized or the cost of changing processes
to match the design of the system are far higher than expected.
As with all development approaches, the competencies of the requirements discovery team
strongly influences the probability that the implementation will be deemed "successful" by
participants. The average skill level of analyst teams implementing COTS successfully is as high
as those implementing through other solution approaches. An interesting quirk of findings:
unlike all other categories where the skill of the analyst team is equally effective at creating
success as it is at mitigating the probability of failure, in COTS failure seems to be influenced by
factors other than the skill of the business analysis team (i.e., the skill of the team could be
relatively high, and the implementation still may not be successful).
In general, it appears that other processes within the generally accepted approach to selecting
and implementing COTS are getting in the way of competent analyst teams actually achieving
success. Some possible explanations of this "good execution with poor results" phenomenon
associated with COTS:
- Organizations are selecting and purchasing an inappropriate application ' THEN ' trying
to do the detailed analysis of how the company processes will work.
- Some other process is more heavily influencing and creating failures despite stronger
analysis skill, such as:
- The quality of the software
- The contracting or project management approach.
- The IT department's approach to gap analysis and implementation.
- The software vendor's processes or implementation approach.
Business Implications of the Data
Companies with business analysis centers of excellence will need to look at the process of COTS
selection and implementation. As with other areas of system development, the quality of
business requirements discovery should be strongly correlated with achieving successful
outcomes. Where this is not the case, there is likely a process failure which needs to be
addressed.
Risk Assessment Model
From the above data, the one factor that enables executives to proactively predict project
success risk is the type of business objectives being pursued in the project. Using this, an
executive can better forecast the risk of project failure, and take action to manage this risk.
Below, is a business requirements discovery risk scale designed for project managers to describe the probability of a failure to meet specific business goals unless mitigating action is taken.
Source: IAG Business Analysis Benchmark, 2007
Specifically, the table illustrates the expected failure rate to achieve a given business objectives
for Scenario 1 companies. Failure rates for high process change objectives are in excess of 60%.
In order for the Scenario 2 company to achieve success when facing a high risk objectives, it
must adopt the practices of a Scenario 1 company. In Scenario 1 companies, the process of
elicitation and the competencies of the analysts deliver success rates of between 73% and 88%
for the same set of objectives.
Since companies seldom have only one business objective on a project, they should consider
the relative importance of these objectives and plot the overall project's business requirements
discovery risk. The higher the risk level (to the right on the scale) the more often companies did
not achieve their expected business objectives of the project.IAG believes that as risk levels
rise, companies must take steps to mitigate this risk.
The research shows that companies mitigate risk when significant reengineering is required, but
will tend to overlook the need for elite analysts when cost reduction goals are targeted.
Business Implications of the Data
The potential for failure on projects can be mapped based on the business objectives targeted
by that project. Companies can, and do, mitigate this risk by engaging elite analysts which are
consistently successful at achieving business objectives. However, companies tend not to apply
this risk mitigation when cost cutting is a key goal of the company, and will therefore tend to
under-achieve the goals targeted.
Companies must develop or have access to elite analysts to achieve certain business objectives
of application implementation. Failure to deploy this asset will generally result in high failure
rates. The Center of Excellence approach can be used to provide the resources capable of
assessing the business objectives risk of a project (using the scale above), and to provide a
supply of elite analysts to engage in projects where risk is unacceptably high.
Conclusions in Diagnosing Organizations
Most organizations are not well set up to be successful in getting business requirements right '
over 50% do not have even basic pieces in place to be successful at establishing business and
software requirements, and 70% of organizations do not have the fundamental competencies
within business requirements discovery to consistently bring in projects on time and on budget.
Having the requisite competencies is critical to controlled IT performance. It also means that if
an organization is consistently better than 70% of their competitors in this area of competency,
there should be a noticeable performance difference in the company as a whole versus its
competitors. Capital dollars in information technology for Scenario 2 companies are simply
better allocated.
Companies should realize that the competency bar for achieving sustained performance
difference is quite high. This performance gain is not realized by simply implementing a tool, or
training analysts for a few weeks. Achieving change will require a holistic approach to
developing people and processes. The level of effort and investment needed should not be
underestimated.
The data supports the creation of an independent Center of Excellence for business
requirements which is jointly owed by business and IT. Institutionalizing joint ownership positively
influences the cost and timeliness of application delivery. A well-established center of
excellence must be charged with maintaining the appropriate work standards if it is to be
effective at influencing the quality of results as well as the cost. Only when both of these factors
are combined are superior resource efficiency and superior success rates achieved.
The concept of Center of Excellence is further supported by the need for elite business analysts
on certain types of projects. Companies must develop or have access to elite-competency
analysts to achieve certain business objectives of application implementation. Failure to deploy
elite analysts in these situations will generally result in a failure to achieve the target business
objective.
Companies with business analysis centers of excellence will need to look at the process of COTS
selection and implementation. As with other areas of system development, the quality of
business requirements discovery should be strongly correlated with achieving successful
outcomes. Where this is not the case, there is likely a process failure which needs to be
addressed.
Perhaps the most critical findings of this sub-report: Point changes to organization and
deliverables don't yield meaningful change to results in and of themselves. Only when elements
associated with the process of requirements discovery are considered in combination with these
other organizational elements is meaningful change to performance realized. It is this finding
that leads IAG to conclude that many companies simply do not visualize business requirements
as, first and foremost, a process rather than a document. The focus of companies must shift to
the quality of Requirements Discovery as a process and away from "Business Requirements" as a
document that was either completed not at the beginning of a project if they hope to
consistently deliver successful projects.
Contacting the Author
We encourage those with questions on the survey to reach out to the author and IAG. Send us
your feedback, success stories, and experiences in making improvement. Personally, I'm an
avid collector of data on requirements and business issues of performance change so I'm
always interested in hearing about how your organization improved.
If you wish to send me an email, go to www.iag.biz and select [contact us] and send an email to
the address listed with "IAG Business Analysis Benchmark" in the subject line.
About the Survey
This survey is designed to scrutinize the impact of business analysts on North American business,
and the technology projects of these companies. The study started with a random sampling of
approximately 400 projects and winnowed this down to the 110 projects which fit precise criteria.
These criteria are:
- The project budget must be in excess of $250,000 for development, software and
external services. This means we eliminate simple or routine projects that lack a
moderate amount of complexity.
- The project must involve software development or application implementation. This
means that we eliminate infrastructure or technology-only roll-out projects.
- The project must deliver of business capability or software functionality that is significantly
different than those which existed prior to the project. By this we eliminate most
maintenance, bug-fix, or technology replatforming projects which do not really change
the business.
Using these criteria, IAG removed bulk of maintenance or technology-only projects, and
focused on a subset of larger projects that are truly strategic to a company. In numbers, this
subset may account for less than 10% of total projects completed by the IT organization in a
year, but is also likely to account for as much as 50% of project spending. In fact, over 75% of
projects reviewed in our research were considered either "critically important" or "very
important" to the enterprise. This special class of project is typically:
- Fundamental to the performance of the business.
- Larger, and typically cross-functional in nature with a high potential for project
interdependencies.
- Represents the bulk of larger-scale project work which is initiated at companies
today.
This is a difficult class of projects for companies. Our research finds found only 20% delivered on
time, a mere 28% are delivered on budget, and less than 45% that delivered the full functionality
expected at the outset of the project. As a class, this grouping represents a significant amount
of expenditure ' and an area of generally poor performance for large companies.
This survey was developed by IAG Consulting and Michael O'Neil, and fielded in association with
InfoTech Research Group.
About the Author
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
About the Research Partners of this Report
Info-Tech Research Group
This research is done in association with InfoTech Research Group which managed the field
research technology and related processes. InfoTech is a global leader in providing IT research
with over 21,000 worldwide subscribers and a ten-year history of delivering quality.
ITinCanada.ca
Michael O'Neil and the team at ITinCanada.ca provided assistance in survey design and results
analysis. Mr. O'Neil's global research background enabled us to bring together partners to
syndicate the research and assisted us in getting the response rate needed to make this project
a success.
About IAG Consulting
IAG specializes in business and software requirements. Over the last 10 years, IAG has worked
with 300 of the Fortune 500 companies, completed over 1,000 business and software
requirements assignments, and trained over 15,000 business analysts. Our organization focuses
on a practical and practiced approach that is efficient for all stakeholders in both business
professional and information technology departments. We bring measurable gains by:
- Reducing time needed to complete requirements
- Ensuring completeness in documentation and reducing change requests
- Issuing RFPs where vendors can bid accurately and clients get better terms
- Reducing costs in systems development
- Salvaging troubled projects
CONTACTING AN IAG CONSULTING SPECIALIST: Email IAG by accessing www.iag.biz and
selecting contact us or call our North American Toll Free line: 800-209-3616