Description
Preempting enterprise resource planning (ERP) project failure could well become the Holy Grail for organizations seeking to improve their technology infrastructure, organizational efficiency, and competitiveness.
Preempting ERP Project Failure
Project Assurance through Collaborative Intervention
The Prinzo Group, December 2010
Overview
Preempting enterprise resource planning (ERP) project failure could well become the Holy Grail for
organizations seeking to improve their technology infrastructure, organizational efficiency, and
competitiveness.
If you work in the business world, you have likely heard of or experienced horror stories with enterprise
software implementations that range from daily headaches to loss of business. But the fact is that most
organizations do not anticipate project failure. Instead, they plan for success, governed by budget, next
step deliverables, executive expectations, and go?live deadlines. Heads?down to the task at hand, the
project manager and team have little visibility and less control over potential risks within the ERP project
– until it’s too late.
The business of preempting project failure begins with understanding that there is a preventative
approach that can provide planned project assurance at critical points in the project’s evolution. It
begins with clear understanding of expectations – from the executives, to the business and IT
management, to the software vendors and end users.
Why? Because clarity in expectations translates to clarity in both system requirements and business
analysis. Consider these key findings from the report, The Impact of Business Requirements on the
Success of Technology Projects from IAG Consulting:
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
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.
In fact, the horror stories continue. Industry experts
have recently published the following:
IT projects come in at a success rate of only 29%
Average cost over?run is 56%
Average schedule delay is 84% beyond plan
1
Simply translated, this means that nearly 70% of implementations will fail, cost more than 50% over
budget, and take nearly twice as long as planned.
Copyright ©2010 The Prinzo Group Page 2
The extreme complexity and poor success rate of software implementations continues to baffle many
executives. Given that there are accredited bodies of knowledge surrounding software
implementations, certifications for project management professionals, a growing field of highly skilled
practitioners, endless tools, methodologies and countless studies on what makes projects successful –
why do projects still fail? The failures can range from project cost overruns to missed expectations,
disgruntled users to “train wrecks” – which are wastelands of time and money in the form of software
that is never implemented or projects that are simply cancelled.
Why projects fail
You would think that, over the years, project management would have evolved along with the
technology that is being implemented. In truth, the high rate of project failure in today’s organizations is
proof that project implementation methodologies have not kept pace.
So, why do projects fail?
1. Lack of top management commitment
2. Unrealistic expectations
3. Poor requirements definition
4. Improper package selection
5. Gaps between software and business requirements
6. Inadequate resources
7. Underestimating time and cost
8. Poor project management / lack of methodology
9. Underestimating impact of change
10. Lack of training / education
Look closely – you may be surprised to see that a common denominator is not technology, but people.
Their decisions, expectations, and actions are the key components in project success – and failure. Why?
Because for the most part, software is coded to perform a function, but people and/or the project team
members are required to develop the plan, evaluate systems and services, manage the implementation,
design and configure the application, test the system, train the users and communicate the change to
the organization.
In addition to the human element, consider the evolution of project management methodologies.
Today’s software implementation methodology is adopted from the Waterfall Model used by the
Copyright ©2010 The Prinzo Group Page 3
manufacturing and construction industries. The waterfall model is a sequential implementation process
where each phases follows a previous phase flowing steadily downward like a waterfall.
Waterfall methodology
Since no formal methodology was available at the time of the first enterprise system implementations,
the waterfall model has become the de facto methodology used by companies and systems integrators.
Over the years, it has evolved to account for ongoing project activities such as project management and
change management.
The waterfall methodology is the most structured of the methods, stepping through requirements,
analysis, design, coding, and testing in a strict, pre?planned, "all at once" sequence. Progress is often
measured in terms of deliverable artifacts: requirement specifications, design documents, test plans,
code reviews and the like.
A common criticism of the waterfall model is its inflexible division of a project into separate stages,
where commitments are made early on, making it difficult to react to changes in requirements as the
project executes. This means that the waterfall model is likely to be unsuitable if requirements are not
well understood/defined or changed in the course of the project.
2
Inflexible, archaic project management methodologies can result in significant cost overruns as well as
failure to meet the fundamental business requirements of the software implementation over the course
of the project. After the purchase, the most significant cost occurs during the development phase. If,
during the strategy phase, there are gaps in the business requirements and the implementation plan – it
could spell disaster for the implementation itself.
What is interesting is this: if you map the reasons that projects fail to the timed phases of a software
implementation, although the failure points are present throughout the project lifecycle, most, if not all,
can occur before the project technically begins.
Copyright ©2010 The Prinzo Group Page 4
To combat early failure, ERP implementation projects need project assurance from the beginning.
The high cost of failure
Project failure can happen early, causing a ripple effect on your project. In planning your project, you
have calculated your project budget, resource / staffing needs and your projected ROI. However, if there
is a gap in your requirements that causes delay during the acquisition phase of your project, or worse
yet, you leave out key requirements from the strategy phase because of a rushed assessment, the
resulting impact will be seen downstream – causing the extension of subsequent project phases. The
ripple effect of missing project gaps early during the project will not only create vulnerability and
weakness in the project plan integrity, it affects the time line, the overall project cost, realized benefits /
ROI calculations and the project team’s credibility.
For example, project delay cost can be measured as follows:
Internal and external resources cost – a three month project delay resulting in the extension of
two internal resources at $120,000 a year, plus the extension of three consultants at $175 per
hour, results in over $350,000 in extra project costs
Delayed operational improvements and realization of operational improvements – a three
month project delay with additional resource cost will lower the project return on investment
(ROI) by delaying the realization of the system benefits in the form of cost saving and
streamlined business processes
Copyright ©2010 The Prinzo Group Page 5
Loss of confidence in the project team itself – missed project deadlines result in lower project
team morale and organizational skepticism about the viability of the current and future projects
The business case for a better way
History is repeating itself – the impact of the global recession on technology spending is creating the
latest inflection point for enterprise systems. The inflection point will be realized when organizations
realize that upgrading the application will cost as much as implementing the software in the first place.
As the economy improves and beyond, organizations will once again begin enterprise system projects in
the form of business process transformation projects, new system implementations or upgrades.
But how can we improve the odds for implementation success? As you can see from our analysis of
project failure, projects will continue to fail due to human factors with the most common and fatal
failure points occurring early in the project – making the cost of failure exponential.
Inherent in the analysis of failure is the software implementation methodology itself (the waterfall
methodology). As a stand?alone, legacy project management methodology, it does not have the checks
and balances required to ensure success during the strategy, acquisition and planning stages. It does not
provide the mechanisms for project interventions.
By combining the lessons learned with the analysis of why projects fail, the alarming fact is, that after all
these years, while the level of expertise in enterprise system implementations has increased, the
success rate has not. Future failures are imminent because many organizations lack the ability, tools and
knowledge to ensure that projects are delivered on time, on?budget, with user acceptance, or, to put it
another way, organizations lack project assurance.
The need for project assurance
How can any organization that is considering implementing a large?scale enterprise system disregard the
need for project assurance? Project assurance is about making sure that projects are delivered on time,
on?budget, with client acceptance. Having project assurance as part of a large?scale system
implementation or transformation project helps you:
control/reduce project costs
ensure milestones are met
minimize surprises
provide objective analysis
provide peace of mind and trust among executives and project team members
Project assurance is the closest thing to an insurance policy for enterprise application software
implementations that you can find.
Copyright ©2010 The Prinzo Group Page 6
Project Assurance through collaborative intervention
To accomplish these goals, The Prinzo Group has developed a project assurance methodology known as
collaborative intervention
SM
. Collaborative intervention is a project assurance methodology designed to
align project expectations, resources and scope with the goal of increasing the project's probability of
success. Collaborative intervention is different from other project management methodologies in that it
addresses key project failure points before they occur by creating a collaborative environment
comprised of key project stakeholders to discuss and resolve project issues and roadblocks before they
arise.
If you think about your project at the point where you identify the business need to start a project, how
do you know if failure lies ahead? Often you don’t. But if you stand back and look at the situation as if
you were watching a movie, you may see the signs of impending disaster. Picture this scene: a train
speeding down the track; a hurried driver in a car trying to make it across the tracks as the train rounds
the curve; the conductor not paying attention; the crossing bars going down; the red lights flashing; the
bells ringing. Watching the movie, how can you miss what is about to happen?
Picturing the project as a movie works if you can stand back from the project, but, the truth is that most
people on the project team can’t see the train wreck that is about to occur, or if they do see it, they
don’t know how to stop it. That is why collaborative intervention is so innovative: it is a process to avert
disaster by identifying the warning signs and taking preventative action.
Collaborative intervention is a project assurance methodology designed to align project expectations,
resources and scope with the goal of increasing the project’s probability of success. Collaborative
intervention is different from other project assurance methodologies in that it addresses key project
failure points before they occur. How? By creating a collaborative environment composed of key project
stakeholders to identify and resolve project issues and avert roadblocks as they arise.
Most project teams may not encounter one large disaster, but a series of small disasters that can lead
up to larger failure. Like the train wreck scenario above, different parts of the project team may be
unaware that they are on a collision course. Individual events, such as the driver running late or the
conductor being distracted, may be caused by events that took place earlier. The same is true for project
failure. For example, not conducting a needs assessment; missing requirements; choosing the wrong
software or implementation partner; or underestimating the impact of change can all be identified early
on and corrected to lessen the downstream impact.
Collaborative intervention is an ongoing process that evaluates warning signs at the points at which they
are likely to begin to occur in the project. Collaborative intervention allows project managers and
executives to take action, to monitor the situation to make sure that the issues are resolved, and if not,
adjust accordingly. By establishing a framework of collaborative intervention, organizations can ensure
that project failure points are averted before they occur and the disastrous train wreck never
materializes.
Copyright ©2010 The Prinzo Group Page 7
What collaborative intervention means to you
Similar in concept to Independent Verification and Validation (IV&V), collaborative intervention is the
project assurance methodology that lets you verify that project requirements are met and validate that
the project implementation will meet the requirements. However, collaborative intervention differs
from a traditional IV&V project in the following critical ways:
1. It’s comprehensive. Project management IV&V focuses on tactical projects issues such as hands?
on testing of software to make sure that the product built matches detailed requirements,
where as collaborative intervention takes a more comprehensive approach to not only have
checkpoints to ensure tactical deployment, but also checkpoints for strategic issues such as
project alignment with organizational goals and strategy.
2. It’s a smarter start. Project management IV&V methodologies often start in the project planning
phase after a strategy has been defined and software has been purchased. Collaborative
intervention defines the beginning of the project as the initial strategy phase when project
goals, objectives, budgets and plans are formulated, and subsequently, software and services
are purchased. Since many project failure points are conceived in the early stages of the project,
it makes sense to put the collaborative intervention framework in place at the beginning of the
project to ensure success from the start.
3. It’s friendly. Project management IV&V methodologies focus on the science of software
implementation – what is quantifiable and tangible. Collaborative intervention, unlike IV&V,
provides an ongoing structure for realistic issue resolution based on intangible human factors –
trust, common goals and communication.
4. It’s proactive. The collaborative intervention process is proactive, whereas IV&V is reactive.
Collaborative intervention not only reviews the current status of the project, but also ensures
that scope, resources and funding are appropriately aligned for upcoming project phases and
activities.
5. It’s preventative. Collaborative intervention creates a structure of change and involvement for
project sponsors, executives and project managers. Collaboration with an outside expert adds
both value to the project implementation and protection against the high cost of failure. The
interventionist delivers not only know?how, but also assists in navigating the organization by
creating a collaborative team of decision makers that can remove project roadblocks.
Copyright ©2010 The Prinzo Group Page 8
The Collaborative intervention process
Collaborative intervention is comprised of three steps: identify, assess, and intervene.
1. Identify – The first step of the collaborative intervention process is to identify where the project
is in the implementation lifecycle, so that you understand when to intervene. Once determined,
you can know what to look for and what the likely issues may be.
2. Assess – The second step of the collaborative intervention process is to assess. The assessment
is a top?to?bottom evaluation of what to look for during the project to help you align project
expectations, resources and scope with the goal of increasing the project’s probability of
success.
3. Intervene – The final stage of the collaborative intervention process is to intervene. The
collaborative intervention process outlines how to intervene by presenting the findings of the
assessment and working with the project team to develop an implementation plan to address
the findings.
At the end of the day, collaborative intervention gives you the when, what and how answers you need
to assure project success. It helps you to identify and resolve the strategic, tactical and intangible issues
before they become insurmountable. Collaborative intervention gives you the tools and techniques you
need to investigate and defuse volatile situations within the organization and the project team.
And best of all, collaborative intervention gives you (and everyone else involved) peace of mind that the
project is on the right track.
Copyright ©2010 The Prinzo Group Page 9
About The Prinzo Group
The Prinzo Group is an innovative knowledge firm that provides project assurance expertise for
enterprise transformation and technology projects. Publications, workshops, training and consulting are
available to individuals and organizations involved in enterprise applications implementations.
Founded in 2010 by Rob Prinzo, The Prinzo Group has its roots in the technology industry. Six years
earlier, Rob founded Future State Consulting, Inc., which grew to become a trusted consulting partner to
organizations seeking to achieve strategic and tactical optimization of enterprise business applications.
In 2005, Future State Consulting partnered with Anteo Group, an award winning IT Staff Augmentation
Company to launch Anteo Consulting, LLC.
Since 2005, Anteo Consulting worked with large organizations across multiple industries. Experiencing
significant growth under Prinzo’s leadership, Anteo Consulting played a large role in the rapid and award
winning growth of Anteo Group, which has been recognized as by Entrepreneur Magazine and
PriceWaterhouseCooper as one of America’s 100 Fastest?Growing New Businesses (2004?2006), INC
Magazine 5000 Fastest Growing Private Companies (2007?2009) and the Atlanta Business Chronicle as
one of the best places to work in Atlanta (2005?2010).
In 2010, Rob published the book, No Wishing Required: The Business Case for Project Assurance and
launched The Prinzo Group to provide project assurance expertise for enterprise transformation and
technology projects.
Contact Information
The Prinzo Group
5815 Windward Parkway, Suite 302?002
Alpharetta, GA 30005
(678) 496?4615
www.prinzogroup.com
Copyright ©2010 The Prinzo Group Page 10
Copyright ©2010 The Prinzo Group Page 11
References
1. Outsourcing: Industrialize your applications delivery to achieve high performance. Accenture 2008
2. Wikipedia ? (Sommerville, Ian (2007) [1982]. "4.1.1. The Waterfall Model". Software engineering (8th
ed.). Harlow: Addison Wesley. pp. 66f. ISBN 0?321?31379?8.)
http://en.wikipedia.org/wiki/Waterfall_model#Criticism
doc_818129383.pdf
Preempting enterprise resource planning (ERP) project failure could well become the Holy Grail for organizations seeking to improve their technology infrastructure, organizational efficiency, and competitiveness.
Preempting ERP Project Failure
Project Assurance through Collaborative Intervention
The Prinzo Group, December 2010
Overview
Preempting enterprise resource planning (ERP) project failure could well become the Holy Grail for
organizations seeking to improve their technology infrastructure, organizational efficiency, and
competitiveness.
If you work in the business world, you have likely heard of or experienced horror stories with enterprise
software implementations that range from daily headaches to loss of business. But the fact is that most
organizations do not anticipate project failure. Instead, they plan for success, governed by budget, next
step deliverables, executive expectations, and go?live deadlines. Heads?down to the task at hand, the
project manager and team have little visibility and less control over potential risks within the ERP project
– until it’s too late.
The business of preempting project failure begins with understanding that there is a preventative
approach that can provide planned project assurance at critical points in the project’s evolution. It
begins with clear understanding of expectations – from the executives, to the business and IT
management, to the software vendors and end users.
Why? Because clarity in expectations translates to clarity in both system requirements and business
analysis. Consider these key findings from the report, The Impact of Business Requirements on the
Success of Technology Projects from IAG Consulting:
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
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.
In fact, the horror stories continue. Industry experts
have recently published the following:
IT projects come in at a success rate of only 29%
Average cost over?run is 56%
Average schedule delay is 84% beyond plan
1
Simply translated, this means that nearly 70% of implementations will fail, cost more than 50% over
budget, and take nearly twice as long as planned.
Copyright ©2010 The Prinzo Group Page 2
The extreme complexity and poor success rate of software implementations continues to baffle many
executives. Given that there are accredited bodies of knowledge surrounding software
implementations, certifications for project management professionals, a growing field of highly skilled
practitioners, endless tools, methodologies and countless studies on what makes projects successful –
why do projects still fail? The failures can range from project cost overruns to missed expectations,
disgruntled users to “train wrecks” – which are wastelands of time and money in the form of software
that is never implemented or projects that are simply cancelled.
Why projects fail
You would think that, over the years, project management would have evolved along with the
technology that is being implemented. In truth, the high rate of project failure in today’s organizations is
proof that project implementation methodologies have not kept pace.
So, why do projects fail?
1. Lack of top management commitment
2. Unrealistic expectations
3. Poor requirements definition
4. Improper package selection
5. Gaps between software and business requirements
6. Inadequate resources
7. Underestimating time and cost
8. Poor project management / lack of methodology
9. Underestimating impact of change
10. Lack of training / education
Look closely – you may be surprised to see that a common denominator is not technology, but people.
Their decisions, expectations, and actions are the key components in project success – and failure. Why?
Because for the most part, software is coded to perform a function, but people and/or the project team
members are required to develop the plan, evaluate systems and services, manage the implementation,
design and configure the application, test the system, train the users and communicate the change to
the organization.
In addition to the human element, consider the evolution of project management methodologies.
Today’s software implementation methodology is adopted from the Waterfall Model used by the
Copyright ©2010 The Prinzo Group Page 3
manufacturing and construction industries. The waterfall model is a sequential implementation process
where each phases follows a previous phase flowing steadily downward like a waterfall.
Waterfall methodology
Since no formal methodology was available at the time of the first enterprise system implementations,
the waterfall model has become the de facto methodology used by companies and systems integrators.
Over the years, it has evolved to account for ongoing project activities such as project management and
change management.
The waterfall methodology is the most structured of the methods, stepping through requirements,
analysis, design, coding, and testing in a strict, pre?planned, "all at once" sequence. Progress is often
measured in terms of deliverable artifacts: requirement specifications, design documents, test plans,
code reviews and the like.
A common criticism of the waterfall model is its inflexible division of a project into separate stages,
where commitments are made early on, making it difficult to react to changes in requirements as the
project executes. This means that the waterfall model is likely to be unsuitable if requirements are not
well understood/defined or changed in the course of the project.
2
Inflexible, archaic project management methodologies can result in significant cost overruns as well as
failure to meet the fundamental business requirements of the software implementation over the course
of the project. After the purchase, the most significant cost occurs during the development phase. If,
during the strategy phase, there are gaps in the business requirements and the implementation plan – it
could spell disaster for the implementation itself.
What is interesting is this: if you map the reasons that projects fail to the timed phases of a software
implementation, although the failure points are present throughout the project lifecycle, most, if not all,
can occur before the project technically begins.
Copyright ©2010 The Prinzo Group Page 4
To combat early failure, ERP implementation projects need project assurance from the beginning.
The high cost of failure
Project failure can happen early, causing a ripple effect on your project. In planning your project, you
have calculated your project budget, resource / staffing needs and your projected ROI. However, if there
is a gap in your requirements that causes delay during the acquisition phase of your project, or worse
yet, you leave out key requirements from the strategy phase because of a rushed assessment, the
resulting impact will be seen downstream – causing the extension of subsequent project phases. The
ripple effect of missing project gaps early during the project will not only create vulnerability and
weakness in the project plan integrity, it affects the time line, the overall project cost, realized benefits /
ROI calculations and the project team’s credibility.
For example, project delay cost can be measured as follows:
Internal and external resources cost – a three month project delay resulting in the extension of
two internal resources at $120,000 a year, plus the extension of three consultants at $175 per
hour, results in over $350,000 in extra project costs
Delayed operational improvements and realization of operational improvements – a three
month project delay with additional resource cost will lower the project return on investment
(ROI) by delaying the realization of the system benefits in the form of cost saving and
streamlined business processes
Copyright ©2010 The Prinzo Group Page 5
Loss of confidence in the project team itself – missed project deadlines result in lower project
team morale and organizational skepticism about the viability of the current and future projects
The business case for a better way
History is repeating itself – the impact of the global recession on technology spending is creating the
latest inflection point for enterprise systems. The inflection point will be realized when organizations
realize that upgrading the application will cost as much as implementing the software in the first place.
As the economy improves and beyond, organizations will once again begin enterprise system projects in
the form of business process transformation projects, new system implementations or upgrades.
But how can we improve the odds for implementation success? As you can see from our analysis of
project failure, projects will continue to fail due to human factors with the most common and fatal
failure points occurring early in the project – making the cost of failure exponential.
Inherent in the analysis of failure is the software implementation methodology itself (the waterfall
methodology). As a stand?alone, legacy project management methodology, it does not have the checks
and balances required to ensure success during the strategy, acquisition and planning stages. It does not
provide the mechanisms for project interventions.
By combining the lessons learned with the analysis of why projects fail, the alarming fact is, that after all
these years, while the level of expertise in enterprise system implementations has increased, the
success rate has not. Future failures are imminent because many organizations lack the ability, tools and
knowledge to ensure that projects are delivered on time, on?budget, with user acceptance, or, to put it
another way, organizations lack project assurance.
The need for project assurance
How can any organization that is considering implementing a large?scale enterprise system disregard the
need for project assurance? Project assurance is about making sure that projects are delivered on time,
on?budget, with client acceptance. Having project assurance as part of a large?scale system
implementation or transformation project helps you:
control/reduce project costs
ensure milestones are met
minimize surprises
provide objective analysis
provide peace of mind and trust among executives and project team members
Project assurance is the closest thing to an insurance policy for enterprise application software
implementations that you can find.
Copyright ©2010 The Prinzo Group Page 6
Project Assurance through collaborative intervention
To accomplish these goals, The Prinzo Group has developed a project assurance methodology known as
collaborative intervention
SM
. Collaborative intervention is a project assurance methodology designed to
align project expectations, resources and scope with the goal of increasing the project's probability of
success. Collaborative intervention is different from other project management methodologies in that it
addresses key project failure points before they occur by creating a collaborative environment
comprised of key project stakeholders to discuss and resolve project issues and roadblocks before they
arise.
If you think about your project at the point where you identify the business need to start a project, how
do you know if failure lies ahead? Often you don’t. But if you stand back and look at the situation as if
you were watching a movie, you may see the signs of impending disaster. Picture this scene: a train
speeding down the track; a hurried driver in a car trying to make it across the tracks as the train rounds
the curve; the conductor not paying attention; the crossing bars going down; the red lights flashing; the
bells ringing. Watching the movie, how can you miss what is about to happen?
Picturing the project as a movie works if you can stand back from the project, but, the truth is that most
people on the project team can’t see the train wreck that is about to occur, or if they do see it, they
don’t know how to stop it. That is why collaborative intervention is so innovative: it is a process to avert
disaster by identifying the warning signs and taking preventative action.
Collaborative intervention is a project assurance methodology designed to align project expectations,
resources and scope with the goal of increasing the project’s probability of success. Collaborative
intervention is different from other project assurance methodologies in that it addresses key project
failure points before they occur. How? By creating a collaborative environment composed of key project
stakeholders to identify and resolve project issues and avert roadblocks as they arise.
Most project teams may not encounter one large disaster, but a series of small disasters that can lead
up to larger failure. Like the train wreck scenario above, different parts of the project team may be
unaware that they are on a collision course. Individual events, such as the driver running late or the
conductor being distracted, may be caused by events that took place earlier. The same is true for project
failure. For example, not conducting a needs assessment; missing requirements; choosing the wrong
software or implementation partner; or underestimating the impact of change can all be identified early
on and corrected to lessen the downstream impact.
Collaborative intervention is an ongoing process that evaluates warning signs at the points at which they
are likely to begin to occur in the project. Collaborative intervention allows project managers and
executives to take action, to monitor the situation to make sure that the issues are resolved, and if not,
adjust accordingly. By establishing a framework of collaborative intervention, organizations can ensure
that project failure points are averted before they occur and the disastrous train wreck never
materializes.
Copyright ©2010 The Prinzo Group Page 7
What collaborative intervention means to you
Similar in concept to Independent Verification and Validation (IV&V), collaborative intervention is the
project assurance methodology that lets you verify that project requirements are met and validate that
the project implementation will meet the requirements. However, collaborative intervention differs
from a traditional IV&V project in the following critical ways:
1. It’s comprehensive. Project management IV&V focuses on tactical projects issues such as hands?
on testing of software to make sure that the product built matches detailed requirements,
where as collaborative intervention takes a more comprehensive approach to not only have
checkpoints to ensure tactical deployment, but also checkpoints for strategic issues such as
project alignment with organizational goals and strategy.
2. It’s a smarter start. Project management IV&V methodologies often start in the project planning
phase after a strategy has been defined and software has been purchased. Collaborative
intervention defines the beginning of the project as the initial strategy phase when project
goals, objectives, budgets and plans are formulated, and subsequently, software and services
are purchased. Since many project failure points are conceived in the early stages of the project,
it makes sense to put the collaborative intervention framework in place at the beginning of the
project to ensure success from the start.
3. It’s friendly. Project management IV&V methodologies focus on the science of software
implementation – what is quantifiable and tangible. Collaborative intervention, unlike IV&V,
provides an ongoing structure for realistic issue resolution based on intangible human factors –
trust, common goals and communication.
4. It’s proactive. The collaborative intervention process is proactive, whereas IV&V is reactive.
Collaborative intervention not only reviews the current status of the project, but also ensures
that scope, resources and funding are appropriately aligned for upcoming project phases and
activities.
5. It’s preventative. Collaborative intervention creates a structure of change and involvement for
project sponsors, executives and project managers. Collaboration with an outside expert adds
both value to the project implementation and protection against the high cost of failure. The
interventionist delivers not only know?how, but also assists in navigating the organization by
creating a collaborative team of decision makers that can remove project roadblocks.
Copyright ©2010 The Prinzo Group Page 8
The Collaborative intervention process
Collaborative intervention is comprised of three steps: identify, assess, and intervene.
1. Identify – The first step of the collaborative intervention process is to identify where the project
is in the implementation lifecycle, so that you understand when to intervene. Once determined,
you can know what to look for and what the likely issues may be.
2. Assess – The second step of the collaborative intervention process is to assess. The assessment
is a top?to?bottom evaluation of what to look for during the project to help you align project
expectations, resources and scope with the goal of increasing the project’s probability of
success.
3. Intervene – The final stage of the collaborative intervention process is to intervene. The
collaborative intervention process outlines how to intervene by presenting the findings of the
assessment and working with the project team to develop an implementation plan to address
the findings.
At the end of the day, collaborative intervention gives you the when, what and how answers you need
to assure project success. It helps you to identify and resolve the strategic, tactical and intangible issues
before they become insurmountable. Collaborative intervention gives you the tools and techniques you
need to investigate and defuse volatile situations within the organization and the project team.
And best of all, collaborative intervention gives you (and everyone else involved) peace of mind that the
project is on the right track.
Copyright ©2010 The Prinzo Group Page 9
About The Prinzo Group
The Prinzo Group is an innovative knowledge firm that provides project assurance expertise for
enterprise transformation and technology projects. Publications, workshops, training and consulting are
available to individuals and organizations involved in enterprise applications implementations.
Founded in 2010 by Rob Prinzo, The Prinzo Group has its roots in the technology industry. Six years
earlier, Rob founded Future State Consulting, Inc., which grew to become a trusted consulting partner to
organizations seeking to achieve strategic and tactical optimization of enterprise business applications.
In 2005, Future State Consulting partnered with Anteo Group, an award winning IT Staff Augmentation
Company to launch Anteo Consulting, LLC.
Since 2005, Anteo Consulting worked with large organizations across multiple industries. Experiencing
significant growth under Prinzo’s leadership, Anteo Consulting played a large role in the rapid and award
winning growth of Anteo Group, which has been recognized as by Entrepreneur Magazine and
PriceWaterhouseCooper as one of America’s 100 Fastest?Growing New Businesses (2004?2006), INC
Magazine 5000 Fastest Growing Private Companies (2007?2009) and the Atlanta Business Chronicle as
one of the best places to work in Atlanta (2005?2010).
In 2010, Rob published the book, No Wishing Required: The Business Case for Project Assurance and
launched The Prinzo Group to provide project assurance expertise for enterprise transformation and
technology projects.
Contact Information
The Prinzo Group
5815 Windward Parkway, Suite 302?002
Alpharetta, GA 30005
(678) 496?4615
www.prinzogroup.com
Copyright ©2010 The Prinzo Group Page 10
Copyright ©2010 The Prinzo Group Page 11
References
1. Outsourcing: Industrialize your applications delivery to achieve high performance. Accenture 2008
2. Wikipedia ? (Sommerville, Ian (2007) [1982]. "4.1.1. The Waterfall Model". Software engineering (8th
ed.). Harlow: Addison Wesley. pp. 66f. ISBN 0?321?31379?8.)
http://en.wikipedia.org/wiki/Waterfall_model#Criticism
doc_818129383.pdf