11.1 Modelling at the Project Level

This section addresses the structuring of a digital initiative at the project level.

An enterprise’s digital transformation is executed via a sequence of smaller, yet coordinated transitional steps in the form of individual business projects.

Contrary to traditional project and business analysis techniques, a digital methodology must meet several important criteria:

Speed and agility: Most important in digital projects are the speed and agility with which results are produced. Classical project approaches, based upon detailed use case analysis and process modelling, tend to be too slow and rigid for the digital world. Despite the fact that the results of such heavyweight approaches are in fact also required in the later stages of every digital implementation project, cautious and comprehensive analysis still constitutes an obstacle to the required agility. This is called the ‘analysis-paralysis problem’.[1]
Strategic contribution: A suitable project methodology must ensure that every individual project fit into the bigger strategic picture and contributes to it. This means that it is not sufficient that the project’s delivery scope is limited to its mandated business functionality – the project must also meet the aspirations of the digital strategy as a whole. This includes, for example, the reuse of existing modules, as well as basing the implementation on technology standards.
Industrialised IT ﬂexibility: Many winners of the first wave of digitalisation, for example, Amazon, have demonstrated that a highly professionalised IT is the foundation of their business. Without it, neither an outstanding customer experience nor sustainable profit margins can be achieved. In doing this, it is crucial to keep control of the complexity and effectively coordinate several parallel IT activities.

It is evident that most traditional methodologies are not appropriate to meet these criteria. For example, the so-called waterfall project methodology cannot support the necessary speed and coordination of many simultaneous activities. On the other hand, purely agile approaches have their limitations in supporting strategies or implementing innovation at the enterprise level.

Independent of the agile approach, we recommend breaking down any important project into three phases, each representing an increasing level of granularity (see table below).

During Phase 1, activities are described at a level where the impact on the enterprise as a whole is mapped out and a clear overview in the form of an overall roadmap is achieved. In other words, in Phase 1, project candidates are evaluated. This evaluation also requires a costs-benefits-analysis. At the end of Phase 1, there is a formal project signoff. A project manager is nominated, and budgets are assigned.

In Phase 2, the findings are detailed further, clarifying the responsibilities of the various organisational units, compiling an overview of required use cases and services, and describing the necessary IT components.

Finally, in Phase 3 the undertaking is detailed to a level where the specific implementation of individual building blocks can be mandated.

Phases 1 and 2 typically take a few weeks. They provide an overview at the enterprise level, as well as an overview of the individual project. At the same time, the basis is built very rapidly to allow critical structural decisions to be made – the structure and scope of organisational units and IT component delineations. Large-scale implementation efforts are avoided until the moment when specific project implementation is launched. It is paramount that each phase covers the whole scope of the project at the appropriate granularity level.

There are two very delicate milestones. The first critical milestone is the project approval at the end of Phase 1. Equally important is the second milestone at the end of Phase 2. At this point, we need a full overview of the required services and use cases (or process groups, if you prefer). The overview is of paramount importance for a proper implementation.

Most importantly, the impact on the business case, organisational units and existing software components should be clear before beginning implementation. Enterprises applying a two-speed approach should be aware that Phases 1 and 2 cannot be accelerated or omitted. They provide the frame within which high-speed projects can deliver efficiently. Special care must be given to the fact that developing reusable components and assuring the project’s contribution to the overall strategic direction are not the core interests of the project per se, but necessary in the strategic context. In order to balance project and strategic goals, several measures should be taken:

Highly qualified and motivated architects must be pooled in order to assure they can be deployed in a ﬂexible manner into multiple projects.
Documentation of technical and functional standards as well as processes is needed as the basis for the assessment of individual projects.
Governance and quality gates must be defined (this must be done with a sense of appropriateness so as not to overburden business projects).
Strategic and overarching project targets must be financed from outside the individual project (for example, utilising the enterprise’s reusable business components or communication infrastructure).
Appropriate organisational structures and funding mechanisms must be put in place (for example, as part of the CDO Office or an enterprise architecture team).

Dedicated efforts must be taken to install a digital project methodology. It is evident that this approach overcomes the limitations of traditional project methodologies with their typical organisational, planning and financing constraints.

_____

[1] Boss, J.: ‘How to Overcome the “Analysis Paralysis” of Decision-Making’, Forbes, 2015