Information objects of a change initiative

The clusters of knowledge involved in delivering successful projects

My curiosity lead me to participate in a certain workstream focused on improving the usability of information modelling methods available to its practitioners. In particular, making the information modelling a tool for “business people” (for the lack of a better term) rather than a tool for technical geeks in the organisation.

As a part of this, I was presented with an interesting thought exercise. Let’s assume the knowledge that any business generates about itself can be conceptually split into the following categories. I am not trying to challenge or re-define the categories here; let us use them as a given constraint to shape the thinking.

1. Context and long-term objectives: knowledge about the industry the business operates in and the long term goals of the business within this context. It covers matters of competition, mission, vision, etc.

2. Strategies and goals: knowledge of what the business is trying to achieve and why. This category addresses the aspects of strategic goals, objectives, and strategic decisions based on the ways to achieve those goals (strategies).

3. Operational execution: knowledge about how the business is run. In particular, things such as current state customer experience, business processes, business rules, operating guidelines, etc.

4. Future state operating model design and change portfolio: knowledge about the expected or desired future state for the business, covering the to-be experiences, processes, systems, and their priority.

5. Change definition, design, and delivery: knowledge about each individual change initiative that allows you to get closer to the future state operating model.

5 levels of information that exist in the business (arguably any business). Today, we will be focusing on the last level — Change definitions, design, and delivery.

Now, the question is: “What is the minimum amount of information objects needed to be generated on each level to support the business”?

Information objects for change definition, design, and delivery

As a part of today’s exercise, let’s put together a list of information objects important for modelling on level 5 of this framework. When I say important for modelling, what I mean is that they bear some meaningful purpose and can be considered universal enough to be applied across the different types of businesses and projects. I also mean that they, when missed, will cause trouble.

I will use the same definition for the term “information” here as in my previous article on information architecture [1]:

Information is any collection of data that is processed, analysed, interpreted, organised, classified or communicated in order to serve a useful purpose, present facts or represent knowledge in any medium or form.

Let’s have a look at an individual project.

Goals cluster

When you have a project to deliver in your hands, what becomes important to know?

According to PMI’s Lexicon[2], a project is a “temporary endeavor undertaken to create a unique product, service, or result.”

The key aspects of this definition that makes projects different from, say, business processes or departments, are “temporary” and “unique”. A project is initiated for a particular reason, and this reason, when no longer relevant, will indicate that the project should be over. Let’s call this a goal, and it will form the first cluster of important information objects.

Goals cluster

The goal itself may be complex in nature, so even to come up with it and make it understood by people involved, may be a tricky business. Often goals need to be broken down and explained in more detail. Typically, a goal will be decomposed into objectives, each one underpinned by a set of measurable criteria or signals that let one decide whether a goal has been achieved or not.

Interested parties cluster

Arguably, a project will only ever be initiated if its goal is of benefit to someone within or outside of the business. This introduces the concept of value, that will bridge the first cluster with another one. Value is something generated by the project (or rather, a project’s outputs) and is perceived as such by the stakeholders. To a sense, value is always subjective as it cannot be separated from the beneficiaries receiving it. But the beneficiaries are not the only group of parties having interest in the project. The interested parties will form the second cluster of objects — we need to know who is involved in, or otherwise affected by, the project to deliver it successfully.

Analysing the stakeholders is always a separate activity. I personally like to start with an onion diagram framework to map the different types of people involved. It looks at the organisation in the terms of how close the people are to the center of the change, layering them like the rings of an onion.

1. The first layer: immediate project team. These are the people involved into the delivery of the project, which is their main job.

2. The second layer: people affected by the change. These are the people whose daily routines will be affected by the change. It includes end users, customers, etc. — all the people directly affected by the solution.

3. The third layer: people involved in the change. These are the people whose main job is not about delivering the given project. They are also not the people directly affected by the new solution, but they may have an interest in it (i.e. they rely on the information generated by the solution) or they expect others to benefit from it which will indirectly affect them (e.g. subject matter experts, sponsors, etc.)

4. The fourth layer: external environment. People not affected by the change per se, but having an influence on the context of the change (e.g. legal regulators, suppliers, etc.)

Interested parties cluster

Knowledge about the interested parties allows us to better understand who is involved in the change initiative, what their involvement is, and what they are expecting. Knowing that, the team can gain better understanding of the problems they are trying to solve and can more effectively design the solutions, which form the next cluster of information.

Solution cluster

Before a solution can be built, it needs to be somehow scoped and designed. For the sake of this exercise let’s ignore the specifics of an implementation methodology (e.g. predictive design upfront projects vs. adaptive agile projects). In both cases, the act of design happens prior to the implementation of the chosen design, although in different timeframes.

As described in my other article [3], I love the definition of design as:

“an ability to create feasible wholes from infeasible parts”

In order to do so, one needs to understand the goal of this activity (derived from the project goal discussed above), the expected function of the solution, available or expected parts available, and the known constraints.

The expected functions will form the functional scope of the solution — which capabilities the solution is going to bring to different stakeholders. The parts, or the components, will dictate the internal architecture of the solution. These can be broken down further to different types of solution components. On a high level, we can distinguish the business or organisational components (business processes, business rules, new org. or legal structure, etc.), real-world components (physical objects that form the solution, e.g. desk space, store rooms, hardware and networks), and digital components (software). Understanding these components will help understand the scope of the solution within known constraints.

Solution cluster

When there is an element of the solution that needs to be delivered, there is always some effort involved to do it. In project management terms this is the transition from product breakdown structure (the elements of the solution) to work breakdown structure (the activities needed to deliver the solution). Understanding these activities and effort involved together with the elements, a project manager can properly build a resource plan, calendar plan and budget for the initiative.

Delivery cluster

So far, we’ve been talking about the information elements related to the target solution. However, it is impossible to deliver a project without managing the information about the state of the project itself — I will call it a delivery cluster.

First of all, any project manager is associated with the constraints. What originally was defined as a triangle of project management (cost, scope, and time) has been rethought a few times since then. So today we have Schedule, Resources, Budget, Quality, Scope, and Risks [3].

Delivery cluster

We have already discussed scope in more detail but haven’t talked about the rest, all of which seem valid candidates to be included in our information objects.

With time, as the project evolves, the team is faced with changes, so they have to make decisions around what to do with them. I would argue decisions are another piece of information worth managing as a part of an individual project.

Next steps

So far, we’ve got this model of information objects relevant to level 5 of the proposed framework — Change definition, design, and delivery.

The first draft of the model on delivery level. These concepts form the key information objects of value for the team to deliver a change successfully.

It is the first attempt at putting these things together, and it will go through a few rounds of discussions and review until reaching some final form. This Medium article is supposed to become the forum for distribution and collecting the feedback for this and future thought pieces.

The same will happen for all the levels of the framework, before the final model will be proposed by the same group who started it.

In the next write up, we will look at level 4 of the framework — Future state operating model design and change portfolio. Till then, I’d be glad to hear your feedback — what is missing from the framework and model? Which important information objects need to be considered in addition to the ones outlined above?

References

1. Information, content, and data architectures https://medium.com/analysts-corner/information-content-and-data-architectures-bb5c6ccafdb7

2. PMBoK Lexicon, https://www.pmi.org/pmbok-guide-standards/lexicon

3. Systems thinking in analyst’s toolset https://medium.com/analysts-corner/systems-thinking-in-analysts-toolset-54265edd0486

4. PMBoK, https://www.pmi.org/pmbok-guide-standards