The ERP “X” Factor

It’s no secret that business transformation initiatives are highly complex undertakings, whether you’re talking about CRM, Supply Chain Optimization, or a full-blown ERP system.  It’s also no secret that due to the inherent complexities of these transformations, studies indicate that they routinely go over budget and can even fail to deliver the expected benefits that justified them in the first place.

While there are many strategies and tactics that your company can and should adopt in order to avoid becoming another statistic, I want to focus on one in particular: the “X” factor.  Simply put, does your combined team have the ability to e”X”ecute over the entire course of the project?


Most companies understand the importance of vetting the resumes of the team that their System Integrator (SI) is bringing to the table; however, ensuring the continuity of that expertise over the life of your project is just as important.  Key resources should be identified in the statement of work (SOW), and explicit rules governing your SI’s ability to remove them from your project should be baked into the commercial terms.

Furthermore, don’t forget about training and empowering your internal team up-front.  Because even if your core team is comprised of the most talented, driven individuals in your organization, relying solely on your SI to bring them up to speed on platform functionality and technology options is probably a mistake.  If you don’t invest in training for your internal team beyond the knowledge transfer you receive from your SI, you automatically limit your solution to your SI’s perspective and inhibit potential “out of the box” thinking during design and exploration phases of the project.


While closely related to expertise, this is more about depth than breadth…especially when it comes to program management and change management competencies.  In other words, it’s not enough to have people with project management expertise on your team, you want people on your team who have managed similar size programs before.  When it comes to enterprisewide, transformational initiatives, they entail a veritable minefield of potential risks that even your most skilled people will not be able to fully anticipate if they haven’t managed similar programs.

Again, the problem stems from the sheer complexity of these kinds of projects.  There are simply more moving parts, more people, and more cross-functional dependencies to coordinate than on smaller, departmental projects.  In practical terms, this means that management responsibility has to be distributed across multiple managers, geographies, and workstreams in order to get everything done.  As such, previous experience in managing large programs is your most valuable asset when it comes to avoiding the kinds of mistakes that will derail even the best of project plans. Whether it’s coming from your SI or your internal PMO, make sure you have an experienced team at the helm.


Even if you manage to assemble the right mix of skills and experience within your team, the Achille’s heel of projects often comes down to capacity.  For your SI, a capacity crunch can manifest itself in a number of ways that may be detrimental to your project — scope might get reduced, testing cycles might be scaled back, mock conversions might be reduced — but in the final analysis, your SI has the ability to draw on a large talent pool and address resource constraints with relative ease.  The hard part is getting them to scale up and meet their commitments without signing a change order.

When it comes to your internal team, though, any inability to accommodate project demands can quickly become a crippling constraint.  This is true during any phase of the project, but the stakes get higher the closer you get to go-live.  Once the project is operating in high gear, it can be difficult if not impossible for your organization to find an additional 10 developers, testers, or subject matter experts on short notice.  Companies are then presented with a dilemma: either incur the cost of extending the project or approve a change order that authorizes your SI to ramp up and fill the gap.  Neither option is particularly palatable, and it’s easy to see how so many projects go over budget.

Your best defense against this scenario is rigorous and realistic project management that includes a transparent, active process for managing the staffing plan.  The PMO should routinely reforecast all resources on the project — including your internal resources and stakeholders — so that you are better able to anticipate and plan for potential spikes or shortfalls.  Furthermore, during phases of the project when even the slightest hiccups can quickly cascade throughout the project team and wreak havoc on your timeline, assume the need for “surge capacity” and take steps early on to build it into your plan.  This could include planning for additional resources during system testing or data validation, telling your team to plan on some weekend work during peak times, or even deferring vacation during critical periods of the project.  Your team may not be thrilled at the prospect of giving up some weekends, but it’s better to prepare for the additional horsepower and not need it than wait until you’ve got a crisis on your hands and try to tap productivity that simply doesn’t exist.


In summary, software platforms and methodologies don’t transform companies, people do.  And while it’s vital to assemble a team with the right skills and level of experience, it’s just as important to ensure that your team has the ability to make it to the finish line.  Realistic and actionable contingency plans are essential to sustaining the energy and morale of your team over the course of the project, and companies that get it right are much more likely to e”X”empt themselves from becoming another statistic.

Follow me on Twitter @sstamp_ue.  Find my other UpperEdge blogs and follow UpperEdge on Twitter and LinkedIn.

Related Posts

Leave a Comment

Your email address will not be published.