How are ERP acquisition and implementation projects fundamentally different in large and small companies? Why does it matter so much?

There are many ways to structure software acquisition and implementation projects and both large and smaller companies have many of the same choices; but there is one defining difference that is based on size alone.

The core project teams of large corporations are fulltime functional entities in their own right. Team members work for the team and only for the team during the duration of the project, no matter where they came from and where they’ll be going when the project ends. They may be assigned to the team to represent their home organizations but, while the project lasts, they are no longer reporting to that organization in any but an advisory sense and, most importantly, they are no longer doing their usual work.

In smaller companies, membership on a project team is one more duty added to those an employee already has. Depending on the magnitude of the project, there may be one or two fulltime team members (usually from IT) but the team members representing the various business functions continue to work in those functions as their primary responsibility.
There are many consequences of this fundamental difference between larger and smaller companies. Some of these are crucial to our point and are discussed here; for some others,

The essential points here are

  • That large and small company project models are different, not that, in and of themselves, one is right and the other wrong.
  • That an acquisition and implementation strategy is designed for either a large or a small company environment; that parts of it may be transposed from one to the other but, on the whole, it is intended for only one of two very different workaday worlds.
  • That it is therefore unreasonable and unjust to expect a large company approach to work in a small company (and vice versa), no matter how successfully it has been shown to work in the world it was designed for.
  • That many methodologies have been published, and many more are being sold as adjuncts to software itself and to consulting services for implementing it; and some of these have impressive track records of success; but they all are implicitly designed for either small or large companies, whether or not they are sold that way and even whether or not their authors are aware that their best use is confined to one general size of client. After all, why would professional project managers, accustomed as they naturally are to working in a particular style of project, consider how different things might be in kinds of companies they’ve never worked in?

Every project budget is to some extent a mixture of hard and soft costs, but it is surprising how hard the soft costs become in the dedicated fulltime teams typical of large company projects. In projects of any significant scope, large companies usually find themselves forced (for a variety of reasons) to charge all the costs associated with the team to the project itself; this includes not just salaries and fringes but also the facilities the team members occupy and, especially, the time everybody spends not doing anything particular at all.

One consequence of this is that the cost of large company projects is immediately inflated by the resources the company commits. If both a large and a small company plan to commit 10,000 employee hours (at, say, a fully burdened $50 per hour) to similar projects, the large company expects to spend $500,000, while the small company – reasoning that it’s going to pay those people no matter what they work on – may not consider that $500,000 to be a project cost at all. This makes it impractical to make apples-to-apples comparisons between large and small company projects. A successful project to implement System S at the very large ABC Corporation will appear to cost much more than an equally efficient project at the much smaller XYZ Company. Strangely, we don’t hear this discussed much. We hear that Consultancy C claims to do “1X” implementations, but we rarely hear how much of “1X” is comprised of their clients’ own payroll and overhead, something that can vary wildly according to differing budgeting and accounting practices dictated mainly by the relative size of any given client.

Another consequence of dedicated vs. part-time team membership is that the cost of large company projects is further inflated by normal activity (and inactivity!) not directly related to the project at all. In a very efficient organization, perhaps 85% of people’s time is spent directly doing the jobs the organization chart says they do. The remaining 15% is not very much for taking messages, cleaning up their desks, attending mandatory meetings (never mind the occasional cup of coffee). Even in such exemplary companies (really, 85% is way too high), the cost of the project increases by a further 17.6% as soon as it is established. In practice, this surcharge is usually invisible because everyone realizes that fulltime means fulltime and people are budgeted and charged by the day instead of the by the hour. But this has a further inflationary effect on budget and cost, as two-hour tasks inevitable become one-day tasks, and so on.

Yet another consequence is that in a large company, there is no apparent cost benefit to having the company’s own people perform a project-related task if an outside entity appears able to do it for the same cost. And this will often appear to be the case once Management reflects on learning curves and the apparent need to have outside consultants overseeing even the work the company does for itself. Indeed, for reasons described below, it will often seem that the outside resource is cheaper, no matter what they charge, if they can deliver the work more quickly than the company can do it itself.

This brings us to the greatest difference between large and small company project costing: in large company projects, the single largest cost driver is the calendar itself. Consider the following two examples, which admittedly are much oversimplified in detail, but which are anything but uncommon in practice.

Large company example:

Fully burdened weekly rate = ($50/hr x 8 hours/day x 5 days/week) = $2000.
Team size = 12 people.
Burn rate = (12 x $2000) = $24,000 week.
Expected duration = 40 weeks.
Budgeted internal labor cost = (40 x $24,000) = $960,000.
Actual duration = 60 weeks.
Total internal labor cost charged to project = (60 x $24,000) = $1,440,000.
Cost overrun due to schedule slip = $500,000 or 52 percent.
(Jobs lost / careers damaged = ?)

Small company example:

Team size = 6 people.
Team members charging their time to the project = zero.
Burn rate = (6 x zero) = zero.
Expected duration = 40 weeks.
Budgeted internal labor cost = (40 x zero) = zero.
Actual duration 80 weeks.
Total internal labor cost charged to project = (80 x zero) = zero.
Cost overrun due to schedule slip = zero.

Now, we have to suspect that the small company’s 100% schedule slip probably cost it something, but we can’t see from the numbers shown what that cost is or what would have driven it. The point is that it is possible, though unlikely, that the small company experienced no schedule-driven costs at all; while, on the other hand, the large company’s project structure caused almost all its costs to be defined as schedule-driven, making schedule overruns synonymous with cost overruns.

It may also be objected that the 50% and 100% schedule slips shown must be unusual enough that they distort these examples in misleading ways. We would dispute that. Many things affect project schedule performance, and not every schedule is missed – but one kind of schedule is almost always missed: this is the schedule whose finish date is dictated by Management, sometimes in the earliest planning stages and sometimes even before that. We can all deplore this practice but we can’t deny that it happens every day, and we should point out that it happens more often in large companies than in small ones. The nature of large company project budgeting almost requires it: top Management must be given a cost estimate as a precondition of their approval and, since costs are inextricably linked to schedules, how can this be done without imposing a finish date before the project is even designed?

How do large companies try to mitigate this effect? They can see as well as anyone how their project cost structures penalize internal resources. They cannot budget internal costs independently of the project schedule but they can sometimes contract some of the same efforts externally on at least a partially fixed price basis. External consulting support cannot be completely turned off to adjust to internal schedule slips, but sometimes parts of the external effort can be negotiated on a “when-needed” basis. More often, large companies are led to rely on external resources even when they are sold on a burn-rate basis and even when the external rate is significantly higher than the company’s internal rate. This happens mostly for two reasons. The first is the (often true) perception that their consultants have already paid for their own learning curve, which should not only limit the number of hours they have to purchase but also shorten the actual project duration (thereby also limiting internal costs). The second reason is that it is sometimes possible to negotiate non-to-exceed caps on parts of the external effort.

Large company projects are not really our topic here. We discuss these things to show how the smaller company projects we are often involved in should not depend on large company models, because large company project management practices are based on utterly different assumptions about cost and schedule. But the discussion above should at least suggest that large companies have more valid reasons than do smaller companies to hire external project resources.

What of the 100% slip we showed for the small company in our example above? How realistic was it, and what does it mean? In a well run project, it may be quite common and it may not mean much at all. This is because a significant part of the project may be defined as “do the research needed to find out how to get everything else done, in the least expensive and most timely way.” This effort may contain a large number of unknowns (and hence a great deal of uncertainty concerning its own duration) but if it is well planned, it can extend to almost any span without very much affecting the total cost of acquisition and implementation. But that is beyond the scope of this comparison of project cost structures in large and small companies.

Back to Table of Contents

Copyright © 2011, 2012 by Adaptive Growth, Inc. All rights reserved.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS
This entry was posted in ERP Implementation. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>