Delivering Projects Is Like Building a Lego Castle

Organizations must be able to adapt themselves to survive in the long run. This is relevant now and it will be even more indispensable in the future, when “agility” will become the new norm. “Adapting” usually means executing a larger or smaller change initiative to achieve a certain objective. This could for example be an implementation of a new product, system or process or even implementing a new business model or disposing of one.

Traditionally, organizations start a business change as follows: A senior (board) manager has a good idea, the idea is worked out in more detail and then supported by a financial business case and a high level plan. When this is approved, a program team is defined, with a steering committee etcetera and the project or program starts to execute and deliver results (be it iteratively, using agile principles, or more traditionally using waterfall-like approaches).

To be honest, I don’t think the core of this process will change much in the future. The manner and focus of the delivery will however change fundamentally. Today, most organizations realize change mainly by implementing new capabilities with a highly internal focus. Applications are bought on the market or built internally, the internal business processes are adjusted to work with the applications (or vice versa) and the applications are integrated in the existing internal IT landscape.

What do you think will change in project delivery?

In the future, I expect that when a project, program or even a business transformation is delivered it will be done completely differently. Let me explain how I envision the future. I am a strong believer, together with many other people, in the concept of re-usable building blocks. In IT terms, I believe that an API (Application Programming Interface) and SOA (Service Oriented Architecture) are based on this concept. More practically, I love it when the sound from my iPhone with Spotify can be easily streamed to my stereo, because they both support Airplay. And it is great that I can seamlessly pay through my own trusted ING ebanking app when buying something on the Aliexpress webstore in China.

This concept of connecting multiple re-usable building blocks is what I see as a key concept that will dramatically change the contents of what is delivered in future transformation programs, but also how programs are delivered. Let’s start with the what part by using an example that may not even sound too far-fetched. How nice it would be if an Uber driver would deliver your Albert Heijn groceries and your new Zalando shoes in one go? And while the Uber driver drops-off the deliveries in a secure and cooled vault from Lips at your home, it also picks-up the Zara shirt you don’t like and exchanges it for an H&M shirt which you like better (and Zara and H&M mutually settle the payment).

Now imagine what it would take to implement a use case like this. Any individual company that I mention in this case would probably not dare to start such an initiative based on the business case, complexity, risk and dependency on so many external parties.

What do you think projects and programs will deliver in the future?

Companies that survive 2025, will be the companies for which delivering a change mentioned in the example above is business as usual. This means that the core component of projects and programs will be the integration of services from other companies that deliver reusable and standardized building blocks. In 2025, these building blocks will not be delivered by immature “start-ups” (anymore), but by mature small and large organizations. One of the core competencies of each company will be to open-up and share their building blocks to the rest of the world and re-use those of others. This is not limited to software (API’s or apps) or raw materials, but this can be any combination of software, people, robots, services and other (physical) resources. This concept is not only relevant for the retail sector, but also the business-to-business and wholesale markets. You could apply this for example at consulting firms. To be able to stay relevant as a consulting firm, you must be able to deliver solutions that seamlessly fit into another company’s structure. For example, I can imagine a consulting firm that is delivering “business case as a service”. This service uses standardized input from other services to calculate the costs and benefits of a plan based on standardized benchmark data and deliver standardized output that can be used as input for standardized business plans etcetera.

Let’s call these combinations “business capability solutions” for now. By 2025 there will probably be something like a “business capability solutions” store, comparable to current app stores, where one can order and rate the solutions.

And how will programs be delivered in the future?

By 2025, the most successful companies will be those companies that are able to execute change in the best and fastest way. This means that businesses must be the best and fastest in selecting the most promising business capability solutions. In addition, they must be able to connect individual solutions with each other and integrate them with their internal existing systems, processes and people to build innovative new solutions (the Lego concept).

This is not how businesses and projects are run nowadays. First, an organization must develop capabilities that are able to scan the market for new business capability solutions and be creative in inventing new combinations of solutions (maybe even together with competitors). For the shorter term these projects will probably be done in separate “innovation departments” or “labs”, but in the longer term this will be business as usual and this role is fully embedded in the product management capability of an organization.

The approach and required capabilities to deliver change will be different. The core activity of a project will be selecting and connecting the various business solutions or building one’s own re-usable business solutions (pre-fab building).

What will be the demands on the future project organization?

By default, a project team will not only consist of members of the internal business, IT and project members, but also of members from the various external solution providers. Referring to my simple use case above: all members in the chain of solutions would probably need to be involved in the project, all with different roles, (financial) interests and priorities. This is a nightmare for traditional program management techniques that are often governed using the authority of one “senior responsible owner” or one “project sponsor”.

These types of future projects need to be organized in a different way to be successful. I expect that separate small “joint venture”-like companies will be setup on a temporary basis to deliver the projects. These companies are funded by the multiple beneficiaries of the project results and are managed by a program manager who is more or less independent from the solution providers. It is not hard to imagine that a project is impossible to manage if each solution provider uses different project delivery methodology and tools. That is why I expect that we will also see a strong standardization of these methods, deliverables and tools with, again, “reusable building blocks” that can be used in other projects/joint venture companies.

The project world of 2025, will be a simple world of building Lego castles. And the project world in 2035-2050 will probably be a world where the building of these Lego objects is fully automated. The involvement of human beings in projects will be limited to defining innovative ideas, whereby the project execution to realize these ideas is fully automated. And by 2050, these innovative ideas will most probably also be coming from the artificial intelligence of neuromorphic computing devices…