How to Create a Realistic Digital Transformation and Software Implementation Project Plan

Implementation planning is one of the most important steps in any digital transformation, yet most organizations and even many consultants get it wrong. Plans take longer than expected, cost more than projected, and fail to deliver the business value that was promised. This is a major reason so many digital transformations fail. The good news is that creating a realistic project plan is not impossible. It requires the right benchmarks, the right structure, and a willingness to address the components that vendor proposals consistently leave out.

Why Most Implementation Plans Are Unrealistic

In our experience, most organizations gloss over the planning phase and jump straight into deployment. The result is a project plan built on assumptions provided by software vendors and system integrators, both of whom have an incentive to underestimate effort and cost. The proposal you receive at the start of a project rarely reflects the actual time and money required to deliver the value you are expecting.

The most successful organizations treat implementation planning as a discrete phase of work, not a checkbox before deployment begins. They use independent benchmarks, structured methodology, and rigorous scoping to build plans that hold up to reality.

Implementation Benchmarks to Use as a Starting Point

One of the most effective things you can do during planning is compare your assumptions against industry benchmarks. These are not best practices or best-case scenarios. They are averages drawn from cross-sections of organizations that have actually been through digital transformations. We have been collecting and studying this data for over a decade, and the patterns are remarkably consistent.

Average Implementation Timeline

The average implementation for an ERP project or digital transformation is 18 months. A large multinational organization typically takes 3 to 4 years or more, while a smaller mid-market organization may complete an implementation in 9 to 12 months. The 18-month average holds across industries, geographies, and organization sizes.

Average Implementation Cost

There are two useful ways to estimate cost.

The first is as a percentage of annual revenue. The average organization spends 2 to 3 percent of revenue on a digital transformation. For smaller organizations, this can rise to 3 to 4 percent because they have less scale and fewer economies. As a quick example, a $100 million company should expect to spend $2 to $3 million on total cost of ownership for the transformation.

The second is as a multiple of technology cost. Total cost of ownership typically runs 3 to 4 times the software license or subscription cost. With most vendors moving to subscription pricing, this metric requires translating the subscription cost into an equivalent on-premise multi-year cost before applying the multiplier.

Operational Disruption Rate

Between 50 and 52 percent of organizations experience some form of material operational disruption at go-live. The duration ranges from 2 to 4 weeks for smaller disruptions to several months for significant ones. This is not a planning input directly, but it is a strong reason to invest in ERP implementation quality assurance and rigorous testing as part of your plan.

The Standard Phases of Software Deployment

Software vendors typically structure implementations around five major phases:

1. Design and requirements: Defining what the system needs to do
2. Build and configure: Setting up the software based on the requirements
3. Testing: Validating that the system works correctly
4. Training: Preparing users for go-live
5. Go-live and stabilization: Cutover and the immediate post-launch period

The proposal you receive will outline these phases and assign durations to each. The problem is that this structure represents only one workstream within a much broader transformation program. Without accounting for the work that lives outside the vendor’s scope, the timeline and budget will fall short of what is actually required.

What Vendor Proposals Leave Out

Vendor proposals consistently underestimate effort because they focus narrowly on the technology workstream. The activities that drive the most time, cost, and risk in a transformation typically fall outside the vendor’s scope. When we advise clients on implementation planning, we always start by identifying these missing components.

Business Process Improvement

When the vendor and system integrator arrive to define requirements, they need answers immediately about how each process should work. If your organization has not already invested in business process optimization, one of two things will happen. Either the design phase will extend significantly while you figure out your future-state processes in real time, or the system will be built around assumptions that do not fit your business, which leads to even larger delays during testing and go-live. Both outcomes are expensive and avoidable.

Organizational Change Management

Change management is rarely included in vendor proposals because it is outside their delivery scope. But waiting until late in the project to address it almost guarantees a delayed go-live. Resistance builds throughout the project, and by the time training begins, the change management gap becomes obvious. Effective organizational change management needs to start during pre-implementation planning and run in parallel with every other workstream.

The Non-Software Technical Workstream

This includes data mapping and migration, system architecture, integration design, and the decommissioning plan for legacy systems. None of this is typically scoped by the primary software vendor, yet all of it must be planned, executed, and tested in parallel with the implementation. Organizations that overlook these activities consistently hit major problems during testing and cutover.

The Pre-Implementation Planning Phase

The most important phase of a transformation is the one most often skipped: pre-implementation planning. This is the work that happens after technology selection but before deployment begins.

For most mid-sized to large organizations, it takes 3 to 6 months and includes:

• Defining the future-state target operating model
• Designing the future-state organization
• Conducting initial change impact analysis
• Performing an organizational readiness assessment
• Building a technology roadmap, including integration and decommissioning sequencing
• Establishing governance, risk management, and program oversight

The time invested here is not lost time. It compounds throughout the project. In our experience, organizations that complete a thorough pre-implementation planning phase consistently finish their transformations closer to budget, closer to timeline, and significantly closer to the benefits they originally promised. Organizations that skip this phase pay for it many times over during deployment.

Getting this work right starts with a structured approach during Phase 0 planning.

Building a Realistic Project Plan

With benchmarks established and missing components identified, you can now build a project plan that reflects reality.

The process looks like this:

1. Compare the vendor proposal to industry benchmarks. If the proposed timeline and budget are significantly below the average, dig in to understand why. Ask what is included and, more importantly, what is not.
2. Add the missing workstreams. Build out parallel plans for business process improvement, change management, and the non-software technical workstream. Assign owners, durations, and budgets to each.
3. Adjust based on your specific variables. Use the benchmarks as a starting point, then flex up or down based on complexity, organizational size, the scope of process change, and the resources available internally.
4. Identify and price the risks. A realistic plan includes a risk register and contingency budget. The 50 to 52 percent disruption rate is a useful reminder that surprises are likely, even with good planning.
5. Stress test the plan with your steering committee. Get challenge from people who will not be afraid to push back on optimistic assumptions.

This is where pre-implementation planning becomes invaluable. The work you complete in that phase gives you the information you need to convert a generic vendor estimate into a credible, organization-specific plan that holds up over the life of the project.

What Makes a Good Digital Transformation Project Manager?

A realistic project plan is only as good as the person managing it. The role of project manager in a digital transformation is one of the most demanding in the organization because it requires a uniquely broad skill set. In our experience, the best project managers bring strength across three areas.

Technical Knowledge

A good project manager understands technology as an ecosystem, not just a single platform. It is rare for an organization to implement only one system. Most transformations involve multiple technologies that interact with one another. A project manager who can think in terms of solution architecture, understanding how different technologies integrate and function together, is far more valuable than one who only knows how to configure a single application.

Business Understanding

Many people would argue that business understanding is even more important than technical knowledge. A project manager who can dive into the business and understand how different functions operate, where process breakdowns occur, and how technology can improve those processes is going to make significantly better decisions than one who only sees the project through a technical lens. This operational and strategic understanding is often overlooked when organizations select a project manager, and it is one of the most common reasons transformations lose alignment with business goals.

Leadership and Communication

Of the three skill sets, leadership and communication are the most important and the hardest to develop. A strong project manager identifies stakeholder needs, discerns pain points, builds consensus, and takes ownership of outcomes without deferring to a boilerplate project plan. They work effectively with both the internal business team and the external implementation team to ensure all workstreams stay connected.

When we advise clients on selecting a project manager for their digital transformation, we prioritize leadership and communication skills over technical depth every time. Technical knowledge can be supplemented. Leadership and communication cannot.

A Note on Certifications

Certifications like PMP can be helpful, but they are not a substitute for the skills described above. All things being equal, a certification can differentiate two otherwise comparable candidates. But a certified project manager without business understanding and leadership skills will struggle in a transformation environment. The complexity and ambiguity of these programs demand more than methodology. They demand judgment, adaptability, and the ability to lead through uncertainty.

Questions We Hear Most

How Far Off Are Vendor Estimates Usually?

In our experience, vendor estimates underestimate timeline and budget by 30 to 50 percent on average, sometimes more. This is not because vendors are dishonest. It is because their proposals reflect only the technology workstream and assume the organization will handle the rest. Once you add change management, business process work, data migration, and stabilization, the actual program cost is significantly higher than the vendor’s quoted figure.

Should You Use Waterfall, Agile, or a Hybrid Approach?

Most successful enterprise transformations use a hybrid approach. Pure waterfall struggles with the iterative nature of process design, while pure agile struggles with the milestone-driven nature of large platform deployments.

A hybrid approach uses waterfall structure for major phases (design, build, test, train, go-live) while applying agile methods within each phase to handle the inevitable adjustments. The exact balance depends on your organization, but rigid adherence to one methodology over the other is rarely the right answer.

How Do You Handle Plan Changes Mid-Project?

Treat your project plan as a living document, not a fixed contract. Significant changes (scope, timeline, budget) should go through a formal change control process governed by your steering committee. Smaller adjustments can be handled by the program management office.

The key is to maintain visibility into how changes accumulate. Death by a thousand cuts is one of the most common reasons projects exceed budget. A strong governance framework, anchored to a clear business case and a realistic plan, is the best defense against scope creep.

If you are preparing for a transformation and want guidance on building a realistic implementation plan, contact us at eric.kimberling@thirdstage-consulting.com.