As this year's Shop Talk Community events have progressed wehave noted several trends – better software, better vendorpartnerships, agile implementations and unfortunately theminor improvement in core system modernization projectoutcomes. In recent articles, here and in TechDecisions, I have suggested that to some extent the seeds offailure are in the very definition of the project.

In a very important way the definition of a project and projectsuccess is changing. Traditionally we think of a project asthe completion and delivery of a laundry list of specificrequirements. The laundry list mentality leads to a binaryview of projects that creates huge scope issues. The “if Idon't get it now, I'll never get it” view of project requirements,based on many years of IT under-delivery, leads to theinappropriate inflation of project scope and all the attendantstresses and risks that follow from that. While requirementsand the delivery of core functionality remain central to thesuccess of any implementation project, the emphasis should be—andis—changing. Now we are beginning to focus on the deliverynot only of business requirements, but also the establishment ofcore capabilities that support business drivers like “speed tomarket” and “straight through processing.” In addition tosatisfying a list of requirements we are now in the business ofdelivering the software capabilities and potential to deliver (asyet) unknown requirements in the future; an endless stream of whichwe know are coming, we just don't know what or when. “Sustainable competitive advantage” is a phrase that gets bandiedabout a lot. The most important word in this phrase is“sustainable” which implies that a carrier must create capabilitiesthat last over several years. If a carrier makes oneinnovative and disruptive move it may gain an advantage short term,but then other carriers will figure it out and follow. Inorder to sustain an advantage the carrier needs to be able toinnovate repeatedly and incrementally over time. This canonly be done by first creating platforms and capabilities.

One of the smart guys in our industry once likened the attemptto develop a legacy replacement project ROI to developing an ROI toput your kid through college. What you get for your money ispotential, not necessarily specific results (or these days with thekid back in your basement guest suite, any result). In oneimportant sense the end result of a legacy transformation projectis not an “end result” it's a beginning. It's actually whatyou do with the newly established software over the next severalyears that is most important, not the laundry list of functionsthat got crossed off. This I think represents an importantshift of perspective that has several benefits. One hugebenefit is the reduced scope pressure that can easily warp or evensink a project. Another benefit is the longer term andfrankly more realistic view of return on investment. Also,implicit in this view is the understanding that the project isn'tever “done.” Rather, improvements become doable andconstant. In this world view the definition of projectsuccess changes radically. Project scope is never finalizedand the “project” is never “finished”. The old “end” becomesthe new “beginning.” Clearly, this is not your father'simplementationproject!