Although the causal connections that link the chain of technological adaptation described in the first part of this article can be readily debunked, the intuition behind the story of Stephenson’s gauge--that technologies are more easily accepted and more rapidly assimilated when built on pre-existing standards and processes--is compelling, and is validated by our common experience when applying a new technology to a current need.

But success in using technology--measured by its return on investment--appears to depend less on the technical facility and functional richness of the technology itself than on the context in which it is deployed. And that context is created by the interaction of stakeholders in the technology with the processes that create alignment between the scope of work to be performed and the value of the work accomplished.

To varying degree, all technologies are disruptive when encountered for the first time. Even when we are shown how to use and accommodate a technology for its intended purpose, we are nevertheless challenged by negotiating the learning curve that using the technology in our own context demands of us. This learning curve comprises two domains: the acquisition of competency in the technology, and integration of the technology with pre-existing methods of working.

For obvious reasons, most learning effort is directed at the first domain--achieving technical competency--because that is where the practical value of the technology is realized. Hard skills have an immediate application and payoff. By competently applying the technology to a business problem, these skills yield tangible results in the form of a new product, service or other artifact. Success in using the technology is further exhibited in opportunities for qualitative improvements--ease of use, speed of execution, for example--that enhance creation of the resultant work product.

But when introducing technology that is new to the enterprise, integration with pre-existing methods of working is the harder part of negotiating the learning curve. And it can become much harder where there are no methods of working to accommodate the new technology.

Though they often begin in analysis or emerge from research and development activities, methods of working generally become established through the iterative, collective learning curve of the enterprise, a process that creates cultural credibility around how things get done. But the inertia of cultural credibility can also create resistance when introducing a new technology, especially where its deployment is not congruent with the status quo of how things usually get done in the enterprise.

Many IT projects fall short of their goals not because of any inherent failings in the technology selected, but because the enterprise is unable to integrate the technology with its current methods of working. But without the capability to apply it effectively, a new technology’s potential value to the enterprise may not be realized.

In this context, the critical function of project management is to acculturate, or mediate, integration of the new technology into the enterprise’s accepted methods of working. This statement may sound like a theoretical proposition, but is actually grounded in direct observation and experience from a recent project.

In order to fully realize the richness and facility of the target business model, product management needed a better way in which to specify, create, test and deploy the various business functions upon which the operation of the model depended. On the backend, the challenge for the product development team was how to code and implement the desired functions with reduced cycle times and with better quality results. In other words, how to do more, do it faster and do it better. A number of coincidental factors provided an opportunity to achieve this.

First, both teams were physically co-located on site. There was immediate and almost constant face-to-face interaction and communication between the two. Second, both teams were small, comprising no more than four or five members each. Thus, issues could be discussed, problems resolved and decisions arrived at within relatively short timeframes. Third, both teams recognized that the current waterfall-based product development lifecycle model--from requirements gathering, specification, coding, verification, testing to implementation--was becoming moribund, and needed refreshing. Better software tools could be an enabler for this.

The legacy database-centric application, together with poor scalability and performance issues, gave further impetus to the development team to renovate the current product architecture and move away from its reliance on Java. In looking for a solution to these problems, the Ruby on Rails (RoR) open source Web development framework was selected. RoR was attractive to the development team for a number of reasons.

An average RoR application has about 20 to 30 lines of configuration code as compared to the hundreds of lines of code typically required of a medium-sized Java-scripted Web application. This reduced code footprint made for fewer bugs and shorter coding and QA cycle time, especially with respect to creating and automating the testing of product management’s use cases. Additionally, because RoR is agnostic of database architecture, it enabled development to decouple the business applications from the database and avoid using code-intensive customized stored procedures and functions.

As a scripting language, RoR was also attractive to the project’s developers because, as RoR’s creator David Heinemeier Hansson remarked in a 2007 interview, it enabled them to get stuff done “in style”. It also gave developers the ability to deliver functionality much more quickly without, as Hansson further observed, “feeling like a hack doing it.” It also helped that RoR skills commanded a premium within the development community.

While the technology pull of these characteristics made for easy adoption of RoR by the development team, some adjustments needed to be made to integrate it into the product management team’s methods of working.

In particular, because the product team had a pre-established method of working with the development team, the introduction of new specification constructs--such as state diagrams and user scenarios--that mapped prototyping of the desired business functionality much more closely to the finished product could be readily adopted. This created positive momentum among the team, which facilitated a relatively smooth transition to RoR-based product development.

The necessity of project management is that it keeps project activities focused on meeting stakeholder expectations and satisfying their wants and needs. This is commonly understood to refer to the tangible goals and business objectives of the project. But it also refers to the methods of working by which the project is accomplished.

Technology is generally deemed fit-for-purpose by an enterprise when it passes a number of selection criteria, usually represented by technical functionality (or its utility value), cost of ownership, compliance (standards and interoperability) and support of business objectives. But while its selection cannot be wholly constrained by the status quo, consideration needs to be given to a candidate technology’s alignment with an enterprise’s methods of working.

It cannot simply be left to happenstance to find out whether or not the technology can be productively used in the context in which it is deployed. Introducing new technology into a project is as much about the process of assimilating the technology as how the technology itself is used by the project. This is the learning curve that all projects must address. And those that don’t may very soon find themselves running off, rather than on, the rails.

You can find out more about Ruby on Rails here. Ian Whittingham, PMP is a Program Manager at Reuters Insight. The views expressed by the author in this article are his own. You may contact the author directly at ian.whittingham@reuters.com.

Running on New Rails (Part 2)