- Implementing enterprise software is hard. Research shows that 17% of IT projects go so badly that they threaten the existence of the company (Bloch, 2012). You need a framework that will greatly improve your chance of success.
- Traditional Waterfall project implementations have a demonstrated a low success rate for on-time, on-budget delivery.
Our Advice
Critical Insight
- Agility outside of software development is still in its infancy. The knowledge to apply it to business processes is lacking.
- Your best process experts are the same people you need to keep the business running. The business cannot afford to have its best people pulled into the implementation for long periods of time.
Impact and Result
- Leverage the best practices of project management to deliver value to the business sooner.
- Follow our iterative methodology with a task list focused on the business must-have functionality to achieve rapid execution and to allow staff to return to their daily work sooner.
- Engage users and receive timely feedback through the use of timely demonstrations of work completed.
- Govern and manage the vendor partner relationship to leverage their expertise.
Member Testimonials
After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.
8.8/10
Overall Impact
$23,250
Average $ Saved
13
Average Days Saved
Client
Experience
Impact
$ Saved
Days Saved
Kichler Lighting
Guided Implementation
8/10
N/A
N/A
Packaging Machinery Manufacturers Institute
Guided Implementation
9/10
$3,779
3
Boise Cascade Company
Guided Implementation
8/10
$14,489
5
Southwest Gas Corporation
Guided Implementation
10/10
$61,999
60
City of San Luis Obispo
Guided Implementation
10/10
$12,733
10
Enterprise Application Selection & Implementation
Don’t outsource your brain: You can’t outsource project accountability to the SI.
This course makes up part of the Applications Certificate.
- Course Modules: 5
- Estimated Completion Time: 2-2.5 hours
- Featured Analysts:
- Suanne McGrath-Kelly, Sr. Research Director, Applications Practice
- David Piazza, VP of Research & Advisory, Applications Practice
Workshop: Governance and Management of Enterprise Software Implementation
Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.
Module 1: Assess
The Purpose
- Explicitly define your business objectives.
- Identify the key stakeholders.
- Establish your success criteria.
Key Benefits Achieved
- Goals and objectives of the project.
- Table of key stakeholders.
- Key success metrics.
Activities
Outputs
Establish your starting point.
- Establish the goals and objectives of the project, identify key stakeholders, and determine key success metrics.
Governance structure.
- Determine your governance model along with the roles and responsibilities (RACI), and then determine the organizational Agile capabilities.
Define your metrics.
- Establish the key performance indicators (KPIs) that will guide the project.
Module 2: Prepare
The Purpose
- Establish your backlog of work and the teams performing the work.
- Test your selected methodology
Key Benefits Achieved
- A better understanding of the work, both short and long term, to complete prior to transitioning to operations.
- Stable teams that will perform better over the long term than temporary teams.
Activities
Outputs
Establish your backlog.
- A prioritized backlog of the requirements to implement.
Build your teams.
- Decide on your team structure and define data governance and communication plans.
Assess readiness.
- Test the selected methodology and identify areas for improvement or enhanced governance.
Module 3: Govern and Course Correct
The Purpose
- Understand the need for a simple dashboard.
- Course correct with backlog grooming.
- Develop a transition checklist for the executive steering committee to use to determine when to transition to operation.
Key Benefits Achieved
- Team will complete requirements on a steady cadence with regular check-ins to determine if course correction is needed.
- Steering committee remains informed through the dashboard and ability to see progress in the iteration end demos.
Activities
Outputs
Govern and manage.
- An executive dashboard and a reviewed backlog.
Transition.
- Scenarios depicting success or failure of the project and the potential risks and an executive checklist to assist in the decision to go operational.
Governance and Management of Enterprise Software Implementation
Being Agile will increase the likelihood of success.
Table of contents
- Assess
- 1.1. Establish Your Starting Point
- 1.2. Governance Structure
- 1.3. Define Your Metrics
- Prepare
- 2.1. Establish Your backlog
- 2.2. Build Your Teams
- 2.3. Assess Readiness
- Govern and Course Correct
- 3.1. Govern and Manage
- 3.2. Transition
ANALYST PERSPECTIVE
Are you ready to enable your people to do their best work?
“When you read “govern and manage” the tendency is to think of “command and control”; however, research shows that traditional project methods lead to high failure rates. If you reframe it as an agile conversation about “providing oversight and course correcting” then you enable people to do their best work and achieve better results.” (Robert Fayle, Director ‒ Research, Enterprise Applications, Info-Tech Research Group)
Our understanding of the problem
This Research is Designed For:
- Applications leaders implementing a new enterprise product.
- Project managers looking for a better way to deliver successful implementations.
This Research Will Help You:
- Improve the likelihood of a successful implementation by surfacing problems sooner and getting regular, early feedback from stakeholders.
- Define metrics that are leading indicators of success or failure and deliver on the anticipated business value.
This Research Will Also Assist:
- The governance committee providing oversight.
- The frontline leaders tasked with executing the implementation.
- Business stakeholders.
This Research Will Help Them:
- Understand their role as facilitators not controllers.
- Provide an overview of the overall project and the roles of all involved.
- Determine how the requirements break down to execution tasks.
Executive summary
Situation
- Implementing enterprise software is hard. Research shows that 17% of IT projects go so badly that they threaten the existence of the company (Bloch, 2012). You need a framework that will greatly improve your chance of success.
- Traditional Waterfall project implementations have demonstrated a low success rate for on-time, on-budget delivery.
Complication
- Agility outside of software development is still in its infancy. The knowledge to apply it to business processes is lacking.
- Your best process experts are the same people you need to keep the business running. The business cannot afford to have its best people pulled into the implementation for long periods of time.
Resolution
- Leverage the best practices of project management, traditional and Agile, to deliver value to the business sooner.
- Follow our iterative methodology with a task list focused on the business must-have functionality to achieve rapid execution and to allow staff to return to their daily work sooner.
- Engage users and receive timely feedback through the use of timely demonstrations of work completed.
- Govern and manage the vendor partner relationship to leverage their expertise.
Info-Tech Insight
- Agility is not absolute.
Being Agile means using various techniques to get the right work done right. Sometimes that means traditional Waterfall techniques are the right answer. - Iterations allow for course correction.
Short planning and execution cycles allow for better course correction. It’s far easier to recover from being fifty percent off on a week-long estimate than one that is four weeks.
Understand the benefits provided by Agile and the requirements for successful implementation
The effectiveness of your delivery method will depend on how integrated you are with the business and how disciplined you are in the execution of the method.

“Is the path you are choosing going to get you where you want?” (Diana Larsen, author and co-founder of the Agile Fluency Project)
Project success – Agile versus Traditional (including Ad Hoc)
IT Project Success Rates
(Source: Ambysoft, 2018)
17% of projects with budgets greater than 15 million fail to the point of threatening the existence of the company. (Source: McKinsey & Company, 2012)
Info-Tech Insight
Aim for the highest level of integration with the business and the discipline to execute to increase your chances of success.
Agile at work
CASE STUDY
Industry: Construction
Source: IBM Corporation, 2019
Challenge
CTE, which sells, rents, and services construction and industrial machinery, had its financial data siloed in three separate legacy systems.
Data analysis meant manual processes to extract, collate, and validate the necessary data. This time and cost-intensive process hampered CTE’s plans for the utilization of customer-centered information.
Solution
CTE chose SAP S/4HANA in the cloud with IBM Services as the system implementer (SI). The project required collaboration across a significant cross-section of CTE employees.
Working in three-week sprints using IBM’s Ascend methodology (powered by SAP’s Activate), CTE received the first proof of concept within ten days of project launch.
Results
IBM was able to deliver a live solution in eight months. CTE was able to recover the time on data reconciliation while relying on validated data from a single source to examine its customers’ spend patterns.
The implementation plan – follow the Info-Tech path
- Use Agile techniques such as a backlog for the work items, focusing on the must-have items (i.e. 40% of the backlog).
- Use iterations to accomplish work, which sets the implementation up for success.
- Once all the must-have requirements have been implemented, the business has the choice of launching the enterprise software.
- Post launch the teams can continue in the same cadence delivering additional functionality ad infinitum.

Related Info-Tech research
Build a Better Backlog
The quality of your product backlog is key to realizing the benefits of Agile.
Implement Agile Practices That Work
Guide your organization through its Agile transformation journey.
Create a Plan for Establishing a Business-Aligned Data Management Practice
Guide your organization through its Agile transformation journey.
Enable Shared Insights With an Effective Data Governance Engine
Empower data-driven decisions for operational excellence.
Use this icon to help direct you as you navigate this research
Use this icon to help guide you through each step of the blueprint and direct you to content related to the recommended activities.

This icon denotes a slide with an associated activity. The activity can be performed either as part of your project or with the support of Info-Tech team members, who will come onsite to facilitate a workshop for your organization.
Info-Tech offers various levels of support to best suit your needs
DIY Toolkit |
Guided Implementation |
Workshop |
Consulting |
"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful." | "Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track." | "We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place." | "Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project." |
Diagnostics and consistent frameworks used throughout all four options
Governance and Management of Enterprise Software Implementation – project overview
1. Assess | 2. Prepare | 3. Govern and Course Correct | |
---|---|---|---|
![]() Best-Practice Toolkit |
1.1 Establish Your Starting Point1.2 Governance Structure1.3 Define Your Metrics |
2.1 Establish Your Backlog2.2 Build Your Teams2.3 Assess Readiness |
3.1 Govern and Manage3.2 Transition |
Guided Implementations |
|
|
|
![]() Onsite Workshop |
Module 1:
Set Strategic Expectations and Realistic Goals |
Module 2:
Prepare Your Teams and Requirements for Execution |
Module 3:
Govern and Course Correct the Implementation and Prepare for the Transition of Operation |
Phase 1 Outcome:
|
Phase 2 Outcome:
|
Phase 3 Outcome:
|
Workshop Overview
Contact your account representative or email Workshops@InfoTech.com for more information.
Workshop Pre-work | Workshop Day 1 | Workshop Day 2 | Workshop Day 3 | Workshop Day 4 | |
---|---|---|---|---|---|
Activities |
Set Up for SuccessP.1 Executive commitment. P.2 List of requirements. P.3 Selection complete. P.4 Implementation partner on board |
Define Clear Goals and Objectives, Governance, and Metrics1.1 Establish your starting point. 1.2 Set up your governance structure. 1.3 Define key success metrics. |
Establish Your Project Backlog2.1 Establish your backlog. 2.2 Build your team. 2.3 Assess your readiness. |
Govern and Course Correct3.1 Compile the dashboard. 3.2 Review your backlog. 3.3 Mitigate failure with scenario planning. |
Transition4.1 Build the transition checklist. 4.2 Review governance document and the implementation plan. |
Deliverables |
|
|
|
|
|
Phase 1: Assess
Phase 1 outline

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Guided Implementation 1: Assess
Proposed Time to Completion: 3 weeks
Step 1.1: Establish Your Starting Point | Step 1.2: Governance Structure | Step 1.3: Define Your Metrics |
---|---|---|
Start with an analyst kick-off call:
|
Review findings with analyst:
|
Finalize phase deliverable:
|
Then complete these activities…
|
Then complete these activities…
|
Then complete these activities…
|
With these tools & templates:
|
With these tools & templates:
|
With these tools & templates:
|
Phase 1 Results & Insights
|
Step 1.1: Establish Your Starting Point
PHASE 1 |
PHASE 2 |
PHASE 3 |
|||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Explicitly define your business objectives.
- Identify the key stakeholders.
- Establish your success criteria.
This step involves the following participants:
- Executives
- Delivery lead
- Stakeholders
Outcomes of this step
- Goals and objectives of the project.
- Table of key stakeholders.
- Key success metrics.
Glossary of terms
Project management practices, and in particular Agile practices, have a language all their own. The following list is not exhaustive, but it is intended to help everyone agree on the meaning of certain terms.
- Product Backlog Item (PBI) – A requirement that has been added to the list of work to complete.
- System Integrator (SI) – The vendor/partner assisting with the installation and set up of the enterprise software.
- Iteration (or sprint) – A time-boxed period of work during which tasks are worked on to completion. No task should take longer than the defined period.
- Iteration (or sprint) Team – A cross-functional team that works together for one or more iterations to complete PBIs.
- Scrum Master (SM) – The scrum master is a facilitator who helps iteration teams overcome road blocks.
- Epic – A very high-level requirement that may represent a module of the proposed system or an end-to-end business process (e.g. accounts payable [module] or procure to pay [end-to-end business process]).
- User Story – A business requirement identified during the selection process.
- Delivery Lead – We will use this role as a generic placeholder. In your organization this may be a project manager, an Agile coach, product manager, or some other role.
- (Delivery) Team – To avoid project or Agile connotations we will refer to any and all teams by the generic “Team.” If there is a specific team referenced then it will be noted, e.g. operations team.
- Subject Matter Expert (SME) – Business and technical leaders who have specialized knowledge needed by the project team, e.g. enterprise architect.
- Product Owner – This role is the business owner of the backlog. This role can be fulfilled by the delivery lead, a dedicated product owner, or some other role.
- Agile Coach – An Agile coach is someone with broad experience implementing and running Agile processes.
Info-Tech Insight
Create your own glossary of terms that is accessible to the entire enterprise. This will ensure everyone has a common understanding of terms used.
A successful software implementation provides more than immediate business value; it can build competitive advantage
When software projects fail, they can jeopardize an organization’s financial standing and reputation, and in some severe cases can bring the company down altogether.
Rarely do projects fail for a singular reason, but by understanding the pitfalls, developing a risk mitigation plan, closely monitoring risks, and self-evaluating against where you should be during critical milestones, you can increase the probability of delivering on time, on budget, and per the intended benefits.
Benefits are not limited to just delivering on time. Some others include:
- Building organizational delivery competence and overall agility.
- The opportunity to start an inventory of best-practices, eventually building them into a center of excellence.
- Developing a competitive advantage by maximizing software value and continuously transforming the business.
- An opportunity to develop a competent pool of staff capable of executing on projects and managing organizational change.
Exercise: Review your goals and objectives for the implementation
1.1.1 – 30 minutes
INPUT: Business strategy, Business vision
OUTPUT: Record results in section one of the Governance Model Charter Template
Materials: Whiteboard, Markers
Participants: Executives, Delivery lead, Stakeholders
The aim of this exercise is to affirm/develop strategic requirements for the application. Record the results in section one of the Governance Model Charter Template. To assist in forming your goals, answer the following questions:
- What are the major coverage points?
- Who will be using the systems?
- How will different users interact with the systems?
- What are the objectives that need to be addressed?
- Where do we start?
- Where do we draw the line?
Sample
Goal | Goal Statement |
---|---|
Cut costs | To reduce the overall operating cost of the portfolio – directly through license and vendor management and indirectly through process improvements. |
Info-Tech Insight
By including the goals and objectives in the Governance Model Charter Template, the project team is reminded that the focus is the business value delivered not the technology.
Understand how to navigate the complex web of stakeholders
Identify which stakeholders to include and what their level of involvement should be during requirements elicitation based on relevant topic expertise.
Sponsor | End User | IT | Business | |
---|---|---|---|---|
Description | An internal stakeholder who has final sign-off on the project. | Front-line users of the technology. | Back-end support staff who are tasked with project planning, execution, and eventual system maintenance. | Additional stakeholders that will be impacted by any technology changes. |
Examples |
|
|
|
|
Value | Executive buy-in and support is essential to the success of the project. Often, the sponsor controls funding and resource allocation. | End users determine the success of the system through user adoption. If the end user does not adopt the system, the system is deemed useless and benefits realization is poor. | IT is likely to be responsible for more in-depth requirements gathering. IT possesses critical knowledge around system compatibility, integration, and data. | Involving business stakeholders in the requirements gathering will ensure alignment between HR and organizational objectives. |
Large-scale projects require the involvement of many stakeholders from all corners and levels of the organization, including project sponsors, IT, end users, and business stakeholders. Consider the influence and interest of stakeholders in contributing to the requirements elicitation process and involve them accordingly.
EXAMPLE: Stakeholder involvement

Exercise: Identify your key stakeholders

INPUT: Organization chart
OUTPUT: Record results in section 7 of the Governance Model Charter Template
Materials: Whiteboard, Markers, Sticky notes
Participants: Executives, Delivery lead
Using the example below, identify your key stakeholders. Record the results in section seven of the Governance Model Charter Template.
Customer | End Users | IT | Vendor | Other | |
---|---|---|---|---|---|
Description | An internal stakeholder who has final sign-off. | Front-line users of the technology. | Back-end support staff who are tasked with maintaining and upgrading the system. | Organization that develops and licenses the software deployed at the business. | Other unique stakeholders in your organization that you should consider as they interact with application. |
Examples |
|
|
|
|
|
Value | Customer buy-in and support is essential to the success of the project.
Often, the customer controls funding and resource allocation. |
End users determine the success of the system through user adoption.
If the end user does not adopt the system, the system is deemed useless and benefits realization is poor. |
IT is likely to be responsible for more in-depth requirements gathering.
IT possesses critical knowledge around system compatibility, integration, and data. |
The vendor and implementation partners will provide insight throughout the strategy and roadmap.
Ensure you review the vendor product roadmap. |
Involving all unique stakeholders in requirements gathering will incorporate a variety of perspectives and will help ensure all stakeholder needs are met. |
Focus on the why to ensure success
Your organizational goals will guide the expectations for the new enterprise software.
This is your company so focus on your goals for the enterprise software. Adopting the success metrics of someone else’s company may not help yours succeed.
SampleGoal | Goal Statement | KPI |
---|---|---|
Cut costs | To reduce the overall operating cost of the portfolio – directly through license and vendor management and indirectly through process improvements. | Ten percent reduction in year-over-year spend. |
Manage support | Reduce the burden on the IT support staff – leverage vendor and outsource where possible. | Five percent IT budget allocated to internal support. |
Manage vendors | Maintain a manageable number of vendors; use a single source wherever possible unless there is a distinct business need to extend outside application. | One main vendor and up to five supporting process vendors per operating model. |
Justify investments | Look closely at opportunities to innovate and manage discretionary spend. | Two percent annual budget allocated to innovation. |
Address process gaps | Look for ways to improve operational efficiency by addressing any process gaps identified in operating model. |
Exercise: Define key success metrics

INPUT: Goals and objectives for implementation, Current organizational metrics
OUTPUT: Document metrics in section 14 of Governance Model Charter Template
Materials: Whiteboard, Markers
Participants: Executive steering committee, Delivery lead, Key stakeholders
- Review the goals and objectives for the implementation.
- Brainstorm metrics or KPIs that align with the identified organizational goals. Define each.
- Record results in section 14 of the Governance Model Charter Template.
Goal | Goal Statement | KPI |
---|---|---|
Cut costs | To reduce the overall operating cost of the portfolio – directly through license and vendor management and indirectly through process improvements. | Ten percent reduction in year-over-year spend. |
When creating your list of goals, be clear, concise, and specific. Be sure to determine the priority of each goal and associate it to an organizational KPI.
Info-Tech Best Practice
Leverage Info-Tech’s IT Metrics Library in the appendix for additional organizational metrics.
Step 1.2: Governance Structure
PHASE 1 | PHASE 2 | PHASE 3 | |||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Creation of your governance model.
- Assessment of your Agile capabilities.
This step involves the following participants:
- Executives
- Delivery lead
- Stakeholders
- Team – Internal and SI
- Agile coach
Outcomes of this step
- Governance model.
- Roles and responsibilities (RACI).
- Agile capabilities.
Governance is not management
Executive Governance Level |
Includes the executive project sponsor, C-level executives, and other senior members of interested parties. They are individuals with a vested interest in the project and their success and failure will be dependent on the success or failure of the implementation. They are responsible for:
|
Steering Committee Level |
Includes SVPs, VPs, and other leaders who are responsible for implementation execution and kept accountable for work quality and deliverables.
|
Team Level |
Includes the teams that are executing the tasks pulled from the backlog. Co-ordination of work and other activities such as training can be facilitated by delivery lead or a dedicated team.
|
Info-Tech Insight
You won’t get engagement unless there is a sense of accountability. Do not leave this vague. Specific individuals in your organization need to be assigned accountability to ensure the system development achieves what was intended by your organization and not what your SI intended.
The Phoenix Pay System – A failure of governance
CASE STUDY
Industry Government
Source 2018 Spring Reports of the Auditor General of Canada
Public Services and Procurement Canada
Public Services and Procurement Canada (PSPC) is the department responsible for administrating the pay of public service employees. In 2009 the Government of Canada started the Transformation of Pay Administration program, which would centralize pay services and switch to a new pay software.
The Phoenix Pay System
After a public competition, PSPC awarded a contract to IBM to customize a PeopleSoft commercial pay software to meet the government’s needs. Three executives at PSPC were responsible for delivering the pay system while the Deputy Minister of the Department was responsible for that governance and monitoring was in place, documented, and maintained.
Results
There was no independent oversight of the Phoenix project, which allowed the executives to implement the system even though they knew it had significant problems. The Deputy Minister of PSPC was dependent on information that was provided by the project executives so the Minister did not get the information showing that Phoenix was not ready for implementation. The executives were more focused on meeting the project budget and timeline than on what the system needed to do.
Chart showing only the executives provided project status to the Deputy Minister.
Exercise: Define your governance structure
1.2.1 – 1-2 hours
INPUT: Goals and objectives, Key success metrics
OUTPUT: Complete section two of the Governance Model Charter Template
Materials: Whiteboard, Markers
Participants: Executives, Delivery lead, Team – Internal and SI
This exercise is about developing an implementation operating model up front. Any questions and decision making during implementation should always refer back to goals and objectives. Stakeholders from all levels of the established governance structure need to be unified in their support of each goal and objective. Complete section two of the Governance Model Charter Template after working through the following questions.
- To what degree can the business use standard software functionality and avoid customizations, unless there is a compelling reason to do so?
- Who will be accountable for making sure the system will benefit the organization?
- What decision rights will the different governance layers, delivery lead, and the teams have?
- Does the organization wish to parallel existing business processes in the new system or attempt to achieve major business transformation (process modernization/evolution vs. revolution)?
Info-Tech Insight
It is critical that all participants with decision-making authority and influence, including the SI, firmly agree to the goals and objectives and are committed to upholding them throughout the implementation.
Who is accountable?
Too many assumptions are made that the SI is accountable for all implementation activities and deliverables – this is simply untrue. All activities can be better planned for, and misunderstandings can be avoided, with a clear line of sight on roles and responsibilities and the documentation that will support these assumptions.
Discuss, define, and document roles and responsibilities:
- For each role (e.g. executive sponsor, delivery manager, test lead, conversion lead) clearly articulate the responsibilities of the role, who is accountable for fulfillment, and whether it’s a client role or SI role, or both.
- For each deliverable, articulate the purpose of the deliverable clearly and define which individual or team has responsibility for the deliverable and who is expected to contribute.
- Empower the team by granting them the authority to make decisions. Ease their reluctance to think outside the box for fear of stakeholder or user backlash.
- The implementation cannot and will not be transformative if the wrong people are involved, or if the right people have not been given the tools to succeed in their role.
Exercise: Define roles and responsibilities
1.2.2 – 1 hour
INPUT: Stakeholders list
OUTPUT: Complete section seven of the Governance Model Charter Template.
Materials: Whiteboard, Markers
Participants: Executives, Delivery lead, Key stakeholders, SI lead
Instructions
- Assess the skills necessary for an enterprise implementation. Inventory the competencies required for an enterprise implementation team. Map your internal resources to each competency as applicable.
- Select your internal implementation team. Determine who needs to be involved closely with the implementation. Key stakeholders should also be considered as members of your implementation team.
- Identify the number of external consultants/support required for implementation. Consider your in-house skills, timeline considerations, integration environment complexity, and cost constraints as you make your resourcing plan. Be sure to dedicate an internal resource to manage vendor and partner relationships.
- Document the roles and responsibilities, accountabilities, and other expectations as they relate to each step of the implementation.
- Document results in section seven of the Governance Model Charter Template.
How capable are you at being Agile?
After many years of helping Agile teams, James Shore and Diana Larsen learned a lot about what it takes to succeed with Agile and why many organizations don’t see the expected benefits. In 2012 they took that experience and the Agile Fluency Project was born. They identified four different areas, or zones as they call them, of capability. The key here is to understand that this is not a maturity model; it is a capability model. Each organization is unique and will have different levels of skill or fluency in each area. The model cannot tell you how mature your organization is in its use of Agile. (Source: ThoughtWorks, 2012)

Zone | Benefit | Investment | Learn From | Time to Fluency |
---|---|---|---|---|
Focusing | Greater visibility into teams’ work; ability to redirect. | Team development and work process design. | Scrum, Kanban, non-technical XP | 2-6 months |
Delivering | Low defects and high productivity. | Lowered productivity during technical skill development. | Extreme Programming, DevOps movement | +3-24 months |
Optimizing | Higher-value deliveries and better product decisions. | Social capital expended on moving business decisions and expertise into team. | Lean Software Development, Lean Startup, Beyond Budgeting | +1-5 years |
Strengthening | Cross-team learning and better organizational decisions. | Time and risk in developing new approaches to managing the organization. | Organization design and complexity theories | unknown |
How Agile are you?
Key principle: Agility is not a set of practices; it is a mindset. Alistair Cockburn said, “…we wouldn’t ask ‘can I use agile here’, but … ‘how agile can we be, here?’” (Source: Practical Analyst, 2018)
Applying the key principle:
Agile practice has the highest success rate, but it is up to you to determine where your organization can operate on the spectrum between Waterfall and Agile.
← Waterfall — — — — | — — — — — — — — — | — — — — Agile → |
Full Waterfall | Custom Practice | Agile Practice |
Works well for small project that have few unknowns. | Helps projects survive the surfacing of unknowns. | Best for projects with unknown unknowns. |
|
|
|
Info-Tech Insight
If you are new to Agile we recommend engaging a coach to accelerate your progress and assist you in avoiding the common pitfalls of implementing Agile.
Exercise: Assess your current capabilities in delivery
1.2.3 – 1-2 hours
INPUT: Agile frameworks, Project management practices
OUTPUT: Current delivery capabilities
Materials: Whiteboard, Markers
Participants: Delivery lead, Team, Agile coach
- Identify your current project practices and map them using the table below.
- Determine the number of unknowns in your implementation. Use Agile if your number of unknowns is high.
Sample
← Waterfall — — — — | — — — — — — — — — | — — — — Agile → |
Full Waterfall | Custom Practice | Agile Practice |
Works well for small project that have few unknowns. | Helps projects survive the surfacing of unknowns. | Best for projects with unknown unknowns. |
|
|
|
Step 1.3: Define Your Metrics
PHASE 1 | PHASE 2 | PHASE 3 | |||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Define your delivery metrics.
This step involves the following participants:
- Key stakeholders
- Delivery lead
- Team
Outcomes of this step
- Delivery metrics.
Building leading indicators
Lagging KPIs are relatively simple to identify, whereas leading KPIs can be more elusive.
For example, take the lagging KPI “Customer Satisfaction.” How do you turn that into a leading KPI? One method is to look at sources of customer complaints. In a retail sales system, backordered items will negatively impact customer satisfaction. As a leading indicator, track the number of orders with backordered lines and the percentage of the total order that was backordered.
Toronto Raptors acquire Kawhi Leonard![]() Making |
Kawhi Leonard named NBA Finals MVP![]() Reporting |
Performance Metrics
Use leading and lagging metrics, as well as benchmarks, to track the progress of your system.
- Leading KPIS: Input-oriented measures:
- Number of active users in the system.
- Time-to-completion for processes that previously experienced efficiency pain points.
- Lagging KPIS: Output-oriented measures:
- Faster production times.
- Increased customer satisfaction scores.
- Benchmarks: A standard to measure performance against:
- Number of days to ramp up new user.
Info-Tech Insight
“Leading indicators make the news; lagging indicators report on the news.” (Carlos Sanchez, Senior Director, Enterprise Applications, Info-Tech)
Review examples of popular metrics
In addition to delivery metrics and system performance metrics, equip the business with process-based metrics to continuously prove the value of the enterprise software. Review the examples below as a starting point.
SampleMetric | Description |
---|---|
Percent of requirements complete | This is often represented by a burndown chart in Agile projects. |
Issues found | Total number of issues found within a given time period such as one iteration. |
Issues resolved | Total number of issues resolved. |
Percent of processes complete | This metric represents full workflows such as procure-to-pay or quote-to-cash. |
Exercise: Define your metrics
1.3.1 – 1-2 hours
INPUT: Key success metrics
OUTPUT: Defined metrics
Materials: Whiteboard, Markers
Participants: Key stakeholders, Delivery lead, Team
- Gather any metrics related documentation that you collected during your requirements gathering.
- Collect team-level metrics for your existing teams:
- Examine outputs from any feedback mechanisms you have (satisfaction surveys, emails, existing SLAs, burndown charts, resourcing costs, licensing costs per sprint, etc.).
- Look at historical trends and figures when available. Be careful of frequent anomalies as these may indicate a root cause that needs to be addressed.
- Explore the definition of specific metrics across different functional teams to ensure consistency of measurement and reporting.
Sample
Metric | Description |
---|---|
Percent of requirements complete | This is often represented by a burndown chart in Agile projects. |
Issues found | Total number of issues found within a given time period such as one iteration. |
Issues resolved | Total number of issues resolved. |
Percent of processes complete | This metric represents full workflows such as procure-to-pay or quote-to-cash. |
If you want additional support, have our analysts guide you through this phase as part of an Info-Tech Workshop 
Book a workshop with our Info-Tech analysts:
![]() |
|
The following are sample activities that will be conducted by Info-Tech analysts with your team:
1.1.1 |
![]() |
Review your goals and objectives for the implementation
This activity is designed to bring everyone to the same starting point. By clearly stating your goals and objectives, all activities can be measured against how they assist in achieving those goals. |
1.3.1 |
![]() |
Define your metrics
This activity involves key stakeholders, the delivery lead, and the team to define delivery metrics. These metrics ensure the implementation remains on track to fulfill the key success metrics. |
Phase 2: Prepare
Phase 2 outline
Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.
Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Guided Implementation 2: Prepare
Proposed Time to Completion: 3 weeks
Step 2.1: Establish Your Backlog | Step 2.2: Build Your Teams | Step 2.3: Assess Readiness |
---|---|---|
Talk requirements with analyst:
| Learn about team dynamics:
| Identify readiness to implement:
|
Then complete these activities…
| Then complete these activities…
| Then complete these activities…
|
With these tools & templates:
| With these tools & templates:
| |
Phase 2 Results & Insights
|
Step 2.1: Establish Your Starting Point
PHASE 1 | PHASE 2 | PHASE 3 | |||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Build your initial backlog.
- Prioritization of your backlog.
This step involves the following participants:
- Key stakeholders
- Delivery lead
- Agile coach
Outcomes of this step
- Prioritized implementation backlog.
A backlog is more than a prioritized list: A tiered backlog organizes requirements at various stages of readiness
The DEEP backlog
- Detailed Appropriately: Items are broken down and refined as necessary for each tier.
- Emergent: Backlog grows and evolves over time as items are added and removed.
- Estimated: Effort an item requires is estimated at each tier.
- Prioritized: Items’ value and priority are determined at each tier. (Source: Perforce, 2017)

How risky is it?
While Agile will address and mitigate risk during each iteration, there is a place for traditional risk management. Some requirements, such as the introduction of a new technology, come with a higher risk and therefore should be scheduled early in the project. This will allow for the mitigation of any risk before it can significantly impact the project schedule. Thus, when prioritizing the backlog consider risk as much as business value.

By delivering the product in smaller iterations, teams reduce the amount of risk that is accumulated over time, as they validate the accuracy with each iteration. The shaded area represents the risk mitigated by teams when they deliver with smaller iterations through Agile.
Exercise: Build your backlog
2.1.1 – 1-2 hours
INPUT: Requirements
OUTPUT: Initial backlog documented in the Product Backlog Item Prioritization Tool
Materials: Whiteboard, Markers, Sticky notes
Participants: Key stakeholders, Delivery lead, Agile coach
This activity is meant to determine the common vernacular for PBIs used in your organization.
- Select an initial list of requirements as PBIs and provide a brief description of each.
- Identify on which tier or where within the backlog each PBI is intended to live.
- Enter what type of documentation is required for each PBI.
Sample
MoSCoW in your friend
Prioritization ensures that the implementation teams focus on the right requirements within the right use cases.
Prioritization is the process of ranking each requirement based on its importance to project success. Hold a separate meeting for the domain SMEs, implementation SMEs, project managers, and project sponsors to prioritize the requirements list. At the conclusion of the meeting, each requirement should be assigned a priority level. The implementation SMEs will use these priority levels to ensure that efforts are targeted towards the proper requirements and the plan features are available on each release. Use the MoSCoW Model of Prioritization to effectively order requirements.
The MoSCoW Model of Prioritization
Must Have | Requirements which must be implemented for the solution to be considered successful. |
Should Have | Requirements which are high priority that should be included in the solution if possible. |
Could Have | Requirements which are desirable but not necessary and could be included if resources are available. |
Won't Have | Requirements which won’t be in the next release but will be considered for future releases. |
Exercise: Prioritize your backlog
2.1.2 – 30 minutes
INPUT: Requirements
OUTPUT: Prioritized backlog
Materials: Whiteboard, Markers, Sticky notes
Participants: Key stakeholders, Delivery lead, Agile coach
- Based on the PBIs created, the product owner assigns a priority ranking to each PBI to determine the order in which they will be completed.
- Have your team review the PBIs and question the PBI’s value, priority, goal, risk, and meaning to better understand the needs of the requirement.
- Define “done” by defining individual acceptance criteria for each PBI.
As a people manager, I want to access employee absence information so that I can plan work
Priority: Must have
As an employee, I want to be able to request vacation so that I can plan time off.
Priority: Should have
As a project manager, I want to know planned vacation time so that I can determine sprint capacity.
Priority: Could have
Step 2.2: Build Your Teams
PHASE 1 | PHASE 2 | PHASE 3 | |||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Establish your team.
- Determine data governance and RACI.
- Build a communication plan.
This step involves the following participants:
- Delivery lead
- SI lead
- Stakeholders
- Data architect
- Communications team
Outcomes of this step
- Team composition.
- A data governance plan including a data RACI.
- Communications plan.
Understand the unique external resource considerations for the implementation
Organizations rarely have sufficient internal staffing to resource an enterprise software implementation project entirely on their own. Consider the options for closing the gap in internal resource availability.
The most common project resourcing structures for enterprise projects are:
- Your own staff +
- Management Consultant
- Vendor Consultant
- System Integrator
CONSIDER THE FOLLOWING
Internal vs. External Roles and Responsibilities
Clearly delineate between internal and external team responsibilities and accountabilities, and communicate this to your technology partner upfront.
Internal vs. External Accountabilities
Accountability is different than responsibility. Your vendor or SI partner may be responsible for completing certain tasks, but be careful not to outsource accountability for the implementation – ultimately, the internal team will be accountable.
Partner Implementation Methodologies
Often vendors and/or SIs will have their own preferred implementation methodology. Consider the use of your partner's implementation methodology; however, you know what will work for your organization.
When contemplating a resourcing structure, consider:
- Availability of in-house implementation competencies and resources.
- Timeline and cost constraints.
- Integration environment complexity.
Info-Tech Insight
Select a partner with a culture compatible with yours.
Team composition is important
Ensure inner-team communication and a high degree of trust.
Communication | Proximity | Trust |
---|---|---|
Teams must have some type of communication strategy. This can be broken into:
|
Distributed teams create complexity as communication can break down. This can be mitigated by:
|
Members should trust other members are contributing to the project and completing their required tasks on time. Trust can be developed and maintained by:
|
Info-Tech Insight
When selecting a team, include individuals with both high skill and high integrity. These leaders help keep the lines of communication open between team members and build trust.
How long do people stay on a team?
All teams go through turmoil until they figure out how to work together, if they ever do.
- Every time a team has members leave or join, it will return to the Forming stage of development.
- A culture of trust will reduce the impact of the Storming stage.
- A mature team will quickly move to Norming if the core team is stable and only ancillary members are changed.
Four Stages of Team Development
Stage | Characteristics |
---|---|
Forming | Team members test the boundaries of both interpersonal and task behaviors. |
Storming | Characterized by conflict and polarization around interpersonal issues. |
Norming | In-group feelings and cohesiveness develop. |
Performing | Interpersonal structure becomes a tool of task activities and group energy is directed to task execution. |
Exercise: Establish team composition
2.2.1 – 1-2 hours
INPUT: Skills assessment, Stakeholder analysis, Vendor partner selection
OUTPUT: Team composition
Materials: Whiteboard, Markers, Sticky notes
Participants: Delivery lead, SI lead, Stakeholders
Instructions
- Assess the skills necessary for an implementation. Inventory the competencies required for the implementation project team. Map your internal resources to each competency as applicable.
- Select your internal implementation team. Determine who needs to be involved closely with the implementation. Key stakeholders should also be considered as members of your implementation team.
- Identify the number of external consultants/support required for implementation. Consider your in-house skills, timeline considerations, integration environment complexity, and cost constraints as you make your team composition plan. Be sure to dedicate an internal resource to managing the vendor and partner relationships.
- Document the roles and responsibilities, accountabilities, and other expectations of your team as they relate to each step of the implementation. Track results in section nine of the Governance Model Charter Template.
Data stewards
Data stewards:
- Champion business person accountable for data quality in their particular area.
- Serve on an operational level addressing issues related to adherence to standards/procedures, monitoring data quality, raising issues identified, etc.
- Manage access, quality, escalating issues, etc.
To obtain both buy-in and commitment, determine who the data governance champions are within the organization and get them onboard with the project first. These people will most likely be business leaders and data owners most affected by data governance issues.
Info-Tech Best Practice
A stewardship role is generally more about managing the cultural change that data governance brings. This requires the steward to have exceptional interpersonal skills that will assist in building relationships across departmental boundaries and ensuring that all stakeholders within the organization believe in the initiative, understand the anticipated outcomes, and take some level of responsibility for its success.
Understand how data flows through your organization from an enterprise application perspective
Understanding where data lives can be challenging as it is often in motion and rarely resides in one place. There are multiple benefits that come from taking the time to create a data flow diagram.

Create a Plan for Establishing a Business-Aligned Data Management Practice
Make sure the right information gets to the right people, at the right time.
Enable Shared Insights With an Effective Data Governance Engine
Empower data-driven decisions for operational excellence.
Exercise: Data change simulation
2.2.2 – 30 minutes
INPUT: Data strategy and management plan
OUTPUT: Data RACI
Materials: Whiteboard, Markers
Participants: Data architect, Delivery lead, Technical SMEs
- Determine the roles that may require data changes.
- Record who has the authority to approve the change.
- Define a RACI for your data activities.
Type of Change | Approval Level | Documentation |
---|---|---|
Add element to picklist | Team | Update user documentation |
Modify existing data element | Data architect | Record in change log |
Add new data element | Data architect | Record in change log |
Are you getting through to your stakeholders?
Let’s jump into the future. Your implementation is in full swing and you are sharing the status via email, dashboard, and song and dance during company town halls. The challenge is that the business is not engaging as fully as necessary and this is slowing down your teams and putting the project at risk. In the table below, we have some forms of communication and possible solutions to increase business engagement.
Communication Form | Example | Disengagement Mitigation |
---|---|---|
A bi-weekly email summarizing the project status sent to all staff. Focus on the wins since the last email and highlight staff who really contributed. Be sure to include business stakeholders whenever possible. | Have the CEO and other senior leaders reply to all with a positive message about the great job being done and how it is really helping the business succeed. | |
Iteration planning meeting | At the beginning of each iteration you will have an iteration planning meeting. It is critical that business stakeholders be part of the conversation. Often, the business will be late or not show up at all as it sees it as an “IT only” effort. | Have the CEO or C-level executives join for the first five minutes to extoll the virtues of the project and its value to the business. They can show their appreciation for the priority that the group is giving to the important project. |
Leverage Info-Tech’s Manage Stakeholder Relations blueprint to make proper stakeholder management a habit.
Exercise: Build a communication plan
2.2.3 – 1 hour
INPUT: Backlog, High-level implementation timeline
OUTPUT: Communication plan
Materials: Whiteboard, Markers, Sticky notes
Participants: Delivery lead, Communications team
Create a communication plan similar to the table below. Be sure to include the major points to be communicated via each form. It is okay to repeat yourself. In fact, it helps reinforce the message.
Sample
Medium | Frequency | Content | Disengagement Mitigation |
---|---|---|---|
Bi-weekly |
|
Have business leaders reply to all with positive messages | |
Town halls | Monthly |
|
Recognize top contributors from different parts of the business. Consider giving out prizes such as coffee mugs. |
Iteration demos | Every two weeks (at the end of each iteration) |
|
Record and share the demos on an internal site for all to view. |
Step 2.3: Assess Readiness
PHASE 1 | PHASE 2 | PHASE 3 | |||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Run a test iteration with a daily standup.
- Practice a team demo and retrospective.
This step involves the following participants:
- Delivery lead
- Team
- Agile coach
Outcomes of this step
- The team has an understanding of how iterations fit into execution.
Bringing it all together
Agility comes in many forms. It is often associated with software development, but agility goes beyond that narrow focus. For example, Handelsbanken of Sweden and Statoil of Norway are Agile organizations and have been so for many years.
Info-Tech’s CLAIM model is based on concepts of agility that are not just for software development; they are for the entire enterprise. In this particular case, we have replaced “A” for automation with “D” for data as it is critical to the implementation.
Culture. Agile teams believe that value is best created by standing, self-organizing cross-functional teams who deliver sustainably in frequent, short increments supported by leaders who coach them through challenges.
Learning. Agile is a radical change in how people work and think. Structured, facilitated learning is required throughout the transformation to help leaders and practitioners go from doing Agile to being Agile.
Data. Manage your data and its integrity to prepare for conversion. Appoint data stewards to guide data governance and management.
Integrated Teams. While temporary project teams can get some benefits from Agile, standing, self-organizing teams that cross business, delivery, and operations are essential to gain the full benefits of Agile.
Metrics and Governance. Successful Agile implementations require the disciplined use of delivery and operations metrics that support governance focused on developing better teams.
Have an iteration planning session to establish scope and estimates for your upcoming iterations
Planning takes time – don’t rush this step.
- The product owner and team review the product backlog and release plan, and discuss the high-priority items that must be completed for the upcoming milestone.
- Break your requirements down into smaller individual tasks. Use point estimation (see sidebar) to size the tasks
- Some tools (e.g. Team Foundation Server) estimate tasks by hours and not points. In this situation, consider estimating your tasks in hours and then rolling them up into points at a higher level.
- Adjust your plan based on the issues, risks, and tasks that were identified. Remember to leave a bit of buffer in your plan to accommodate unexpected impediments.
- Break down your milestone into iterations that range from one to four weeks in length. Iteration lengths should be consistent within a given project. Identify the requirements that can be completed within a given sprint and shift your milestones and release plan if necessary.
- Ideally, demonstrable business value should be deliverable at the end of a sprint.
- It is common for new tasks to emerge as the team works through each sprint. Once the team makes a commitment, additions and changes must wait until the next sprint unless approved by the product owner.
Point Estimation Scheme
Consider the following points paradigm for new teams: 1 point ~ 1 hour, 3 points ~ 0.5 day, 7 points ~ 1-2 days, 13 points ~ 3-4 days. Modify this scheme as necessary.
As teams become more accustomed to this approach, begin transitioning from a days-to-points conversion to tasks-to-points (e.g. code a button on the web UI = 3 points).
Understand the common strategies to a vertical breakdown approach
How do you determine how small a task should be?
There is no hard and fast rule to how small an item must be. This will depend on:
- The length of the iteration.
- The size of the application or project.
- The experience and comfort level of the team.
It will take new Agile teams a few iterations before they find their momentum.
1. Workflow steps?
What steps does a user perform? Are all of the steps necessary now? Can steps be simplified for now? Steps in an order process, like selecting a payment option or delivery method. |
2. Business rules?
What rules apply to this story? Are all business rules necessary now? Can simpler rules suffice? Rules in order process (no order below ten dollars, no shipping outside the US). |
3. Happy/Unhappy flow?
What does the happy/unhappy flow look like? Are all unhappy flows necessary (right now)? Can unhappy flows be simplified (for now)? Failures during a webshop order process and possible recovery options. |
4. Input options?
Which platforms are supported? Are all platforms required (right now)? Are some platforms harder to implement than others? Tablet, iPhone, desktop, touchscreen. |
5. Data types and parameters?
What data types are supported and relevant? Which parameterized views are there? Are all parameters relevant at the moment? Different search options/strategies or report types (e.g. tables, graphs). |
6. Operations?
What operations does the story entail? Are all operations necessary right now? Breakdown on CRUD (create, read, update, delete). |
7. Test cases?
What tests scenarios are used to verify this story? Are all test scenarios relevant at the moment? Some test scenarios may be very complex, but not highly relevant at this time |
8. Optimize now vs optimize later?
What optimizations can we think of (UX/UI)? Are all optimizations necessary now? Implementing autocomplete for addresses, usage of GPS-location. |
Exercise: Iteration planning
2.3.1 – 30 minutes
INPUT: Groomed implementation backlog
OUTPUT: Iteration backlog
Materials: Whiteboard, Markers, Sticky notes
Participants: Team, Delivery lead, Agile coach
- Refer back to the PBIs added in Activity 2.1.2.
- Choose a vertical break-down strategy that the team is comfortable with.
- List all possible tasks associated with each PBI in the backlog.
As a people manager, I want to access employee absence information so that I can plan work
Priority: Must have
Tasks:
- Capture the data.
- Store the data in a database (could be a separate story, could be broken down).
- Create a means to access the information online.
- Provide means to print the information.
- Ensure security measures are in place to protect information.
As an employee, I want to be able to request vacation so that I can plan time off.
Priority: Should have
Tasks:
- Create a means to enter the request.
- Create a means to modify the request.
- Create a means to delete the request.
As a project manager, I want to know planned vacation time so that I can determine sprint capacity.
Priority: Could have
Tasks:
- Provide a means to access employee absence data for a specific project.
- Provide a means to retrieve employee absence data for a specific project.
- Provide a means to report when new requests are entered for a specific project.
Conduct a daily standup session during development to measure progress
- Use the daily standup session to surface any blockers or risks that could impact completing committed tasks.
Rules of the Standup | Topic of the Standup | Goal of the Standup |
---|---|---|
|
Three things should be reported by each team member in a standup meeting:
|
|
Exercise: Build your task board and simulate a daily standup
2.3.2 – 30 minutes
INPUT: User stories in sprint backlog
OUTPUT: Task board
Materials: Whiteboard, Markers, Sticky notes
Participants: Team, Scrum master, Agile coach
- Identify and select a location for the team’s task board.
- Set up the team task board by vertical columns for to do, in progress, tested, and done.
- Add your committed user stories to the task board along with their relevant tasks.
- Simulate a daily standup, facilitated by the scrum master by answering the three questions:
- What did I do yesterday?
- What am I going to do today?
- Are there any roadblocks?
Ensure alignment with stakeholder expectations through demonstrations
Involve stakeholders and management in your plan by including them in demonstrations – their constructive feedback will ensure the implementation is moving in the right direction. Aim to deliver demonstrable business value each iteration.
Showcase your progress for stakeholders to obtain feedback on enhancements or to modify, add, or remove features to meet new business needs.
- Identify key points in your release plan to schedule demonstrations with stakeholders. These points (ideally, at your project milestones) should demonstrate some business value in your solution. Find a balance between the frequency of your demonstrations and your stakeholders’ availability.
- Focus on demonstrating features that are complete. If you are planning on showing work-in-progress, ensure that your stakeholders understand what they see may change.
- Leverage a proxy if your stakeholders or product owners are unavailable. Ensure that this proxy is up to date with the latest stakeholder needs and engages in regular communication with stakeholders.
- Collaborate with your stakeholders on the enhancements so the changes can be injected and prioritized against your product backlog. Assess and address any impacts these changes have on your release.
Hold an iteration retrospective to identify and document issues to be resolved
Aim to learn from past mistakes and pain points, and apply lessons to future iterations.
- The iteration retrospective differs from the iteration review because it is not project-oriented, but process-oriented.
- This step is important in improving the process as each team member has a chance to voice what is working and what is not.
- The scrum master can act as a facilitator for these meetings.
Questions to Ask During Your Retrospectives
- What did you like about the iteration?
- What were you lacking during the iteration?
- What did you learn?
- What do you desire to help improve the process?
Info-Tech Insight
Think of the first iteration as a test run. After the first iteration, the team members should have a better idea of their capacity and what they can realistically achieve in one iteration.
Exercise: Simulate a demo
2.3.3 – 1 hour
INPUT: Task board built in previous exercise
OUTPUT: Demo
Materials: Whiteboard, Markers
Participants: Team, Delivery lead, Stakeholders
- Refer back to the user stories each team committed to for the sprint, and prepare a wireframe for the acceptance criteria to prove you are done.
- Practice showcasing the wireframe within your team and center your story around a realistic user solving a problem. Keep in mind that the demo must prove not only that the software works, but also that it is valuable.
- Teams take turns presenting their demos to other stakeholders and stakeholders choose one option based on the demo:
- Approve
- Reject
- Request for change (goes into future a sprint)
Exercise: Simulate a retrospective
2.3.4 – 30 minutes
INPUT: Activities done that day
OUTPUT: List of action items
Materials: Whiteboard, Markers, Sticky notes
Participants: Team, Scrum master, Agile coach
- Identify a retrospective approach that the team agrees upon and wants to use as part of their Agile practices.
- Set up any materials (e.g. sticky notes, pens) that the team will require to simulate a retrospective.
- With the scrum master facilitating, conduct a retrospective on the day’s activities you participated in to understand Agile practices.
- Document any action items on how the team can improve.
If you want additional support, have our analysts guide you through this phase as part of an Info-Tech Workshop 
Book a workshop with our Info-Tech analysts:
![]() |
|
The following are sample activities that will be conducted by Info-Tech analysts with your team:
2.1.1 |
![]() |
Establish your backlog
Convert your list of requirements into a prioritized list of high-level tasks for the implementation team to execute. |
2.3.1 |
![]() |
Assess your readiness
This step takes the team through a simulated iteration cycle to familiarize them with the process. |
Phase 3: Govern and Course Correct
Phase 3 outline
Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.
Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.
Guided Implementation 3: Govern and Course Correct
Proposed Time to Completion: 2+ weeks
Step 3.1: Govern and Manage | Step 3.2: Transition |
---|---|
Discuss the implementation cadence:
|
Discuss how to transition to operation:
|
Then complete these activities…
|
Then complete these activities…
|
With these tools & templates:
|
With these tools & templates:
|
Phase 2 Results & Insights
|
Step 3.1: Govern and Manage
PHASE 1 | PHASE 2 | PHASE 3 | |||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Compiling an implementation dashboard.
- Grooming the backlog.
This step involves the following participants:
- Delivery lead
- Executives
Outcomes of this step
- An implementation dashboard.
- Updated backlog based on feedback from last iteration.
Dashboards are concise for a reason
Build a dashboard that reflects the leading metrics you have identified. Call out requirements that represent key milestones in the implementation.
Sample

Exercise: Compile status report
3.1.1 – 1 hour
INPUT: Backlog, Iteration plan, Delivery metrics
OUTPUT: Build your dashboard using the Governance Dashboard Template
Materials: Whiteboard, Markers, Sticky notes
Participants: Executives, Delivery lead, Stakeholders
- Develop a dashboard that quickly summarizes the information the executives are interested in. Use Info-Tech’s Governance Dashboard Template to help build your dashboard.
Sample
Business priorities change – can you?
Often backlog grooming is used interchangeably with, or considered a part of, sprint planning. The reality is that while they are very similar and have the same required participants and objectives there are some key differences.

Exercise: Review backlog

INPUT: Existing backlog, New and/or modified requirements
OUTPUT: Table of backlog responsibility to review and expected cadence
- Review the activities of your idea or work request intake process.
Examples: split epics, write user stories, estimate, valuate, add to backlog. - Identify who needs to be involved and their type of involvement for each activity using the following categories:
- Responsible: Individual responsible for executing or capturing the results of the activity.
- Facilitator: Individual who facilitates the discussion between participants according to the standards of the activity.
- Required participants: Roles and perspectives integral to completion of the activity.
- As-needed participants: Roles and perspectives that can be needed under certain circumstances of the activity.
- Identify the cadence of the activity. This can be expressed as:
- Frequency of the activity: Every quarter.
- Trigger for the activity: On demand as a request or when a new idea is presented.
- Other established meetings or ceremonies where the activity would take place: PI planning.
Exercise: Review backlog (continued)

Below is a sample table of activities, participants, and cadence.
SampleActivities | Participants | Cadence | |||
---|---|---|---|---|---|
Responsible | Facilitator | Required Participants | As Needed Participants | ||
Split Epics | Product Owner | Scrum Master | Project Team | Solution Architects, Business Stakeholders | On Demand as Epics Are Qualified |
Write User Stories | Product Owner | Backlog Grooming | |||
Estimate | Product Owner | Backlog Grooming | |||
Valuate | Product Owner | Backlog Grooming | |||
Prioritize, Inject Into Backlog, and Update Roadmap | Product Owner | N/A | Product Manager | PI Planning |
Step 3.2: Transition
PHASE 1 | PHASE 2 | PHASE 3 | |||||
1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 |
Establish Your Starting Point | Governance Structure | Define Your Metrics | Establish Your Backlog | Build Your Teams | Assess Readiness | Govern and Manage | Transition |
This step will walk you through the following activities:
- Create different implementation end states.
- Establish a transition checklist detailing the items required to transition the implementation to operation.
This step involves the following participants:
- Executives
- Delivery lead
- Team
Outcomes of this step
- Scenario descriptions of the risks or activities that can result in various outcomes (success or failure).
- A transition checklist which will be used by the executive steering committee to determine whether the implementation is ready to transition to operation.
Disaster planning for success
Scenario planning is a technique that has been used for many years not only in business but also in others areas such as the military.
The goal of scenario planning is to identify a future state and come up with actions that will mitigate or accelerate the organization ending up in that state.

Royal Dutch Shell has been using scenario planning for 50 years to successfully navigate an uncertain future. Scenario planning, imagining an alternate future, activates the same areas of the brain as memory. The idea is that having “lived” through the scenario, the organization will have learned how to avoid or recover from it. (Source: Shell, 2019)
Exercise: Imagine your implementation future state
3.2.1 – 1-2 hours
INPUT: Success metrics, Risk log
OUTPUT: Scenario descriptions of various failures
Materials: Whiteboard, Markers
Participants: Executives, Delivery lead, Team
- Imagine it is a year from now. Think of three possible scenarios: the implementation was wildly successful, the implementation met expectations, and the implementation was a complete disaster.
- Begin with the failure scenario or where a risk has been realized. Describe fully the state of the failure and the effect upon the organization. Identify the changes that could have lead to that state (loss of key resources, failure of governance, technology problems, etc.).
- Now imagine the implementation was wildly successful. Again, fully describe the end state and the effect on the organization. Describe the behaviors, metrics and risk mitigations that led to this outcome.
How do you transition?
Deciding when to turn the system on can be a complex question. While looking at the requirements implemented is one aspect of readiness, there are many more factors to consider. Executive commitment and business readiness are just as important to the transition as getting all the testing done.
Use Info-Tech’s Enterprise Software Implementation Checklist Tool to help assess your readiness.

Sample
Criteria | Answer |
---|---|
Application Readiness: | |
Have all test scenarios and scripts been executed? | Yes |
Have the pre-determined pass rates been achieved for each stage of the testing? | Yes |
Management Sponsorship: | |
Is there commitment/buy-in from the business? | Yes |
Is there commitment from the steering committee and sponsors? | Yes |
People/Process Readiness: | |
Have impacted groups been made aware of the changes coming as a result of the project? Do they understand the impact of change? | Yes |
Data Readiness: | |
Has the data in each source system for data conversion activities been cleansed? | Yes |
Exercise: Transition checklist
3.2.2 – 1 hour
INPUT: Delivery metrics
OUTPUT: Customize the Transition tab of the Enterprise Software Implementation Checklist Tool
Materials: Whiteboard, Markers
Participants: Executives, Delivery lead, Teams
- Create your transition checklist.
- Record your checklist in the Enterprise Software Implementation Checklist Tool.
Sample
Criteria | Answer |
---|---|
Application Readiness: | |
Have all test scenarios and scripts been executed? | Yes |
Have the pre-determined pass rates been achieved for each stage of the testing? | Yes |
Management Sponsorship: | |
Is there commitment/buy-in from the business? | Yes |
Is there commitment from the steering committee and sponsors? | Yes |
People/Process Readiness: | |
Have impacted groups been made aware of the changes coming as a result of the project? Do they understand the impact of change? | Yes |
Data Readiness: | |
Has the data in each source system for data conversion activities been cleansed? | Yes |
If you want additional support, have our analysts guide you through this phase as part of an Info-Tech Workshop 
Book a workshop with our Info-Tech analysts:
![]() |
|
The following are sample activities that will be conducted by Info-Tech analysts with your team:
3.2.1 |
![]() |
Govern and manage
The analyst will walk you through scenario planning of the best and worst cases of your implementation. Scenario planning helps identify possible risks that can be addressed before they impact the implementation. |
3.2.2 |
![]() |
Transition
Knowing when to turn the system on can be a complex task. Our analyst will walk you through the process of selecting the right check list items for your implementation. |
Insight breakdown
Executive Brief Insights
- Agility is not absolute. Being Agile means using various techniques to get the right work done right. Sometimes that means traditional Waterfall techniques are the right answer.
- Iterations allow for course correction. Short planning and execution cycles allow for better course correction. It is far easier to recover from being fifty percent off on a week-long estimate than one that is four weeks.
- Aim for the highest level of integration with the business and the discipline to execute to increase your chance of success.
Phase 1 Insights
- Create your own glossary of terms that is accessible to the entire enterprise. This will ensure everyone has a common understanding of terms used.
- By including the goals and objectives in your governance template, the project team is reminded that the focus is the business value delivered not the technology.
- You won’t get engagement unless there is a sense of accountability. Do not leave this vague. Specific individuals in your organization need to be assigned accountability to ensure system development will achieve what was intended to by your organization and not what your SI intended.
- It is critical that all participants of decision-making authority and influence, including the SI, firmly agree to the goals and objectives and are committed to upholding them throughout the implementation.
- If you are new to Agile, we recommend engaging a coach to accelerate your progress and assist you in avoiding the common pitfalls.
- “Leading indicators make the news; lagging indicators report on the news” (Carlos Sanchez, Info-Tech Research Group).
Insight breakdown
Phase 2 Insights
- Select a partner with a culture compatible with yours.
- When selecting a team, include individuals with both high skill and high integrity. These leaders help keep the lines of communication open between team members and build trust.
- Think of the first iteration as a test run. After the first iteration, the team members should have a better idea of their capacity and what they can realistically achieve in one iteration.
Phase 3 Insights
- Build a dashboard that reflects the leading metrics you have identified. Remember to highlight requirements that represent key milestones in the implementation.
- Create a table of backlog responsibility covering activities, participants, and expected cadence.
- Use scenario planning to set your team and implementation up for success.
- Decide when to transition by considering all relevant factors, including testing, executive commitment, and business readiness.
Research contributors and experts
![]() |
Diana Larsen, Author, Speaker, Agile Coach AgileFluency.org A visionary pragmatist, Diana Larsen is Chief Connector at the Agile Fluency Project, where she holds a vision of an inspiring future: “Every Agile software team practices Agile software development at a level of fluent proficiency that specifically fits its businesses’ needs.” Devoted to the success of all Agile coaches and teams, Diana co-authored the books Agile Retrospectives: Making Good Teams Great, Liftoff: Start and Sustain Successful Agile Teams, and Five Rules for Accelerated Learning, as well as co-originated the Agile Fluency Model. |
![]() |
Carlos Sanchez, Practice Lead Info-Tech Research Group Carlos leads the enterprise application software team at Info-Tech Research Group. Carlos has worked in a variety of industries, including manufacturing, distribution, biotechnology, hi-tech, injection molding, steel, plastics, and non-for-profit. Prior to joining Info-Tech, Carlos ran his own consultancy helping medium and large organizations improve processes and execute enterprise applications initiatives. Carlos oversaw the selection, implementation, and recovery of a variety of applications including: ERP, manufacturing execution systems, payroll, human resources, accounting, warehouse management, and maintenance. |
Related Info-Tech research
Build a Better Backlog
The quality of your product backlog is key to realizing the benefits of Agile.
Implement Agile Practices That Work
Guide your organization through its Agile transformation journey.
Create a Plan for Establishing a Business-Aligned Data Management Practice
Guide your organization through its Agile transformation journey.
Enable Shared Insights With an Effective Data Governance Engine
Empower data-driven decisions for operational excellence.
Bibliography
“10 Powerful Agile Metrics – and 1 Missing Metric.” Sealights, n.d. Web.
“2018 IT Project Success Rates Survey Results.” Ambysoft, 2018. Web.
Alexander, M. “Agile Project Management: 12 Key Principles, 4 Big Hurdles.” CIO, 19 June 2018. Web.
Babcock, J. “Alistair Cockburn – Agile Is an Attitude.” PracticalAnalyst, 9 April 2015. Web.
Bloch, Michael, et al. “Delivering Large-Scale IT Projects on Time, on Budget, and on Value.” McKinsey & Company, 2012. Web.
“Construction SAP Services.” IBM, 4 June 2019. Web.
Esteves-Sousa, J., and J. Pastor-Collado. “Towards the Unification of Critical Success Factors for ERP Implementations.” 10th Annual Business Information Technology (BIT) 2000 Conference. Manchester. Web.
Goerzig, D., and T. Bauernhansl. “Enterprise Architectures for the Digital Transformation.” 11th CIRP Conference on Intelligent Computation in Manufacturing Engineering, 2017, pp. 540-545. Web.
Government of Canada. “Report 1 ‒ Building and Implementing the Phoenix Pay System.” 2018 Spring Reports of the Auditor General of Canada, 9 Mar. 2018. Web.
Grangel, R., and C. Campos. “Agile Model-Driven Methodology to Implement Corporate Social.” Computers & Industrial Engineering, vol. 127, 2019, pp. 116-128. Web.
Karlsson, Johan. “Backlog Management: 6 Tips to Make Your Backlog Lean.” Perforce, 7 Dec. 2017. Web.
Larsen, Diana, and James Shore. “The Agile Fluency Model.” ThoughtWorks, 2012. Web.
Bibliography
Laux, C., and G. S. Hundal. “Measuring and Analyzing Agility of an Enterprise Through DMAIC Six Sigma.” Seventh International Conference on Lean Six Sigma, 7-8 May 2018, pp. 128-136. Faculty Publications, Purdue e-Pubs. Web.
Rubin, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Pearson Education, 2012.
“The MoSCoW Method.” ProductPlan. n.d. Web.
Verwijs, Christiaan. “10 Powerful Strategies for Breaking Down Product Backlog Items in Scrum (With Cheatsheet).” Medium, 1 April 2017. Web.
“What Are Shell Scenarios?” Shell, 2019. Web.
Info-Tech IT Metrics Library
The following are examples of metrics that your organization can consider tracking.
Application Development Quality
- Percent of releases that cause downtime.
- Percent of releases that meet deadlines.
- Satisfaction that solutions are released successfully and are stable.
- Satisfaction with the acceptance testing performed on solutions.
Application Development Throughput
- Percent of application development projects that do not meet deadlines.
- Percent of projects that are over budget.
- Satisfaction that solutions delivered are cost-effective.
- Satisfaction that solutions delivered are timely.
Application Maintenance
- Percent of budget spent on maintenance.
- Percent of maintenance budget spent on day-to-day maintenance.
- Percent of maintenance budget spent on hotfixes.
- Percent of maintenance budget spent on patch releases.
Application Portfolio Management
- Number of supported applications.
- Overall application portfolio satisfaction.
Enterprise Application Selection and Implementation
- Percent of projects that are over budget.
- Percent of projects that do not meet deadlines.
- Satisfaction that solutions delivered are cost-effective.
- Satisfaction that solutions delivered are timely.
Info-Tech IT Metrics Library (continued)
Portfolio Management
- Percent of projects cancelled based on re-evaluated business value.
- Percent of projects exceeding planned budget.
- Percent of projects that realize planned benefits.
- Satisfaction that IT projects provide business value.
Project Management
- Number of projects started without an approved business case.
- Percent of projects that achieved expected benefits.
- Satisfaction that IT projects provide business value.
- Satisfaction with the quality of the project deliverables.
Requirements Gathering
- Percent of solutions not meeting business case objectives.
- Satisfaction that proposed solutions are feasible and optimal.
- Satisfaction that requirements accurately reflect business needs.
Organizational Change Management
- Satisfaction with the ability of IT to prepare stakeholders for changes.