In previous Sikich blog posts, I have given my thoughts about how addressing some key readiness best practices at the beginning of an ERP project can improve the chances that the objectives of the project will be delivered successfully. As Mary Poppins said, “A job well begun is a job half done.” But what about the other half of the job, the other half being implementation when execution challenges take center stage? In this post, I’d like to highlight some of the execution challenges I’ve experienced in both sponsoring and leading large tech projects, both ERP and others. By being prepared for these challenges, you can greatly reduce the risk of tech implementation project failure.
Maintain Senior Business Leadership Focus
Regardless of how technology dependent a major project might be, it’s still a business project first and foremost. Senior business sponsors and stakeholders are likely to be heavily engaged in pre-project planning, particularly during the funding process. That engagement will become more important and will require a greater level of time, share of mind, and attention to detail on their part in the implementation phases of the project. Regular communication with and ongoing participation from senior leadership, particularly those in decision-making roles, must be maintained. Once configuration and implementation are in full force, senior leadership may take for granted that execution is on track and project teams may be reluctant to surface bad news or difficult business decisions. Business leadership must remain in the driver’s seat with eyes wide open throughout implementation.
Set Realistic Expectations
Projects begin as ideas. We may want to improve business processes, develop new products and services, and transform business operations. And ultimately every one of us is in Sales, promoting those ideas and the associated projects, competing for sponsorship and funding and the allocation of scarce resources. In our enthusiasm to “sell” our projects, we must be careful not to raise expectations beyond what can be delivered. There are many cautionary tales in which a project promised so much and became so big and complex that what was accomplished was overshadowed by what was promised and not delivered. And thus, the project was judged a failure. As Tom Peters advised almost 40 years ago, align expectations with what your project can capably deliver—under promise and overperform.
Enforce Disciplined Project Management
In the interest of not replicating the entire PMBOK Guide in this post, I’ll propose a summary definition of project management as using accepted knowledge, tools, skills and techniques to manage project resources and activities to deliver the objectives of the project. This definition manifests itself in the project plan. A quote attributed to Dwight Eisenhower is “Plans are worthless, but planning is everything.” His point was that the unexpected is bound to occur, and therefore everything will not happen the way it was planned.
Managing a large tech project is ongoing and iterative and requires continual balancing of competing and changing interests and constraints. These interests and constraints are always project scope, quality of deliverables, time to completion, and resources required. Changes to any of these factors (and be assured that they will occur throughout the duration of a large tech project) will entail trade-offs and risks. Project management teams must recognize that this will occur and acknowledge the functional relationship between these four factors. They must be flexible and adjust plans to account for these changes. And they must be transparent with stakeholders and senior leaders as to root causes of changes and how they are being addressed to manage expectations.
Control Change Orders
A consultant I met once long ago had a boat. The name of the boat was “Change Order.” Guess how he paid for that boat?
Regardless of how careful and diligent you are up front in developing requirements and use cases, changes are inevitable. And the cost to your project of changes increases the farther along you are in the project. See the visual below from the PMBOK Guide.
Some suggestions I’ve found useful in managing change requests to minimize project risk:
- View change as a process of constant communication and negotiation by planning for it and establishing a process around it.
- Manage expectations around change.
- Change is inevitable. Suffering is optional.
- Establish a formal change control system, including a Change Control Board (CCB).
- Define procedures for making timely decisions on smaller changes.
- Use written and oral performance reports to help in identifying and managing change.
- Use project management and other collaborative communication and version control tools to help manage and communicate changes.
The inability to manage change requests has the potential to lead your project into chaos. Know how to recognize change requests that are immaterial to greater project objectives and have the courage to say “No.”
Have the Right People
Having the right talent in key project and stakeholder roles may be the most difficult thing to achieve when staffing a large tech project. Transformative projects require people with a transformative mind set and a passion for achieving a project’s vision. And they need to understand and accept where they will fit and contribute within the enterprise in the post-implementation world. It’s the job of project and business leadership to communicate the organizational vision and to manage both the professional and human aspects of the transition. Large tech projects are about accepting change. As someone I know once said, “If you can’t change the people, then you need to change the people.” Human resource decisions are the most difficult decisions to make. Avoiding those decisions will carry a high cost for your project.
Keys to Minimize Risk for Tech Project Failure
In summary, committed leadership, realistic expectations, solid project management, disciplined change control, and the right people are the keys to minimizing risk of failure for complex tech projects.
This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.