The heart of a systems development production process is the work of implementation; designing, coding, testing, usability, scaling, architecture, refactoring. Its flip-side is the system in use, the feedback of users, usability in practice, unexpected uses, the goals users actually achieve by using the system, their met and unmet needs, how they obtain value from its use. In some sense the problems of production, or organizing teams to develop and maintain complex interdependent and interrelated digital systems is largely solved. Production poses a relatively well-known domain of problems and we have a variety of possible solutions available to address the challenges of intrinsic complexity and task interdependence, of scale and size of production, products and markets. What is less well understood is the domain beyond engineering; of the dynamics between customers, users, producers and the market, what we term ‘systems.’
Producing implementations for high-tech ambitions. ‘Implementation’ is the catch-all term for those production activities following at the end of an up-front requirements analysis, evaluation, and ‘design’ process (Bødker et al., 2004, Gregory and Richard L., 1963, Avison and Fitzgerald, 2006). Under this view of ‘implementation’ as the catchall for design, architecture, coding, testing, refinement, optimization, packaging and finishing a high tech project.
IMPLEMENTATION: DESIGN, TEST, AND DELIVERY
In the (traditional) view of systems development the SDLC brackets everything to do with concrete product production under the banner ‘implementation.’ (Figure below) Implementation covers product design, development, test and delivery. It appears strange that such wide-ranging and yet central activities of the SDLC should be relegated to what appears at face value one quarter of the lifecycle.
Figure: SDLC as interrelated activities
I might argue on this basis alone that the SDLC perspective on implementation is too broad (indeed dismissive of ‘production’) to be of much practical use. Let us however focus on contemporary views of implementation in high tech product life cycles.
Implementation has two faces, a technological facet and a social facet. Implementation covers everything dealing with the concrete realization of a product, everything that is hinted at during the more abstract phases or activities of requirements analysis, evaluation/design and maintenance (these comments must of course by qualified by your own working definition of the SDLC). On the technological side implementation deals with design, architecture, feature functionality, deployment, installation etc.; on the social side implementation deals with feature acceptance, usability, scalability. What is then does implementation encompass? Implementation may be viewed as construction (production). Implementation also often covers as rollout or delivery, and a third meaning of implementation is that surrounding organizational change management, in particular change supporting ERP implementations. In the case of ERP implementation the technology system is often quite static, a finished product, however flexibility available in how the product is ‘configured’ to deliver functionality. ERP configuration is therefore a more limited kind of systems development that may or many not work well within the institutional constraints of a particular organization. One way of thinking about implementation is as a problem of ‘introduction,’ something taking place in the conversational interactions surrounding analysis, design, coding, and test activities.
“The roll-out is where theory meets practice, and it is here that any hidden failures in the earlier stages appear” (Boddy et al., 2008)(Boddy et al., 2008)
Accordingly the byword for an implementation initiative is ‘order.’ A project should rollout in an orderly controlled way. However large-scale rollouts of technology are notoriously difficult and range over technological challenges and social/organizational challenges, for example;
“ERP implementation is an organisational change process, rather than the replacement of a piece of technology. It impacts strategy, structure, people, culture, decision-making and many other aspects of the company.” (Boddy et al., 2008)Implementation is therefore often characterized as a project management problem rather than a problem extending and impacting activities prior to and following production. In this guise implementation is a matter of project execution, separate from the ex-ante (up-front) process and separate from the ex-post (delivery) process. Such implementation projects more often than not necessitate further analysis, evaluation, and design alongside the work of coding, configuring and testing a new system.
MUTUAL ADAPTATION
Regression life cycles and agile methods have reworked the relationship between the activities of the SDLC. The Rational Unified process and methods like SCRUM anticipate all activities and phases will occur at the same time. Both overcome the chaotic consequence of ‘doing everything at once,’ by mandating highly structured roles and interactions, many mediated through distinctive techniques like ‘the planning game,’ ‘planning poker,’ ‘the on-site customer,’ ‘refactoring,’ ‘regular releases,’ ‘unit testing,’ etc. The big message for test and design work is that you can’t design without testing, and testing in all its guises is one of the strongest drivers for design.
The greatest test, and opportunity, for a new technology is when it is removed from the laboratory into the user environment. Implementation is the process of:
“mutual adaptation that occurs between technology and user environment as developers and users strive to wring productivity increases from the innovation.” (Leonard-Barton, 1988)
Implementation is therefore a natural extension of the invention process albeit the process takes place within user environments. The dynamic can be thought of as a kind of convergence towards an ideal end goal. However acknowledging the concept of equifinality (Leonard-Barton, 1988), our end goal may simply be the first solution that works from among a universe of possible solutions.
Implementation in the user environment generates learning that redefines our understanding of technology-in-use and therefore draws us back in to new prototyping, testing, feasibility, problem solving and idea generation. Likewise, technology implementation in the user environment generates new learning bout possibilities in user and corporate performance. Technology interaction enables possibilities for redefining tasks and roles, business function and business model. Learning through implementation is a balancing of tension between narratives of technologically driven change and user resistance. Instead Leonard-Barton offers the idea of continuous ‘re-invention’ to interpret this tensions, of learning through implementation that feeds in turn back into technology and corporate performance thereby enabling the productive (though unpredictable) dynamic of mutual adaptation (Leonard-Barton, 1988).
While most current presentations of the technology development dynamic now include user involvement they persist in characterising innovation as a flow from idea generation through to production. However including deploying in the user environment and user involvement within an on-going cycle of releases and updates incorporates the impact of learning that occurs. Mutual adaptation is a constant in the field of technologically mediated innovation and if recognized may be harnessed as a productive dynamic to drive both social and technologically oriented aspects of systems development. The implication for organizations involved in systems development is to “break down the firm separation of development, test and operations.” (Hamilton, 2007)
