Managing Change through Successful Projects

This page discusses the Dragon1 theory and software on how to use Enterprise Architecture to manage change through projects in your organization.

It will create a common mindset among people mapping interactive visualizations together with the team and have them used by stakeholders managing successful projects.

Learning Objectives

• What is a Project?
• What is Change?
• What is Mainstream Enterprise Architecture?
• What is Dragon1 Enterprise Architecture?
• What is an Architecture Framework?
• What is an Architecture Design Assignment?
• What is a Program of Requirements?
• What is a Total Concept?
• What is an Architecture Principle?
• What is the First Principle?
• What are the Current State and Future State (AS-IS and TO-BE)?
• How to use Interactive Visualizations managing a Project?

What is a Project?

A Project is a temporary organization focused on producing a predefined and unique product, service, or result.

A Project preferably does not last longer than 9 months and preferably has a budget of fewer than 5 million euros.

A Program is a group of Projects.

A Project Map is a generic overview of the structure of a project.

What is Change?

Change is something we all come across. Every day, the organizations we work for or work for are different from the day before. This is because the needs of people change, because of new legislation and because of new scientific discoveries and technologies from the industry, etc.

The smartphone is an example of a huge change in everything. The smartphone has changed many things, such as how we solve crime cases. All stories in movies now are different because of the possibilities of the smartphone.

In organizations, we want to manage many changes (or transition or transformation), for instance, introducing a new product, business process, or information system. In all these cases, we want to manage the change: to set goals, measure and check progress, and (re)direct the projects. Some of these changes are fundamental, drastic, groundbreaking, and changing the rules of a complete industry. In that case, we call the change an innovation: think of Google, Airbnb, and Uber.

RISK

In organizations, we also define RISK. Risk is defined as the costs of failure, according to Dragon1. We want to manage the risk during a change. In other words, we want to minimize or mitigate the cost of problems we encounter during the change. Suppose we need to replace a software application. That could disrupt customer service, which could cause fines, penalties, or even lawsuits.

Did you know that most product introductions fail because of compliance issues with legislation? So, that is an important risk to manage.

Many organizations today are having a problem introducing digital products and services because they don't know how they will impact their real-world products and services. Think here: Microsoft with MS Office Desktop software versus Amazon AWS and Google Cloud with MS Office 365.

Managing Projects prevents project failure

Did you know that in 2020, 70% of all projects failed, and did you know that 90% of yearly targets of strategic goals were not reached? One could say that these two facts make it clear that every director and manager needs Enterprise Architecture.

Managing transformation, transition, or change puzzles a director and a manager. How to do it? How do you deal with risks, budgets, and showstoppers? How do you keep the stakeholders calm? How can suppliers collaborate with the employees and with each other?

How to deal with the change in processes, applications, technology, and CULTURE? All these questions and so few answers.

Managing Change of Workforce

Note that not only the products, services, processes, and IT technology change but also the workplace and workforce. In our organizations today, four different generations are often present, bringing along four different types of culture, and these four different generations vary in presence and impact everything. And how are you going to manage that change?

Enterprise Architecture (EA) is, correctly used, a management instrument that can act as a bridge between Strategy and Transformation. This is because Enterprise Architecture is a total concept for a structure and is documented as an integral Business/IT design. 'EA can act as a bridge' because it won't act as a bridge if you don't apply Enterprise Architecture properly.

Enterprise Architecture is useful for a director and a manager to help change, transformation, programs, and projects succeed.

Strategy, Architecture, Transformation, Projects

Dragon1 Enterprise Performance Framework.

Strategy is defined (in the Dragon1 open EA Method) as 'a coherent set of goals and efforts for directing an organization'. Transformation (Business Change in the visualization above) is defined as 'a process of profound and radical change that orients an organization in a new direction, taking it to a much higher level of effectiveness'. Architecture is defined as a total concept for a structure, and Enterprise Architecture is a total enterprise concept for an enterprise structure.

With these three definitions, you can tie the three words together: Strategy provides the WHY and WHAT of where the organization should be heading. Architecture converts it into a grand integral business/IT design to build the new organization. Transformation is the actual process of changing the organization piece by piece using a grand design.

Managing Projects without Enterprise Architecture

As strategy and transformation are done in almost any organization, but without doing enterprise architecture, we see that many programs and projects are started up, all using their own vision and design, blueprint, and roadmaps to realize.

One can call this unstructured decentralized transformation. This causes a lot of programs and projects to fail. The alignment between architecture projects is impossible, and the project results do not amplify but block each other. Showstoppers are around every different corner.

If a change is not that complex, one can succeed by accident or by being lucky without using Enterprise Architecture. In all other cases, Enterprise Architecture can be considered a prerequisite for success. So the challenge is, how to apply Enterprise Architecture so that it leads to coordinating all programs and projects integrally?

Mainstream Enterprise Architecture

Enterprise Architecture today is practiced in two ways: as real Enterprise Architecture and as Strategic IT Management and Consultancy (a.k.a mainstream Enterprise Architecture).

Mainstream Enterprise Architecture has an IT focus. In this case, people may hear the word 'architecture', but they think, will, and act 'IT'. In mainstream enterprise architecture, the architects see themselves as consultants who, without being asked, advise any stakeholder on what to do and how to improve things so that IT better supports the Business Processes. But this is all often without business cases and support from the boardroom.

A fundamental change, for instance, implementing standards enterprise-wide in organizations without the support of CxOs and enough budgets for architecture projects, will not have that much effect. Before you know it, in this situation, stakeholders will continuously ask WHY the architects want to have all these costly state-of-the-art solutions that no one asked for. You end up as an architect trying to explain what architecture is and why it is needed. JUST DON'T DO THAT! Building architects also never explain what is their method and framework they use, and that is for a reason!

With mainstream EA, you can certainly increase the maturity of your IT Management, Information Management, and Information Security. But you won't be able to change business models fundamentally, move supporting walls, shorten the time to market for products, or transform the organization enterprise-wide into a digital company. There are also things called human, culture, money, and raison d'etre (the existential reason of the company). And they are miles away from IT but are part of real Enterprise Architecture.

Mainstream EA produces hideous diagrams that are never used to support decision-making by managers. Everybody knows the process and application landscape created, for instance, using the ArchiMate model notation, which only the architect understands. These models may be necessary for some suppliers or engineers at one point, but they can never be the most important diagram to map as part of the grand architecture design.

Dragon1 Enterprise Architecture

Dragon1 Enterprise Architecture is about designing a total concept for an enterprise structure, where that total concept acts as a bridge between strategy and transformation. There are various domains with total concepts that can be designed: business architecture, solution architecture, etc. A diagram that shows which domain architectures can be designed is called the Enterprise Architecture Framework diagram in Dragon1 [read here for an example].

Architecture Design Assignment

NEVER EVER create a design without an owner/client asking for it. Because who will approve the requirement and the design and pay for its realization? (Know that design is another word for building plan).

The CxO is an architect's natural owner/client. A CxO is accountable and responsible for certain parts of the organization and has the power and privileges to change these parts. Create a portfolio of visualizations of the work you have done before and use that to get an official Design Assignment or contract for an Architecture Study from an Owner/Client.

Program of Requirements

Designing a total concept for an enterprise structure is simpler said than done. As an architect, you are the moderator of creating a Program of Requirements per strategy, organization, solution, or project. In this PoR, you write down the mission, vision, stakeholders, strategic starting points, needs and requirements, etc. If your PoR is ready and validated by the owner/client and stakeholders, you can create a total concept.

Total Concepts

A total concept consists of concepts. In your PoR, you will find direct or indirect demands and requests for concepts or elements and components that are part of the concepts. Of course, you don't want product names and brands in your Total Concept, you restrain to elements (logical functional parts) and components (technical physical parts). You are now selecting concepts, using your experience and creativity, and doing some Proof of Concepts. You draw sketches and principles diagrams and write small and smart business cases for the owner/client and stakeholders so they approve your proposal to make the concepts part of the architecture (total concept).

Dragon1 defines that the Owner/Client tells the architect who should be seen and used as stakeholders to collect or get requirements from. Dragon1 also defines the architect as creating a stakeholder onion diagram and collecting stakeholder requirements using use case diagrams, customer journey diagrams, and all kinds of sketches.

Architecture Principles

In real Enterprise Architecture, or better said, in the Dragon1 open EA method, a principle is about the way a concept works and produces results. Architecture Principles are (promoted) principles that are valid throughout the structure. So, a total concept consists of concepts, and every concept has a first principle.

First Principles of Concepts

A first principle reveals or describes the enforced way the whole concept works, producing results. A principle consists of elements (at the logical level), components (at the physical level), and out of technical products (at the implementational level of abstraction).

As an architect, you are searching for elements and components present and missing in the organization. As an architect, you can analyze what percentage of that concept is already available (% applied) in the organization and how mature (m=?) it is. In Dragon1, write down the %, m, t, and $ for every concept. T is the implementation time, and $ is the implementation cost.

Current and Future State (AS-IS and TO-BE)

You don't need to, but you can first create an overview of the current organization at the four levels of abstraction (per domain or as a whole). You can differ between generic overviews, medium overviews, and detailed overviews. Next, project or re-engineer the concepts and principles by looking at the elements, components, and technical products. As an architect, you always need to create at one time in your project (Architecture Study) the future state of the organization. In Dragon1, we call the visualizations you create at the implementational, logical, and physical level the Structure Diagrams. The diagrams at the conceptual level we call Architecture Diagrams.

Managing Projects with Interactive Visualizations

Although it is mentioned before, here we repeat the core activities of managing change in the organization through projects:

• Setting goals
• Measuring and Checking progress
• (Re)directing people and steering projects and processes

Isn't it great that with the interactive visualizations, any stakeholder can do all three of them?

Next, we are at the point of the intended change. There are up-to-date visualizations placed (published) in the Viewer. This means every stakeholder (by logging in) can access the visualizations. And they are meaningful to them because, for one thing, many of the stakeholders participated in creating them.

As an architect (or creator of these visualizations), you must promote that stakeholders use the visualizations in discussions, meetings, and presentations. If something is not correct, let them comment on the visualizations. Also, try to get the visualization approved and have an official status. In that way, you will automatically trigger the visualization usage.

With these visualizations, you help all stakeholders, preventing the failure of change, projects, and programs.

Dragon1 Trial Account

Are you interested in visualizing and managing your projects? Sign up today for your Trial Account.