As this year's Shop Talk Community events have progressed we have noted several trends – better software, better vendor partnerships, agile implementations and unfortunately the minor improvement in core system modernization project outcomes. In recent articles, here and in Tech Decisions, I have suggested that to some extent the seeds of failure are in the very definition of the project.

In a very important way the definition of a project and project success is changing. Traditionally we think of a project as the completion and delivery of a laundry list of specific requirements. The laundry list mentality leads to a binary view of projects that creates huge scope issues. The “if I don't get it now, I'll never get it” view of project requirements, based on many years of IT under-delivery, leads to the inappropriate inflation of project scope and all the attendant stresses and risks that follow from that. While requirements and the delivery of core functionality remain central to the success of any implementation project, the emphasis should be—and is—changing. Now we are beginning to focus on the delivery not only of business requirements, but also the establishment of core capabilities that support business drivers like “speed to market” and “straight through processing.” In addition to satisfying a list of requirements we are now in the business of delivering the software capabilities and potential to deliver (as yet) unknown requirements in the future; an endless stream of which we know are coming, we just don't know what or when. “Sustainable competitive advantage” is a phrase that gets bandied about a lot. The most important word in this phrase is “sustainable” which implies that a carrier must create capabilities that last over several years. If a carrier makes one innovative and disruptive move it may gain an advantage short term, but then other carriers will figure it out and follow. In order to sustain an advantage the carrier needs to be able to innovate repeatedly and incrementally over time. This can only be done by first creating platforms and capabilities.

One of the smart guys in our industry once likened the attempt to develop a legacy replacement project ROI to developing an ROI to put your kid through college. What you get for your money is potential, not necessarily specific results (or these days with the kid back in your basement guest suite, any result). In one important sense the end result of a legacy transformation project is not an “end result” it's a beginning. It's actually what you do with the newly established software over the next several years that is most important, not the laundry list of functions that got crossed off. This I think represents an important shift of perspective that has several benefits. One huge benefit is the reduced scope pressure that can easily warp or even sink a project. Another benefit is the longer term and frankly more realistic view of return on investment. Also, implicit in this view is the understanding that the project isn't ever “done.” Rather, improvements become doable and constant. In this world view the definition of project success changes radically. Project scope is never finalized and the “project” is never “finished”. The old “end” becomes the new “beginning.” Clearly, this is not your father's implementation project!