Breakthrough IT Strategy: Take A New “Path” To Success

by drjim on July 21, 2008

Shinsei Bank Used Paths To Implement Successful Enterprise IT Projects

Shinsei Bank Used Paths To Implement Successful Enterprise IT Projects

Businesses today spent roughly 5% of their gross revenue on IT and end up with very little to show for it. A couple of very bright guys over at the Harvard Business School (David Upton and Bradley Staats) have come up with a new approach to Enterprise IT Projects. They started their research from Eric Raymond‘s (programmer / open source champion) point-of-view: most IT projects are built using the Cathedral Approach:

  • they cost a lot,
  • they take a really long time to create,
  • and they only start to deliver any value after they are all done.

The Harvard guys believe that they have come up with a different approach that slashes costs while at the same time boosting the existing business and even making it easier to launch new ones. Sound interesting? Read on!

The new IT strategy is called the “path” approach. It assumes that there is no way that you can define all of a system’s specifications at the start of a project and so instead you just focus on laying out a path for the system to be further developed over time.

As a proof that this approach works, they studied the Shinsei Bank which is a a Japanese bank. In 1998 Shinsei was in a bad spot: it had had gone bust and (due to bad loans — sound familiar?) sold to the U.S. private equity firm Ripplewood Holdings. The very smart guys at Ripplewood got Masamoto Yashiro (former chairman of Citigroup Japan) to be the CEO of this struggling bank. Yashiro decided that Sinsei needed to compete based on a strong IT department. Here’s how they used a path-based approach to do it:

  1. Instead of implementing a new “big bang” set of business software, they took a different approach. They build a modular infrastructure that would allow them to put pieces in as needed.
  • They build new systems that mimicked the old existing systems that the bank was already using. This allowed them to switch folks over to the new system and then make gradual improvements without requiring extensive retraining.
  • They helped to ensure that the IT department was integrated with Sinsei’s business strategy by having the CIO report directly to the CEO. Note that this is different from many U.S. firms where the CIO reports to the CFO and is effectively “hidden” from the CEO.
  • The Sinsei business unit heads spend a lot of time learning to “talk IT”. This helps to break down internal communication barriers.
  • Sinsei IT application development projects start by focusing on the foreseeable business objectives — not the existing business environment. In other words, they think about how they want things to work, not about how they can automate how things currently work. The IT strategy is then built to meet this forecasted future.
  • This is key: the Sinsei business folks tell IT what they need. IT creates prototypes and has the business side use them. This causes feedback and new possible solutions are identified.

Finally, the Harvard boys identified three characteristics of a path based IT solution that will allow it to succeed:

  • Use a minimal set of standards: pick a few and stay with them. This will reduce costs and simplify the entire project.
  • Create Simple Reusable Solutions: This can be as simple as taking each IT problem, breaking it down as far as it can possibly go, and then implementing solutions to those individual problems. When the low-level problems are connected together you’ll have a flexible solution that can be easily adjusted if any component changes.
  • Create Solutions With Modularity, Not Just Modules: Getting back to the original definition of modules, this simply means that you can tinker inside of one module without impacting any of the other modules that make up a complete solution. A good example of this is to create a solution that can be rolled out in phases. This limits your risk, allows users to get used to the new business software, and allows time for changes to be made.

The Harvard boys conclude their study with one final note of caution: if you want to build on what you’ve accomplished with an IT project, then you need to ensure that you have the committed involvement of your end-users. Otherwise you can expect to fail. In the end, the Shinsei bank is doing quite well due in part to its strong IT department. The realization that most large IT projects end up failing due to internal resistance instead of any technology issues, the path based approach to IT projects has allowed Shinsei to completely re-invent itself.

Be Sociable, Share!

{ 3 comments… read them below or add one }

Jay September 10, 2008 at 3:30 pm

So, they have rediscovered Agile development methodologies? Or put a new spin on RAD. I think one of the more interesting aspects of this approach is with respect to their observations relating to ‘requirements’. They stated that, “there is no way you can define all of the systems’ requirements at the start of the project.”

Yes, it is difficult and time-consuming process that has its own advantages and disadvantages. Not to mention, even if you ‘can’ capture all the requirements, there is absolutely no guarantee they will not change ‘during’ one of the other stages of the development life-cycle that preceeds the actual Implementation phase when the system enters the production platform. Part of the problem with traditional life-cycles during the planning stage is exactly what they discovered… a disparity between planning and designing ‘curren’t needs instead of ‘future’ needs.

Another interesting point – Create Simple Reusable Solutions. I call this discovering ‘root causes’ within the process, tasks, people, or results. As both of us will probably agree, you can spend your entire career resolving ‘symptom issues’ within an information system only to discover new manifestations later on. The best approach is to discover the root cause and resolve that instead. This will typically eliminate other symptom issues that were inherently related to it.

Understandably, designing a system around simple, necessary, business principles creates a solid foundation for modular design. Developing components designed to perform singular operations reduces complexities, proprietary behaviors, and dependencies. Encapsulation and loose coupling of system components are essential to modular design and portability/scalability. Perhaps that just isn’t understood outside of the IT Industry, or established during planning phases.

Internal resistance is a consistent barrier for virtually any type of change initiative. Shifting the SDLC seems more like a symptom modification instead of a root resolution. Internal resistance is basically the culture of the organization. If the business has institutionalized infrastructure, policies, and discplinary/incentive packages around ‘the way things are done’, I don’t care what type of system methodology you use, you are going to encounter internal resistances. Perhaps not the ‘same old problems’, but project-related problems nonetheless.

Cultures that exhibit a desire to question norms, open communication channels, and incentive programs (suggestion box, open meetings, innovation rewards) are usually fertile ground for ‘path’ methodologies. Forward-looking upper management, project champions, and early support/involvment are critical to success. The approach management takes on ‘unfreezing’, ‘changing’, and ‘refreezing’ will either facilitate the appropriate environment, or not.

Selecting projects, systems within the scope of strategic vision is precisely what I feel upper management is there to do. Engaging in activities that do not support, or enhance progress in the strategic direction of the company should be seriously questioned and analyzed during the proposal phase by a multi-functional steering committee.


Daniel Craig October 6, 2008 at 3:59 am

Hello, I was looking around for a while searching for system development life cycle and I happened upon this site and your post regarding rough IT Strategy: Take A New "Path" To Success | The Accidental Successful CIO, I will definitely this to my system development life cycle bookmarks!


Dr. Jim Anderson October 6, 2008 at 10:20 am

Dan: That’s great news! Hey, just keep in mind that what made the Shinsei Bank’s approach so successful is that the different parts of the company (IT included) learned to talk each other’s language. Although this sounds pretty easy to do, in reality it ends up taking a lot of time! Good luck with coming up with a system development life cycle that works for you…


Leave a Comment

Previous post:

Next post: