Cogenitive

The company I work for is in the process of wrapping up one of the biggest system implementation projects I’ve worked on, and probably the biggest that the company has ever undertaken.  As you do when projects start to wind down, I’ve been thinking recently about some of the things that didn’t go particularly well, and why.  One of the key issues we’ve faced, I think, has been with the alignment of incentives for the business users (whose participation and support are always critical to the success of any project) with the overall objectives of the project and the expected benefit to the company.  By way of background, this project involved the modification and implementation of some software developed in the US by our UK operations.   This project was originally estimated at 12-18 months of effort.  We’re now at about 48 months, with probably a more extreme multiplier on the cost.  I wrote an e-mail on the subject a few months ago that I think captures some of the issues fairly well. 

One of the fundamental assumptions that underpinned the initial analysis and business case was that the UK operation would substantially adopt US business processes and organizational structures.  This lead to the assumption that the level of system change required would be relatively small.  One of the basic implications of this assumption is that UK business users would be required to significantly change the way they do business, which implies additional work, disruption, and discomfort as they go through the required transition.  Those business users are the same resources that must give shape to the project and provide input to the requirements, analysis and design process for the (inevitable but presumably minimal) system modifications that will still be required to support the UK business.

 As we’ve moved through the project there have been hundreds, probably thousands of decisions that have needed to be made that have hinged on whether the UK must be able to continue to do things the way they have with their current system (with the associated system development time and cost to modify the new system) or can change to doing things a new way.  Unfortunately, but unsurprisingly, the individuals charged with making those decisions are almost always deciding in favor of additional system development to support doing things they way they do now.  This is unsurprising because in most cases they have almost no incentive to make a change, no matter how small it is, and there is almost always a cost to adopting a new process.  In some cases, the cost to them may simply be learning a new way of doing things, in others, they may actually be giving up a level of functionality to which they’ve become accustomed.  In addition, they may not know if the way things are done now is truly necessary, due to market or internal convention, or due to current system limitations, so they’ve generally erred on the side of caution, assuming that things are truly necessary if they’re not sure.

Counteracting the tendency to want to maintain the status quo is the desire to keep project time and cost down by adopting US processes & existing system functionality.  As IS is, in large part, managing the project and is the primary source of cost & time to implement new functionality to support UK business processes, IS has been asked to attempt to keep this under control.  But of course IS has no authority to enforce it (and rightly so).  If IS starts to say no to a significant number of the system changes requested by business users as a result of the day to day decisions, we lose their support.  If we lose their support, they’ll stop participating, and without their support and participation, the project will fail.  I believe IS has pushed back as hard as we can without alienating the users (too much, anyway).

With a project the magnitude of what we’re undertaking, that touches all parts of the organization and that requires significant compromise between parallel user groups in the US & UK (i.e. reporting lines for stakeholders and participants only meet at the CXO level), the only people with any ability to enforce the change required by the original business case are senior executives.  Even at the level of the workstream leads, the incentives are pretty weak to force major change to business processes.  It’s also extremely difficult for a senior executive to effectively manage the decisions that are resulting in the increase in project scope.  The increase in scope has largely been the result of a large number of small decisions made at the line management level and requiring detailed knowledge of specific business processes and system functionality, rather than a small number of large decisions that can be readily made by a senior executive.

I would also argue that the original assumption (that the UK would be willing to accept the business processes implicit in the new software, i.e. the US business processes) is fundamentally flawed.  A project of this magnitude requires significant support and effort from just about everyone in the business, and ultimately requires buy in and acceptance from a large majority of end users.  Given that there’s little tangible short term benefit to those end users to make the changes and put up with the disruption that are implied by that basic assumption (however small they may be, and unfortunately, in this case, they’re much larger than anticipated), I’m not sure you would ever have the level of support required for the project to be successful.  To get their support and participation, you need to offer them some short term benefit, which will (has) result in increases in project scope.  Stakeholder and project participant incentives need to be aligned with project outcomes and objectives in order to have a chance at succeeding, and I’m not sure the original business case assumptions left enough room for this.

Three other related (and probably more obvious) issues/assumptions are/were:

We assumed that US & UK businesses were fundamentally pretty similar, and that adopting US processes wouldn’t be too difficult.  I think this was probably a bit optimistic, and that we had an insufficient appreciation of the difference between US & UK business processes (and the reasons for/ability to overcome those differences)

Insufficient appreciation of the level of additional functionality required to support the UK market environment – we thought we were 75-90% of the way there with the existing pilot system.  We were more like 10-20% of the way there (which implies a multiplier of 3-9 times original estimates).

The benefits of standardizing on US processes and system functionality mostly accrue to the global organization in the form of lower project cost, cost savings from consistent, streamlined business processes, and improved sales & marketing capability enabled by the system.  In the long run these should benefit individual employees through greater company profitability, but at the cost of significant short term disruption, up to and including the loss of a job for some employees.

——————–

Here’s an example, from a very recent e-mail discussion of system design.  While this is not specifically related to doing things the US or UK way (as the functionality in question is UK only), it’s indicative of the way decisions have been made.

(Me) If the same customer has advised two amounts (e.g. under separate reference numbers), could those go in separate message segments, or are they required to be in the same segment?  It would be simpler to implement if it’s acceptable to report them under separate segments.

(Business User) They are required to be grouped and cannot go separately. The reason for this, is that custoemrs get charged £?? per segment and this is a mechanism they use to keep their costs down.

(Me) OK.  We’ll adjust system design accordingly.  Out of curiosity, how often does this happen and how much do they get charged per segment?

(Business User) It doesn’t happen a great deal of the time but when it does it stays with the contract throughout its lifetime, but that’s irrelevant really. Underwriters are motivated by cost savings and we are obliged to assist them in doing so by using the system in the most cost effective way. The ballpark figure is £1 per segment depending on volume.

While it may seem ridiculous, this is an entirely rational response on the part of the business user.  If we do not implement the more complex method, they’ll be criticized by their customers for not supporting the cost saving strategies that they have in the past (this flexibility is currently available in their existing system), even if the cost savings is only a few hundred pounds a year.  The only benefit to them of giving up this functionality is getting the new system implemented slightly sooner, and for slightly less cost.  Given the choice, the users will take the longer project time to get the functionality they want.  We’ve estimated that the functionality required to implement the more complex method will add 3-5 days of effort to the overall implementation, including design, development, QA, UAT & Integration Testing. Take the few additional days for this one decision and multiply by the hundreds or thousands of similar design decisions that have been made and you end up with big numbers.

If you’ve gotten this far in the post, you’ve probably realized that there are a lot of issues to explore here, but as this is already a long post, I’ll take them up in subsequent notes.