This chapter provides a framework for technology project implementation in systems where the human is an integral element of the completed project. Unlike logically devised software codes and performance tested hardware components, human responses can be unpredictable when faced with the combined stressors of technological and organizational change, which occur when management dictates a technological upgrade. As such, the human interface is a dynamic system component that has the ability to degrade or disable system performance in ways unlike other subsystems. This leads to the idea that integrating employee preparation and participation into the design process from concept development through system deployment improves technology adoption and thereby overall system performance and acceptance of the technological enhancements. An analysis of peer-reviewed literature combined with the author’s industrial experience provides a ten-step process for converting an existing manual system to an automated or computerized version with emphasis on integrating the human element.
A project in its classic form is the set-up of a temporary separate organization with a single aim. This allows for a strong focus, but as documented in the thorny relationship between projects and organizations, the same trade-off between differentiation and integration applies here. A number of more or less sophisticated mechanisms to handle this issue, such as steering groups and user representation, are well known to the project communities.
The project management research community has certainly acknowledged this tension between integration and separation. In the PMI Guide to the Project Management Body of Knowledge (PMI, 2000) a key issue in Project Management is defined as the management of scope: To decide the amount of work to be done and to demarcate against the work that should not be done. This constitutes the rationale for a planned and manageable project, where the performed activities deliver the business purpose.
Researchers have challenged this classic model as they point out that an increasing share of projects has a wider scope than producing a technical solution. These projects are often termed business projects, aiming at organizational innovation and change (Winter, Andersen, Elvin, & Levene, 2006). Other researchers have found that there is a difficult choice between separation and integration: A well-run separate project, with its own identity, rationality and specific results, is not suited to implement its own results back to its mother organization. Correspondingly, the results from projects that are tightly integrated with the organization (but less innovative!) are much easier to implement. This means that project owners and managers actually face the dilemma either to accomplish innovation or to prioritize implementation (Johansson, Löfström, & Ohlsson, 2007).
Do these findings imply that service innovation should not be organized as projects? We think there is no easy answer to this, and for certainty there is a need for more knowledge on the topic. We note, as a point of departure, that the overall picture is that the “hard” and “separate” paradigm, as represented in the PMI Guide to the Project Management Body of Knowledge, is predominant. There may be sound reasons for this. One may easily argue that the phenomenal success of the project management discipline the past 60 years rests on the parsimonious clarity of the project concept, which allows the project manager to concentrate on his objectives.