 |
|||
 |
 |
 |
 |
Adaptive Growth: What We DoWhat We Do. We define ourselves as business advisors for project management, and what that means to us is this: we deliver dense packages of highly specific knowledge about mapping strategic business objectives to business technology. Our approach is designed for the purpose of aiding our clients in their own management of three narrowly defined kinds of projects:
We call ourselves business advisors rather than consultants because we are not in business to rent our skills. The time we spend with our clients is only a vehicle for delivering information; when it’s delivered, we leave. People who call themselves project management consultants usually manage projects on a contractual basis; we don’t – we expect our clients to manage their own projects. If anyone who appreciates this distinction wants to call us consultants anyway, we won’t argue.
We concentrate on abetting(as opposed to managing) the kinds of project that we’ve come to understand through experience, and what we offer is not management itself but rather deep, detailed blueprints that successful projects of these kinds conform to, blueprints that your own project managers can use according to their own styles and inclinations.
What we’ve learned, and what we offer, are not original or proprietary ideas of our own. On the contrary, they are the collected, distilled experience of a great many people, learned over a great many years. What we hope distinguishes us from any number of industry experts who know these things just as well as we do is our focus on delivering this specific expertise, and only this specific expertise, in the smallest possible packages.
When a company contemplates a project that lies outside its own experience, a false dilemma sometimes seems to present itself: we can manage this project ourselves and do without the critical expertise we lack, or we can surrender control to outside experts. Sometimes there is a third way, which is to acquire the missing expertise while still retaining control. We pursue this third way. Acquiring the expertise you lack may involve one step or two: you may just be able to learn it yourselves, or you may have to learn how to rent it while still remaining in control. In either case, the goal is to keep control of the results – as opposed to surrendering control to the outside experts that you will, unquestionably, sometimes need.
ERP System Acquisition & Implementation Viewed as a Single ProjectIt is a truism that in any complex activity, the critical, defining decisions should be made as early in the process as possible. In ERP implementation projects this principle is routinely undermined by the nearly universal practice of separating acquisition and implementation activities into separate projects, performed by separate teams operating under separate control. This causes any number of critical decisions that ought to occur in the earliest phases of acquisition planning to be deferred to the implementation phase, where they are then made by the wrong people for the wrong reasons, well out of the sight of those who have the most at stake in them. These stakeholders have, in fact, needlessly surrendered control of the project to outsiders in the usually unquestioned but always mistaken belief that technical proficiency and product knowledge trump their own needs and abilities in all matters relating to system implementation.What must be turned over to outsiders is the technical process of system configuration – the actual work of making the product do what the user company needs from it. This is a lot, but it doesn’t include three things that should never be turned over to outsiders, but often are:
These three things can’t be separated. Day to day control of the implementation is ceded to implementation vendors when they are given the task of deciding what the system will do (as opposed to how it will do it). When that happens, the implementation team has no choice but to take control: they’ve been given the task of defining the project, so define it they must. And day to day control slips away unnoticed when the implementation team is held to some standard of performance other than the configuration of the system according to the user company’s precise instructions. This being the case, why is the job of defining what the system is to do ever passed to the implementers? Because of some common, overlapping misunderstandings.
Back to top of question All three of these notions are misconceptions. We’ll take them in order. First, the description of what the user company needs the system to do is not a technical, software-dominated task: the task is rather one of describing the complex internals of one particular company’s business, in common business-oriented terms. In many ways, a well implemented ERP system is a mirror of a company’s operations. In this mirror, a single business event – say, a shipment to a customer – is reflected back to different people in different ways. To an accountant looking at one aspect of the transaction, it becomes a $135.53 debit to the cost of sales; to accounts receivable, it becomes an open invoice to be tracked; to someone else it represents a sales commission earned; it is a warranty responsibility for a business unit fifty miles away; it is a line item on a dozen sales reports, and part of a summarized total on a dozen more; it is a fragment of consumed sales forecast, that later became a fragment of a master schedule, that still later became a demand against manufacturing that was fulfilled by a now-closed shop order. That shop order incurred fourteen different labor charges and required as many component issues, each of which was built or bought according to an ever-widening chain of events that can be traced for years to come. This is only the beginning – it is drawings drawn and checks written and requisitions approved and tools sharpened, but if you’re reading this, you get the idea. The point is not that it’s all so marvelously complicated but that every true picture of such things, every true reflection of this kind is so marvelously unique. All of these individual details, those we’ve mentioned and those we haven’t, happen in countless ways in countless companies, but here they happen as this company does them. Likewise, this particular mirror, as it is configured and used, is right for only this company. Change it just a little and it reflects some other company, or no company at all. To get it right takes almost as much knowledge of what this one company does as it took to perform that transaction in the first place. More to the point, to describe everything that goes into that transaction in just the right detail takes about the same knowledge as it takes to perform and manage it in the course of this company’s daily life. What outsider can do that? None of this is a description of software; the closest it gets to that is as a description of business life that must somehow be reconciled to software. This is not to say that everyone knows how to create such a description, but we are sure that everyone can be shown how. We do that part. Back to top of question Second, the business analysis that implementation service companies provide does not create a comprehensive mirror of their client’s operations in terms that the client itself can recognize. No matter how well they do their jobs – and most of them do it very well indeed – their audience is their own company. They talk to their clients diligently and diligently feed back to them what they’ve absorbed, they make many lists and check them all twice but, in the end, the pictures they draw are drawn in the terms of their trade and their product. If those pictures are the only operative blueprint of their client’s business, the implementation team that follows after the business analysts will be speaking a different language than the people they’re working for. Third, companies often rely far too much on the very real understandings they’ve come to with their chosen ERP vendors in the presale phase. These understandings can simply dissipate in the implementation phase to follow. The basic reason is twofold: first, as discussed above, the implementation team is not working to a precise definition of the detailed meaning of success. Second – and this is even more insidious – the implementation team can also fail to learn much of what the presale team discovered. Of course, a handoff of some kind takes place between the presale and implementation teams, but it tends to be a handoff of summarized conclusions, biased toward system-oriented concepts and terms. The nuanced feel for the client’s company that the presale team had to acquire and demonstrate in order to earn the business – the detail behind these summarized conclusions – is lost in this transition. This is discussed somewhat more in the following topic, “ERP System Acquisition Project Planning”; if that still doesn’t go into enough detail, contact us and we’ll explain. These three misunderstandings, when they’re allowed to determine events, have the effect of deferring the implementation team’s full understanding of what they’re supposed to be accomplishing; they defer it at least until the implementation phase is well underway, and sometimes until the team believes it’s almost done. When that happens, it’s not the implementation team’s fault; it’s the natural consequence of having them work to inadequate blueprints. But when it does happen, the cost of correcting the resulting disconnects – when they finally come to light – is far greater than would have been the cost of preventing them in the first place. Back to top of question
ERP System Acquisition Project PlanningERP system acquisition projects are rarely deemed to fail: usually buyers end up buying, and then it's up to the implementers to make it work (or not). All too often ERP acquisition means little more than system selection and contract negotiation, perhaps going so far as to include the contract for implementation. In fact the acquisition phase is the only real opportunity to put in place the mechanisms that - if they are implemented - can later ensure implementation success. This is the opportunity for the buyer to control the meaning of implementation success in concrete terms that buyer, system provider and implementation partner can accept as being in their own best interests. This is, in short, the only time when overall project success can be conclusively defined in enforceable, concrete terms that all parties can willing agree to be held to. That this rarely happens should not obscure the fact that the techniques for achieving it are well understood and have been used successfully by some companies for many years.The amount of time and effort that go into system selection varies radically from company to company. Some companies spend years at it; others (usually subsidiaries) are told which system they will buy before they begin their acquisition efforts. Companies in the first group aren’t necessarily more successful than those in the second. As important as system selection can be, a well done system selection in and of itself is never enough to guarantee implementation success. Let’s take a look behind the statistics about ERP implementation failures and overruns. Almost every ERP vendor has a list of multiple successes – their systems have been proven to work many times over. Unfortunately, they also have many troubled implementations. The fact is that, in and of itself, the choice of an ERP product guarantees nothing. Success happens to them all, but so does failure. Likewise, most ERP implementation companies also have long lists of happy clients; they also have other clients they’d rather not talk about. That is, their methods have been proven to work, but only some of the time. Why do the same products sometimes work and sometimes fail? Why are the same people sometimes able to implement them and sometimes not? The short, unpleasant answer is that ERP implementation success requires that the company acquiring the system do its homework, because failure follows from not doing it. But why wouldn’t anyone do their homework in matters as critical as this? Usually because they try to start some of it long after it should have been completed, and often because they try to outsource work that only they can do for themselves. Back to top of question What critical work ought to be done prior to ERP system acquisition that is often deferred to the implementation phase, or simply never done at all? Why should it be done prior to acquisition? Why can’t it be outsourced to the implementation provider? Consider an obviously false choice: two hypothetical attitudes toward buying an ERP system, phrased in excessively simpleminded terms.
Who would not agree that only the second approach makes sense? Nobody. Who would ever choose the first way? Nobody. So everybody thinks that they acquire ERP software and implementation services based on a shared understanding between all parties, a clear business understanding that covers all significant requirements and can serve as a roadmap for implementation. That this doesn’t happen much of the time is manifestly obvious – otherwise, why does any project ever fail, to any extent? – but how can so many people be so deluded about a process that seems so clear, so fundamental? The short answer is that ERP buyers and sellers do come to agreement, but the agreements they come to are way too general and abstract. They don’t describe expected use and behavior of the new system in nearly enough detail (or in the right kind of detail), and for this reason they can’t (and don’t) govern the day to day tasks of the implementation. When a project is not being governed by an explicit, shared understanding of what is to be done (and why it is to be done), it is being governed by something else – and no matter what that something else may be, whatever shared understanding the parties thought they had achieved is not driving the effort. Back to top of question Pre-sale agreements are usually reached through a combination of a proof of concept demonstration and gap analysis, which identifies required changes to both software and procedures. Implementation tends to be viewed as simply an elaboration of this pre-sale process, but in fact implementers work in far different terms – wherein lies the problem. ERP packages are monstrously complex. Even the simplest are complex enough that no one person – no one, anywhere, including their (multiple) architects and authors – can even begin to fully understand all the ways they might behave. Their behavior is controlled by switches set by the implementation team, more than 10,000 at the most complex end of the scale but never less than a few hundred. Even 100 two-position (either/or) switches can be set in a huge number of combinations (roughly, 1 followed by thirty zeros). Of this immense set of possible ways to configure any modern ERP system, only a tiny fraction has ever been implemented. Even if a product has been configured in thousands of ways for thousands of companies, this still represents only a tiny fraction of the possible configurations. No implementer is equally expert in all parts of the same system (which is why they come in teams). The system itself, however, is not so compartmentalized. Any one system function has potential implications for every other system function. Of course, for any one configuration of any one function, not every potential system-wide effect is realized, but some are. Ideally, the implementation team would somehow notice, evaluate and manage all of these actual effects. In practice, this is horrifically difficult; still, it can be done, and sometimes it is. But only until the target moves. And the target usually does move. The “target” in this sense means the implementation team’s working understanding of their task, and nothing else. It is not necessarily the same as any written spec or contractual obligation, but it is the only thing that counts. Before the fact, the consequences of any change to the implementation team’s working understanding of their task are utterly unforeseeable, ranging from inconsequential to catastrophic; but even inconsequential changes have an impact on the project schedule because they must be evaluated and proven to be inconsequential. All too often changes are somewhat more than inconsequential. Impacts throughout the system have to be discovered, assessed and dealt with. Often changes come in waves, one change requiring many more. Work previously thought complete has to be redone and retested, and more work added to the schedule as the full impact of each change sinks in. Back to top of question Why and how does the target move? Implementers tend to view any change to their understanding of their job as scope creep. Scope creep – a change to the user’s requirements while the project is underway – does happen. It can be controlled but only if the user’s requirements have been rigorously analyzed prior to acquisition; even then, controlling it requires deep project management discipline coupled with strong, informed executive support. But most instances of what implementers call scope creep – most of the changes to their working understanding of their task – do not represent changes in requirements from the users’ perspective. Rather, they are just unpleasant flashes of enlightenment occurring as implementers suddenly come face to face with some unperceived aspect of the users’ expectations. They are surprises, nothing more, and they invariably represent hidden disconnects between user and implementer. They happen because the implementers, with the best will in the world, miss important aspects and implications of the user requirements; and that happens because these requirements are not fully presented in concrete terms that the implementation team can work to (and can be required to work to, and can be measured by) on a day to day basis. It is possible to state the user requirements in ways that vendors and implementers can understand and conform to. It isn’t always done but it is possible, and it has been done many times by many companies. It certainly isn’t something we claim to have invented. Not only did we not invent it, we can’t even begin to do it for anybody. We don’t think anyone can. It is something that only the company purchasing the system can do. No one else can come in and explain the details and nuances of the company’s business to itself, let alone to anyone else. The most that outsiders can do is show a company how it can explain itself to the world (and to itself!) in ways that translate into ERP implementation success. This is what we do. Back to top of question Even a perfect description of requirements and expectations is not enough by itself. It needs to be stated in terms that the implementation team can work to, that their own management can hold them to and that the implementation vendor as a whole is contractually bound to respect. In other words, all real requirements and the methods employed to fulfill them must be gathered into a full and complete Statement of Work (SOW) around which the implementation contract is written and the implementation project is managed. Requirements cannot be imposed after the contract is let. Implementers must work to something, and they will set their own targets if none are set for them, targets that will not be based on their client’s understanding of its own business. After the contract is signed, implementers will rightly view attempts to hold them to unstated specifications as scope creep at best, interference at worst. And implementers will not usually agree to be bound by a sufficiently detailed SOW that they had no part in negotiating. They have every right to insist that their own implementation methods and management practices be written into it. Once the acquisition is over, the opportunity to control the implementation has passed. Back to top of question
ERP System Implementation Project PlanningSuccessful ERP implementations are, by seemingly trite definition, simply those that don't fail; but this isn't trite, because failure is so very common. Failure follows directly from allowing a few well-known risks to go unmanaged. They go unmanaged because control of results slips from buyer to seller. The buyers (the user company) are the only people in the world capable of seeing the new system as a tool for running their particular business. The sellers can’t and don’t think in terms of their client’s business; they are hired because they think in the technical terms of their product. Control usually passes from buyer to seller at the very outset, without anyone even noticing, simply because no one sees a practical alternative. Buyers don't see how they can get and keep control of results while still getting what they need from providers, and sellers don't see how they can give up this control while protecting their contractual interests. The loss of control can be avoided if some basic principles of project management are rigorously applied from the inception of the acquisition and implementation process, and well before what the seller calls the implementation project begins.In the preceding topics we discussed two important themes:
The payoff for pre-implementation planning (or the payback for its absence!) comes in the implementation phase itself. Even if the implementation team sets out from the very start to configure their product by working to a comprehensive blueprint of the desired system, some time will pass before results can actually be seen. During this period the team’s progress can (and should) be monitored in various ways (using established project management techniques), but the actual results of their work – which is to say, of the project as a whole to date – cannot be seen yet. It is only when the first fruits of their efforts can be viewed by the user community that anyone can really begin to evaluate the success of their work. How does this matter? How, especially, does it matter in terms of risk management? Let’s oversimplify and assume that the results of the implementation team’s work appear continuously throughout the project. (This isn’t really true. Results usually become visible in bunches, and some results – those that depend on the integration of many individual modules – only appear toward the end. But let’s simplify for the sake of example.) The schedule calls for an implementation phase of W weeks. As the implementation emerges, an unknown number of problems will be revealed; call this number P. In our overly simple model, the appearance of problems will be dispersed evenly throughout the continuous emergence of the configured product. This means that after ½ W weeks have past, ½ P problems will have emerged – and fully ½ won’t have shown themselves yet (we remind you again: this model errs widely on the side of optimism). Back to top of question Problems have to be dealt with as they emerge. In some cases the project team can correct them in stride. In other cases, the team will have to backtrack and redo work previously thought complete. In particular, the more tests that have occurred (and been deemed complete) when any problem is discovered and addressed, the more tests that will likely have to be repeated; and testing comprises (or should comprise) a large portion of the implementation effort. Minimizing P will obviously have a positive impact on the project’s success, and every effort should be made to do that. But P can never be reduced to zero, and the full magnitude of P cannot be known until the final run of acceptance testing has been passed with every known problem resolved (and shown to be resolved). Thus two goals emerge that are both at least as important as the admittedly important goal of minimizing P:
These things don’t happen without a very explicit kind of planning that should be complete before what is often called “implementation” is even begun. This kind of planning covers four general areas:
This is a high level description of what we deliver. Back to top of question
The Relationship between Market Focused Strategies and Business Software Acquisition and ImplementationPreface: Many strategic plans are plans in the making, not plans in fact. A plan in the making can be many things, some of them very useful, but it is not a plan that is guiding everyday decision making. A plan-in-fact does that. It states the company's strategic goals in appropriate business terms and extends them throughout the company's daily life. It is self-auditing and self-correcting. It informs decision making throughout the organization.It can do these things for two fundamental reasons. First, its high level goals are stated in terms of the company's market, not its operations. Second, the maintenance, monitoring and execution of the plan occur in a self-sustaining, rhythmic process that is perpetually measured against the company's evolving strategic objectives. Such a plan is a living thing, directing every activity that has even medium term implications for the future. Once adapted, such a plan quickly eliminates the usual phenomenon of apparently sound operational decisions that turn out to conflict with long term goals. Market Focused Strategies and Business Technology Much of what people do all day is accomplished through the medium of business technology, most notably in the form of business applications. Some of this technology is strategically neutral – that is, it neither enforces nor impedes the company's strategic direction. There is a tendency to think of most business technology as strategically neutral (our strategy is about selling widgets, not paying the phone bill). But when companies attempt to change their behavior in accordance with their strategic direction, they often find that their technological infrastructures are far less strategically neutral than they had expected. Any company's business technology evolves over time. At any given time it is the aggregate result of thousands of individual choices, most of which are made in apparent isolation, according to criteria (usually technical) that rarely seem strategic in nature. But the combined effect of all these choices can't help but have strategic implications. What we need, and quite often lack, are practical methods for translating strategic goals and objectives into concrete business practices – that is, methods that allow the choices that cumulatively direct the evolution of our business technology to be informed by our chosen strategic direction. Market focused strategies are driven by a company's market, not by its operations. Operationally focused strategic plans are appropriate for companies who don't plan to move into new markets and expect (and hope) that their share of their current markets will be frozen for some time to come. If this describes your company, developing market focused strategies for the acquisition and implementation of software—especially ERP systems will probably be of little interest to you. From this point on, we'll assume that it doesn't describe you, and that the future of your business depends on your success in keeping and gaining market share, and possibly on moving into new markets. Of course any genuine strategic plan does define the future of a company's operations – all of them – and market focused strategic plans are no exception. But a market focused strategic plan examines operations from the perspective of what the company's market wants its operations to become, not how operations might be evaluated one by one, in localized, tactical ways. Another way of saying this is that a market focused strategic planning process looks inwardly at operations from the market's perspective, not outwardly into the world from an operational perspective. Adaptive Growth's Approach Adaptive Growth's approach to the acquisition and implementation of business software—especially ERP software comes from 30+ years in what is now called the ERP industry. Our expertise in this industry was gained from the experience of having actually done ERP system implementations well for a long period of time. We've seen great successes, disastrous failures and everything in between. Over time we've come to notice something that took us a while to focus on, just because we never expected to see it. This is the simple fact that success or failure didn't seem to depend very much on which product was being implemented (even when it was ours), nor on who was hired to implement it (even when it was us). Success seemed to depend, more than anything, on the actual process of acquiring and implementing business software itself. This has led us to re-examine the reasons why some projects succeed and others fail, and to do so in light of what has become well established in many quarters about how project management should be done. We've found that it is possible to effectively reintroduce the responsibility for success into this kind of project. In doing this we have invented nothing, but we have gathered quite a few things together that have been well understood for years and we have packaged them as deliverables of knowledge transfer that is now our stock and trade for the acquisition and implementation of business software. The key to our approach, in the acquisition and implementation of ERP software, is showing companies how to maintain control of the buying process. The Standish Group published a statistic that 85% of all ERP system implementations fail to some degree and 25% of those implementations fail totally. Our experience shows that 60% of the "failures to some degree" are a result of failed expectations after the software system has been implemented. We know why these failures occur and how to prevent them. We would be delighted to tell you more. Please contact us to learn more about Adaptive Growth's approach for managing the risk of failed expectations after implementing business software—especially ERP systems. Back to top of question |
Contact Us
|
|
Overview • Market Focused Strategies • Business Technology • Internet Marketing • Adaptive Growth Library
What We Do • Who We Are • Who We Serve • Pricing • Blog • Contact • Sitemap © Copyright 2008 Adaptive Growth - All Rights Reserved. Web Services by dcosgrove@adaptivegrowth.com |