Governance and Management of Enterprise Software Implementation

Being Agile will increase the likelihood of success.

Table of contents

Executive Brief

Execute the Project/DIY Guide

1. Assess
   • 1.1. Establish Your Starting Point
   • 1.2. Governance Structure
   • 1.3. Define Your Metrics
2. Prepare
   • 2.1. Establish Your backlog
   • 2.2. Build Your Teams
   • 2.3. Assess Readiness
3. Govern and Course Correct
   • 3.1. Govern and Manage
   • 3.2. Transition

Insight Summary

Appendices

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

1. 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.
2. 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

1. Use Agile techniques such as a backlog for the work items, focusing on the must-have items (i.e. 40% of the backlog).
2. Use iterations to accomplish work, which sets the implementation up for success.
3. Once all the must-have requirements have been implemented, the business has the choice of launching the enterprise software.
4. 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

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 Point 1.2 Governance Structure 1.3 Define Your Metrics	2.1 Establish Your Backlog 2.2 Build Your Teams 2.3 Assess Readiness	3.1 Govern and Manage 3.2 Transition
Guided Implementations	Scoping call: discuss preparations that led to implementation. Discuss governance and the importance of stakeholder engagement. Discuss organizational goals, success metrics, and project metrics.	Discuss how to take your requirements and build a prioritized list of tasks. Talk about the teams needed to accomplish the project and the impact of changing members. Discuss the implementation plan and the readiness of the teams to execute.	Discussion of dashboards and backlog review criteria. Disaster preparation through the use of scenario planning and the creation of a checklist of transition to operation criteria.
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: Established goals, objectives, metrics, and structure for governing the project.	Phase 2 Outcome: Teams and prioritized task list ready for implementation.	Phase 3 Outcome: Successful implementation and transition to operation.

Workshop Overview

Contact your account representative or email Workshops@InfoTech.com for more information.

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

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

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.

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.

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.

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

1. Review the goals and objectives for the implementation.
2. Brainstorm metrics or KPIs that align with the identified organizational goals. Define each.
3. Record results in section 14 of the Governance Model Charter Template.

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

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

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

1. 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.
2. 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.
3. 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.
4. Document the roles and responsibilities, accountabilities, and other expectations as they relate to each step of the implementation.
5. 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)

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.

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

1. Identify your current project practices and map them using the table below.
2. Determine the number of unknowns in your implementation. Use Agile if your number of unknowns is high.

Sample

Step 1.3: Define Your Metrics

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.

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

1. Gather any metrics related documentation that you collected during your requirements gathering.
2. 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

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:

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team. Info-Tech analyst will join you and your team onsite at your location or welcome you to Info-Tech's historic Toronto office to participate in an innovative onsite workshop. Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

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 Starting Point

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.

1. Select an initial list of requirements as PBIs and provide a brief description of each.
2. Identify on which tier or where within the backlog each PBI is intended to live.
3. 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

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

1. 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.
2. 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.
3. 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

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 +
1. Management Consultant
2. Vendor Consultant
3. 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.

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

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

1. 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.
2. 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.
3. 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.
4. 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

1. Determine the roles that may require data changes.
2. Record who has the authority to approve the change.
3. Define a RACI for your data activities.

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.

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

Step 2.3: Assess Readiness

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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

1. Refer back to the PBIs added in Activity 2.1.2.
2. Choose a vertical break-down strategy that the team is comfortable with.
3. 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:

1. Capture the data.
2. Store the data in a database (could be a separate story, could be broken down).
3. Create a means to access the information online.
4. Provide means to print the information.
5. 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:

1. Create a means to enter the request.
2. Create a means to modify the request.
3. 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:

1. Provide a means to access employee absence data for a specific project.
2. Provide a means to retrieve employee absence data for a specific project.
3. 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.

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

1. Identify and select a location for the team’s task board.
2. Set up the team task board by vertical columns for to do, in progress, tested, and done.
3. Add your committed user stories to the task board along with their relevant tasks.
4. 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

1. 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.
2. 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.
3. 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

1. Identify a retrospective approach that the team agrees upon and wants to use as part of their Agile practices.
2. Set up any materials (e.g. sticky notes, pens) that the team will require to simulate a retrospective.
3. With the scrum master facilitating, conduct a retrospective on the day’s activities you participated in to understand Agile practices.
4. 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:

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team. Info-Tech analyst will join you and your team onsite at your location or welcome you to Info-Tech's historic Toronto office to participate in an innovative onsite workshop. Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

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

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

1. 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

1. Review the activities of your idea or work request intake process.
   Examples: split epics, write user stories, estimate, valuate, add to backlog.
2. 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.
3. 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.

Step 3.2: 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

1. 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.
2. 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.).
3. 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

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

1. Create your transition checklist.
2. Record your checklist in the Enterprise Software Implementation Checklist Tool.

Sample

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:

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team. Info-Tech analyst will join you and your team onsite at your location or welcome you to Info-Tech's historic Toronto office to participate in an innovative onsite workshop. Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

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.