Simplicity over Complexity

It isn’t always the complexity and the volume that give the basis for success. Most of the time it is pure simplicity which is one of the reasons why my 8th Mantra is “The simplest explanation is usually the right one”.

My first project as Project Manager was back in 1984/1985. I was supposed to Manage a project where we should create the first ever solution for a dynamic host-based message to customers about changes in loan interests. Never been done but I had an idea – and I was allowed to run the project preconditioned I used the Project Methodology that we had as a standard in the company. It was Method/1 from Arthur Andersen! It was gigantic and all the binders on the shelf covered 1,7 meter of space – just for documentation. Hallelujah for the digital solution.

So, where do you start off with a 1,7 meter of binders?
On an external training for a week – of course.

I was 24 years old and unexperienced, so it made me a better Project Manager but was it worth it? We will never know but I don’t think so.

OK, this was back in 1984/85 you say. It is not like that today.
Well, isn’t it? Are you sure?

Just a few of years ago I was a member of a Steering Committee where the corporate IT department was responsible for all Project Management in the Group, as opposed to me which is a believer of Business-driven Project Management. So, I ended up in the Steering Committee, not as Project Manager. The Project Manager had just taken over for a previous failure and the person wanted to start with Pre-Analysis using their own methodology. The Project Manager asked for 6 months, and it was accepted by the SteerCom. After 6 months the Project Manager came back and reported that only 25% of the activities in the Pre-Analysis was completed according to the methodology.

The Project Manager was history the day after. It turned out that the Project Manager was fully dependent on what the methodology said instead of what the experience and/or common sense said.

I have a principal saying that a Pre-Analysis should never take more than 3 weeks, if necessary, use a timebox. If you by that time still don’t know what to do – you won’t know it after 3 or 6 months either. We completed the Pre-Analysis as stated and delivered the rest of the project according to plan.

This is an example of gigantic project development models are still used.

I will give you a glimpse of how I use my method in the next few lines…

Development model

I don’t think this needs any further explanation. On the overall level, it follows the “normal way of doing it” but there is an expression in the illustration you often don’t see – and that is the Value chain. That expression appears in several of the sub-activities in this illustration. This is because it is a very important component of my thinking.


But before we enter the interesting delta analysis around Value chain, scoping is crucial.

I always spend time on the scoping – most of the time together with the Project owner. Some have said I appear as the Devil’s advocate when I ask all my questions, but they are crucial to ensure we deliver what is expected. If the owner of the Project and I as the responsible for implementing it don’t have the same perception of what to implement, then we will have a problem somewhere along the route to success or failure.

When scoping is set and agreed upon, I would like to use the opportunity to introduce my 3 F’s – Focus, Focus and Focus (also my 4th Mantra). This is one of the most important ingredients in the rest of the project life all the way until deployment.

And when Focus is on place, it is relatively easy to implement Change Management as well. Change Management is worth mentioning also in this glimpse of a development model because this is where most of the problems are; The Project Manager is not sufficient Focused on Change Management.

Value chain

There are several definitions of Value chain, but I tend to have a tilt towards “The detailed procedures involved in each step of its business. The purpose of a value-chain analysis is to increase production efficiency and quality so that a company can deliver maximum value for the least possible cost”.

And here my ASIS|TOBE analysis is initiated.

I claim that any Project scope consist of a minimum of one change, and any change can be reflected in the Value chain. What do I mean by that?

The scope agreed with the Project owner must include at least one change to the business. It might be an addition to what we have or something that is discontinued, or a procedure that should be executed differently – either way it is a change.

The illustration to the left is a typical Value chain.

9 different Level 1 activities (Client Management, Product Management….) and for each Level 1 activity, a set of Level 2 processes (in the illustration the sub-list).

I always start with Level 1 and identify in which activities I can foresee a need for a change to be able to implement the scope.

Normally, by running workshops where I facilitate core senior business and IT-people in a series of questions of the type: “To be able to implement <Scope>, does that mean we need to do anything in the way we today perform “Client Management”? Everything is written down – no critical questions asked, that can come later. Then on to the next and the next, all the way until all Level 1 activities are covered.

If you do this right, don’t expect the Workshop to be finished in 1-2 hours. It is a lot to go through and discuss, and not least document so spend some time on this. It is worth the hours, you will see the benefit later in the project.

When completed and all the information is structured, you have a High-Level Value chain impact description.

On a high level, you now have a list of impacts towards customers, systems, infrastructure, vendors, OI, controls, and artefacts. I am sure you begin to see the extent of the project.

When categorizing the identified changes is completed, I am sure you will find a need for a 2nd review. This is perfect and just as it should be.

On a high level, you now have a list of impacts towards customers, systems, infrastructure, vendors, OI, controls, and artefacts. I am sure you begin to see the extent of the project.

Some categories you are unfamiliar with? I will say a few words about two of them, the rest I presume are self-explanatory.

OI is an abbreviation for Organizational Implementation and cover resources, competence, organization, training etc. In short, any impact on the organization itself.
Artefacts is a category covering statements, letters, logos, reports etc. In short, any impact on produced elements – primarily towards customers and/or stakeholders.

If you look carefully at both the illustrations at the same time, you will now see a matrix with Level 1 activities along one axis and Categories along the other axis. I always use this as a starting point for how to organize the project. It is a good help and often close the final result when organizing.

Next, is the Static Test.
Not familiar with the word? I wasn’t either until 2008 (or so) and I found it to be a very useful and powerful tool to use.

Static Testing is a technique which is used to check defects in your analysis result at as an early point of time as possible. Static testing is done to avoid defects at an as early stage of the development as it is easier to identify the errors and then solve them. One person (often the one I plan to use as responsible for a category or Level 1 activity) presents their result and a subset of stakeholders give feedback on the presentation. The goal is to ensure the project is on the right track compared to what is expected.

So, what do we now have?
We have an agreed scope, we have an agreed high-level description, we have a pretty good and agreed idea on what parts of the business is being impacted by the scope and we should be able to give a first draft of Project plan and Project risk map.

I will not cover these areas since they are standard independent of what development model you are using.

Instead, it is time for Level 2 analysis. In principle, the same that was done on Level 1 but now in more detail and on Level 2. Normally, that will take too much calendar time if everyone should participate in all Level 2 workshops so I recommend a delegation to someone that can be responsible for a Level 1 activity to perform this analysis in separate workshops. This way you can run all these Level 2 workshops in parallel and save time. Still, important to use the same questions and the same categories and documentation. Afterwards, each Level 1 group invite all the other Level 1 groups to a Static Test where their own Level 2 results are presented.

By doing the latter, you ensure the holistic view on the solutions and not least the horizontal. What could look good from one Level 1 point of view might be a complete disaster for another Level 1 group.

The project will iterate in these ASIS|TOBE workshops and static tests until completed and when done, you know exactly what to do. Each of the delta’s is an activity in your Project Plan and a test case in your Test Plan. Very useful, and secure consistency, completeness, and audit trail.

Follow this model and always keep your 3 Fs in mind and your probability for success is high. But I will mention one last area that can give you a failure – and that is…

Project Governance

Boring, many says but this is not boring. Especially not when it goes wrong, or you/people around don’t act according to it. That is why it is imminent to have that in place early in the project.

Governance structure refers to the framework of project management, especially regarding rules, procedures, roles, and the division of responsibilities within the whole decision-making process. It keeps the project in check, allowing it to run flawlessly and in accordance with the plan.

If you make sure both yourself as well as the SteerCom (Program Board, if needed is normally above the SteerCom) and other stakeholders are compliant with an agreed Project Governance Framework, that is a good starting point for your project.


I will give you 2 more illustrations that can come handy during your project. That is the Dashboard which I always use to give a snapshot on one page, to SteerCom, Program Board, Management Teams, Board of Directors etc.

Very useful even for yourself as Project Manager to compile the whole project into a one-pager.

The last illustration is a standard Risk Map which is crucial to update when necessary but at least once per month. Using this version of a Risk Map has never ended up in misunderstandings which is important when discussing Risk and Risk Map.

I started this post by telling you about the 1,7 shelf meters of binders to document the first Project Methodology I used. Without any other comparison, this description has been made in just 5 pages and the methodology is working every time both for myself and for others using it.

I would recommend some coaching the first projects but that is nothing compared to the alternative. If you like what you have read and would like to know more or would like some coaching, please contact me/us using this link.

Anyway, I wish you the best of luck with your projects.

Leave a Comment