How should firms decide whether to centralize or decentralize the selection and purchasing of critical IT infrastructure? … [Kristina McElheran’s] recent study forthcoming in the Journal of Economics and Management Strategy provides new evidence that, the advice of IT consultants notwithstanding, there is no single best way to structure this process. Firms are, in fact, more diverse in their approach than is widely recognized. The best choice depends critically on the specific business context in which the IT will be deployed. Communications of the ACM, Nov 2012.

I was invited to give a presentation to a Fortune 50 company on how to get the schedule right when managing a project. I have a couple of challenges when presenting my experience in helping organizations get to on-time delivery of their projects. These challenges deal with the context around what I did.

First off, I mention that we’ve been successful every time at getting organizations to on-time (i.e., within two weeks). Not only were we on time, but the quality of the product was dramatically improved.

Secondly, I spent a bit of time characterizing the organizations I’ve worked with. I admit that I’ve either been blessed or cursed for over 30 years at working with companies that were just really bad at delivering projects on time. One typical characteristic is that these companies have never delivered a project on time. Never. Once we dig up the data, it is typical that they’ll regularly estimate to deliver in “a few months” but average something like nine months to actually deliver them. In another instance, where a company delivered dozens of consumer products a year, they averaged three to four months late on every product, with no new product ever being on time, and they were as late as six to nine months at finishing a promised product.

So while I’ll tout my method as a way to propel an organization to on time with good quality, it must be recognized that there is a context where this works well. It is quite possible that in another context what we did might have had little effect.

Fundamentally, understanding context is nothing more than fully, as thoroughly as possible, understanding the problem we are facing. It is avoiding the “one size fits all” or the “just buy this tool” or the “just take this course” approach to trying to fix problems or trying to improve. These kind of approaches happen in part because we often try to sell great ideas simply, and hence it often threatens to oversimplify what it really takes to be successful with any given methodology.

The ACM article is about when we should centralize or decentralize the purchase of technology projects. The answer is, of course, that it depends upon our context and in any one year we may need to lean more towards centralized or lean toward decentralized purchases. In the Air Force for example, in some years it made the most sense to lease equipment but in other years it was more advantageous to purchase.

So, it depends upon what it going on, what the market looks like, what the technology is, what the risks are versus the rewards, and all the other typical factors. We decide based upon what we know and learn — the context. We may, for example, observe what everyone else is doing but before deciding we need to ensure that what everyone else is doing is really what we need to do (e.g., the financial industry and “toxic” mortgages — did everyone really need to do that?).

Regardless of how sexy or cool or edgy the solution looks, we always need to ensure that it makes sense in our context and hence to our organization. If it does, then great, lets go do it and reap the benefits. If not, let’s admit that and find something more appropriate. Maybe in a few years it will be us that everyone points to and says “hey, they’re successful — lets’ do what they’re doing!”

Are you making decisions based upon your full understanding of the context of your project?

Thank you for sharing. Sharing and comments tells me which articles are most helpful to my readers: