Managing 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 amongst people to create interactive visualizations together with the team and have them used by stakeholders to manage change.

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 a First Principle?
  • What is Current State and Future State (AS-IS and TO-BE)?
  • How to use Interactive Visualizations managing Projects?

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.

project map

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

What is Change?

introduction drones
The introduction of the smartphone still has huge impact of change in all of our business processes and IT systems.

Change is something we all come across. Every day the organizations we work in or we work for are different from the day before. This 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 changed many things, like the way we solve cases in crime. All stories in movies now are different because of the possibilities of the smartphone.

In organizations many changes (or transition or transformation) we want to manage, 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, 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 cause disruption of services to customers, which could cause fines, penalties or even lawsuits.

introduction drones
Drones will cause more change and impact than we can imagine right now in 2021.

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 with introducing digital products and services because they don't know how it will impact their real-world products and services. Think here: Microsoft with MS Office Desktop software versus the Amazon AWS and Google Cloud with MS Office 365.

Managing Projects prevents project failure

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

major causes project failure
Major Causes of Project Failure.

Managing transformation, transition or change is what puzzles a director and a manager. How to do it? How to deal with risks, budgets, showstopper? How to keep the stakeholders calm? How to have 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 changes, but also the workplace and workforce. In our organizations today, often four different generations are present that bring along four different types of culture and these four different generations vary from presence 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 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 if you do not apply Enterprise Architecture properly, it won't act as a bridge.

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

Strategy, Architecture, Transformation, Projects

dragon1 enterprise performance framework

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 as total enterprise concept for an enterprise structure.

With these three definitions you can actually 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 the grand design.

Managing Projects without Enterprise Architecture

projects do not fit together
Too often deliverables from different projects don't fit together.

As strategy and transformation are done and taking place 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 projects is impossible and the results of the project do not amplify each other, but rather 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 seen as 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 & Consultancy (a.k.a mainstream Enterprise Architecture).

Mainstream Enterprise Architecture has an IT focus. People, in this case, 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, provide advice to 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 board room.

A fundamental change for instance implementing standards enterprise-wide in organizations without the support of CxOs and enough budgets in 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. And you end up as an architect trying to explain what is architecture 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 fundamentally change business models, move supporting walls, shorten time to market for products or really transform the organization enterprise-wide into a digital company. Because there is also something called Human, Culture, Money and Raison d'etre (the existential reason of the company). And they are miles away from IT, but they're part of real Enterprise Architecture.

Mainstream EA produces hideous diagrams that are never used to supporting decision-making by managers. Everybody knows the process and application landscape created, for instance using the ArchiMate model notation, that only the architect understands. These models may be necessary at one point for some suppliers or engineers, but they can never be the most important diagram to create 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 act as a bridge between strategy and transformation. There are various domains with total concepts can be designed: business architecture, solution architecture, etc... A diagram that shows for which domains 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 has asked for it. Because: who is going to approve the requirement, the design and pay for the realization of it? (Know that design is another word for building plan).

For an architect the CxO is the natural owner/client. A CxO is accountable and responsible for certain parts so of the organization and has the power and privileges to change these parts. Create a portfolio of visualization 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. You, as an architect, are the moderator of creating a Program of Requirement per strategy, organization, solution or project. And in this PoR you write down mission, vision, stakeholders, strategic starting points, needs and requirements and all kinds of other things. And if you have your PoR ready and validated by the owner/client and stakeholders, you are creating to create a total concept.

Total Concepts

A total concept consists of concepts. And 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 products 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 create small and smart business cases for the owner/client and stakeholders so they approve of 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. Also, Dragon1 defines that the architect creates a stakeholder onion diagram and collects requirements from the stakeholders, using Use Case Diagrams and 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 out 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 out of elements (at logical level) and out of components (at the physical level) and out of technical products (at the implementational level of abstraction).

As an architect, you are on the search for elements and components that are present and/or are missing in the organization. With that, you as an architect can analyze what percentage of that concept is already available (% applied) in the organization and how mature (m=?) it is. In Dragon1 where 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 create first an overview of the current organization at the four levels of abstraction (per domain or as a whole). And you can differ between generic overviews, medium overviews and detailed overviews. Next project or re-engineer the concepts and the principles by looking at the elements, components and technical products. As an architect, you definitely 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 the Interactive Visualizations

Although it is mentioned before, here we repeat the core activities of managing change 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 that 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 now need to promote that stakeholders use the visualizations in discussions, meetings, presentations. And if something is not correct let them comment on the visualizations. Also, try to get the visualization approved and have official status. In that way, you will trigger usage of the visualization almost automatically.

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

Architecting Solutions:

DEMO: Concept Mapping Software

How to use Dragon1 EA Tool

Learn to generate architecture diagrams using repositories
DEMO: Enterprise Architecture Blueprint Template

DEMO: Generate an Enterprise Architecture Blueprint to discover and solve RISK

Banking, Logistics, Healthcare
DEMO: Data Mapping Software

DEMO: Generate Application Landscape for SECURITY

Automotive, Financial Services, Health Care
DEMO: Strategy Mapping Software

DEMO: Generate Strategy Map for CLOUD ADOPTION

Government, Logistics, Banking
DEMO: Process Application Map

DEMO: Generate Landscape for RPA AUTOMATION

Retail, Agriculture, Oil & Gas