The Effect of the “Latest, Greatest” on System Development Projects

I learned just a short while ago that the mobile phone I received so excitedly at Christmas is no longer the latest, greatest model. Only four months later and it’s already been surpassed by the next generation. It’s not as out-of-date yet as Windows XP. Unlike XP, which is no longer being supported by Microsoft as of April 8, 2014, my phone will be supported, at least one hopes, for years to come. But it’s out-of-date nevertheless. People are buying the new version, not the one I have. 

These two occurrences—my phone and XP—remind me that the rapid evolution of technology is still hammering away at some of our critical information systems efforts, usually to the detriment of those projects. 

Some years ago, Professor Richard Donnelly, my mentor at GWU, and I analyzed the effects of rapid technological change on a large, complex federal system effort. We knew that most significant system development failures come down in the final analysis to lack of effective management. But we also surmised that project managers have not been given the necessary tools for managing some of the more insidious challenges to project success. We concluded that effect of rapid technological change on projects is one of those challenges.

Technological change is especially insidious because it can come at a project from multiple directions, often arriving in unrecognized forms. For instance, the solution space is the dimension external to the project from which we piece together the parts—hardware, software, middleware—that our system will employ. Let’s say the system makes use of an embedded sensor. The desire then will be to have the latest, greatest sensor embedded when the system is deployed. And this desire often prevails without objection, even when inserting the latest, greatest comes with the risk that it might not work exactly as tested with one it is replacing. The development environment comprises the tools we use to build the system. We trust those development tools to produce the results we need. But the development tools we use evolve even as we are using them and a new version of a code generator may introduce subtle incompatibilities with elements hidden deep in existing programs. So too, technological change in the business use environment can affect us as well, as when our leading user group decides to standardize on a different data visualization tool than the one they had been using, and that we had built into the system reports. 

In addition, technological change comes both incrementally and disruptively. On the project we studied, the initial 80 software and hardware products had expanded to 100 products after only two and a half years. Of those 100, only 60 were products from the initial list and of that 60, 30 had been already been replaced by newer versions. Each upgrade and new product not only affected the solution design and later in the project the integration scheme, but also helped to drain the dwindling training budget.

So how we do to guard against the impact of rapid technological change on our projects? 
Here are a few hints that we find useful at Phase One.

  1. Be aware of the threat. We need to add technological change to our risk identification taxonomies to be sure that we consider it early in our projects. (The newness of the technology is considered in some taxonomies but the tendency for technology to change rapidly is not.) 
  2. Adopt a management philosophy that resists easy introduction of new technology into the project design. Rarely the latest greatest does offer an overwhelming advantage over the current state, but unless it does, it should be rejected on principle. Just too much risk is involved.
  3. Develop quickly in small insulated packages. The Agile method that we use at Phase One allows us to design, develop, and implement quickly, before new technologies can work their way into the fold.
  4. Appoint a business solution architect in addition to our technical solution architect from the program side,. The business solution architect understands the business processes and culture and how they will be affected by the new solution. The latest, greatest may look great and it may even work great, but it may prove so disruptive to the users that it will never be fully successful.