Review Project Excellence Baseline

A few weeks ago, I was for a three-day assessment training regarding the IPMA Project Excellence Model in Vilnius, Lithonia. For 3 days, by using action learning we familiarized ourselves with the Project Excellence Model. This model will be used to judge which large and mega-sized projects will receive the project excellence award.

IPMA_PEB_2019__cover_previewThe Project Excellence Model (PEM) is described in the book Project Excellence Baseline for Achieving Excellence in Projects and Programmes. This Project Excellence Model is a great tool for continuous improvement of project or program management in your organization? It’s not a maturity model. The main purpose of the Project Excellence Baseline (PEB) is to describe the concept of excellence in managing projects and programs. It complements the IPMA Individual Competence Baseline (IPMA ICB) and the IPMA Organisational Competence Baseline (IPMA OCB).

The book describes a project in its organization’s internal and external context. The concept of project excellence is based on continuous improvement (plan-do-check-act), the role of sustainability and the role of leadership.

The PEM model structure enables easy reporting of the outcomes on all management levels via three levels:

  • Areas: The main components of the model: People & Purpose and Processes & Resources and Project Results
  • Criteria: to enable detailed feedback about the levels of excellence on a particular project
  • Examples: actual practices typically found in excellent projects.

QRC (PEM, 200324)All three areas of the model strongly interact with each other. See the arrows in the figure. This means that none of the areas should be developed in isolation and each of the areas should be actively used to develop excellence in the remaining two. Due to interaction between areas the following business value can be secured: performance, effectiveness and efficiency, reliability, flexibility, continuous improvement, scalability and sustainability.

The People & Purpose area is divided into three criteria: A.1. Leadership & Values; A.2. Objectives & Strategy; A.3. Project Team, Partners & Suppliers.

The Processes & Resources area is divided into two criteria: B.1. Project Management Processes & Resources; B.2. Management of Other Key Processes & Resources.

The Project Results area is divided into four criteria: C.1. Customer Satisfaction; C.2. Project Team Satisfaction; C.3. Other Stakeholder Satisfaction; C.4. Project Results and Impact on Environment.

In a separate chapter the assessment of project excellence, the assessment process itself, the role and competences of project excellence assessors, the scoring approach and the project profile are described in detail. The project profile consists of three general scores, respectively for People & Purpose, Processes & Resources and Project Results. Examples of conclusions after assessing could be leadership driven projects with low process maturity, process driven project with low leadership and/or sense of purpose and, balanced projects combining great leadership and a strong sense of purpose with a strong process culture.

In the annexes you get a very detailed description of the Project Excellence Model and the scoring tables for the model areas and criteria. The last annex explains the IPMA Global Project Excellence Award assessment and its benefits for stakeholders, applicants and for finalists and winners.

Conclusion: Not only a book for assessors or applicants of the IPMA Project Excellence award but for project sponsors, project or program managers or PMO/Centre of Excellence staff too who can use it as a great tool for continuous improvement of project or program management.

To download: Project Excellence Baseline

Introduction to the Project Excellence Baseline

AGILE NXT 3rd edition

AgileNXT_Magazine_3In this third edition of AGILE NXT — a magazine designed by Xebia’s thought leaders and experts to inspire and inform you, offers 15 new insights:

  • The Ultimate Model for Managing Performance in Agile Environments (Daniel Burm). The Agile performance management model consists of five main building blocks: purpose, strategy and goals, whole system alignment, performance models and metrics, coordinated performance management routines and high-performance culture and behavior.
  • Schiphol’s Customer Value Takes Flight With A New Mindset (Esmé Valk and Ellen Barree). The program is all about changing mindsets and behaviors bottom up, without having a structural blueprint thought out in advance.
  • Stop Focusing on Agile & Start Adding Real Value (Kevin Bakker). In many organizations, Agile and Scrum have become container concepts—their true definition and purpose forgotten. So, it makes sense to regularly reflect with your whole team on the what and ways of working Agile. As an organization, keep asking, “what problem do we want to solve?” Does your approach add the most value, or are there other options?
  • Need Business Agility? Boost Your IT Capabilities (Bart Bouwers). 5 capabilities are explored: Build the Right Product, Continuous Delivery & Release on Demand, Detect & Recover Fast, Easy Infra & Containers, and Always Compliant & Always Secure.
  • Change the Way You Change – A result-Driven Growth Hack (Ron Meyer and Paul Immerzeel). Based on an agile transformation that is not yet showing results, the sponsor asks himself the following questions: What do I sense?, What do I feel?, What do I think?, What do I want?, and, What can I do about it?
  • Agile Doesn’t Create Future-Proof Organizations (Riët Broekhuizen and Ellen Barree). The 4th revolution requires radical innovation, where organizations experiment with new revenue models and structures, automate all repetitive actions, eliminate bureaucratic processes and employ the latest technologies in an open and transparent environment.
  • Digital Business: Make it Happen, and Make it Stick! Digital Success Requires a Healthy Dose of Common Sense (Edwin Oldenbeuving). There are seven skills for life and work in the 21st century: cooperation, communication, problem solving, self-reliance, creativity, critical thinking and social and cultural skills.
  • Portfolio Management – Through Different Glasses (Jarl Meijer). Five Tips to Reduce Portfolio Management Complexity are discussed: Nurture a culture of trust and transparency; Scale down to independent units of max. 125 people; Provide clear company-wide goals and priorities; Focus portfolio management sessions on strategic choices and solutions for impediments; Drive performance growth and predictability.
  • Cloud Migration Will Disrupt Ops as You Know It (Mark van Holsteijn). Three strategies for cloud migration and their effect on IT Operations are explained: rehost, redesign and re-platform.
  • Artificial Intelligence for Leadership decision-making (Rik de Groot). AI supports decision-making by: Analyzing the situation based on data, trends, historical information, and information from outside the organization; Giving leaders insights and options; Providing fact-based information; Looking at the big picture instead of local optimization.
  • You Can’t Escape Team Behavior (Anne Davidse and Marianne Pot). The escape room creates a bubble within which you can better understand team behavior. By analyzing how individuals’ function in a high-pressure team challenge, you can identify opportunities for improvement, spot natural leaders, and build trust.
  • Deep Democracy: Listening to the Wisdom of the Minority (Kenny Baas-Schwegler). Checking in, spreading perceptions (listen to all options, share other options and different viewpoints, and raise hands for recognition), deep democratic voting (majority vote is needed, sincere apology to those members who aren’t part of the majority, collect their arguments and vote again and repeat cycle if there is no full consensus), go fishing (make explicit agreements with each other, everyone says what they have to say), equality in differences (vote again).
  • Scoring an “A” for Agile in Architecture (Winfried Scheulderman). An overview of characteristics of a modern IT architecture process and six considerations to take into account if you want to introduce modern architecture.
  • The Agility Gap: What’s Really Behind It? (Daria Nozhkina). When an organization primarily focuses on its financial priorities, it directly impacts its approach to Agile transformation, which, in turn, influences the transformation’s success.
  • Common Sense Scaling: The 10 Do’s and Don’ts for Delivering Value with Multiple Teams (Evelien Acun-Roos). Start small, involve, change habits and behavior, measure and seek knowledge and experience.

Conclusion: a mix of articles. Some articles are too short to make a difference. Other articles definitely offer new insights. In total it’s definitely worthwhile to download and read the magazine.

To download:


Scaling agile in organisaties

9789401806213-480x600Ondertussen is de tweede geheel herziene druk van mijn boek Scaling agile in organisaties verschenen. Sprak ik in de eerste druk over ruim 30 agile frameworks of aanpakken, in deze druk passeren 70 agile frameworks of aanpakken de revue. Het boek beval de meest recente versie van mijn bird’s eye view on thew agile forest en neem ik de lezers mee wat het betekent voor organisaties als ze doorgroeien van een enkel permanent agile team naar vele agile teams. Daarbij ga ik ook in op de vraag wat dit betekent voor de rol van projectmanager, PMO en portfoliobureau. Uiteraard zijn de hoofdstukken die gewijd zijn aan SAFe (nu versie 5.0), LeSS, Nexus, Scrum @ Scale, spotify, AgilePM en PRINCE2 Agile gebleven. Er zijn echter nieuwe hoofdstukken bijgekomen met daarin uitgebreide beschrijvingen van Disciplined Agile (ondertussen overgenomen door PMI), AgileSHIFT en bimodal portfoliomanagement. Daarnaast van vele agile aanpakken korte beschrijvingen. Ten opzichte van de eerste druk komen er nu verschillende frameworks aan bod die helpen bij het creëren van een agile cultuur of mindset zoals AgileSHIFT, Open Space Agility en Agile Fluency. Ik wens jullie veel leesplezier en mocht de behoefte er zijn dan ben ik gaarne bereid om in een sessie van een uur of langer uitgebreid in te gaan op de inhoud van het boek en jullie een overzicht te geven wat er zoal speelt in het agile landschap.

Bestellen: Scaling agile in organisaties

Are incremental and iterative the same phenomenon or not? (part 2)

webinarIn the first part of this article (see previous post) I compared a waterfall and an agile approach when creating a payment app. In this second part of the article, I position waterfall and agile in an incremental versus iterative matrix and shows what happens in the other two quadrants too. As a last step I elaborate on the minimum viable product (MVP) and the minimum marketable product (MMP) and shows where these fit in the different approaches and a story map. At the end you will find the corresponding mini webinar.

As stated, I noticed that students often mix the words iterative and incremental together. In figure 4 you can find four quadrants as a result of a horizontal line presenting incremental or not and a crossing vertical line representing iterative or not[1].

In the left lower corner, we see the approach where there are no iterations and no increments. This is the waterfall approach. All activities (design, analysis, build, test and deploy) are performed once for the entire project. In this case we see a single delivery of the final product based on a fixed scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is to manage cost. See also the waterfall approach to develop the payment app in the first part of the article.

In the lower right quadrant, we see an incremental approach without iterations. This is a staged or incremental delivery of smaller parts the product. All activities for a given stage (design, analysis, build, test and deploy) are performed once. Within a given stage the scope is fixed, but the total product is based on a more dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is speed of delivery.

Dia8Figure 4: Iterative versus incremental

In the left upper quadrant, we see a spiral or iterative approach without increments. This is a single delivery where the final product is created by using several iterations. A good example of this approach is design thinking. In the graph you see a sequence of the activities framing, analysis, idea generation, realization and reflection. This sequence will be performed repeatedly or iteratively where in every iteration you get closer to the final, correct or required, product. In many cases this final product is a prototype or model. In this spiral approach we have a dynamic or flexible scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is the correctness of the solution.

In the upper right quadrant, we see the agile approach with increments and iterations. Scrum is a good example[2] of this approach. At the end of each increment, often called a sprint or timebox there is a delivery of an increment of the product. This increment is the result of many iterations to develop small but correct parts, often called user stories or backlog items, of the product. The final product will be delivered piece by piece. In this agile approach we have a dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is customer value via frequent deliveries and customer feedback. See also the agile approach to develop the payment app in the first part of the article.


In figure 4 you can also find the acronyms MVP and MMP. MVP stands for minimum viable product (Eric Ries, Lean Startup) and is a version of a new product or service which

allows a team to collect the maximum amount of validated learning about customers with the least effort. The MVP for the Dropbox service was a simple movie. This means that the P in MVP could be a completely different product in comparison with the final product.

I often use the following example of a new financial product. An enthusiastic sales manager has a great idea regarding a new financial product. He thinks that they can sell at least 100.000 of these products. Together with some finance experts, they design the product in a couple of months. A development team is assigned, and it takes them 4 months to develop the product. In parallel commercial brochures are developed and the product is launched with a big event. Unfortunately, just a few people buy the product. If we follow Eric Ries’ approach we could make the assumption that 10% of their web users are interested in this product. To test this hypothesis, they develop a MVP. In this case a simple button on the homepage. If you click you get a screen with a message regarding this new product and the question to leave your mail address behind if you are interested. Less than 1% of the visitors pressed the button. The product will not be developed. They saved a lot of scarce resources.

If we take a closer look at figure 4, we see the potential usage of MVP’s in all quadrants. When using a waterfall approach, you could create a MVP in the first design phase to check if there is a business justification for the project. The same can be done in the first phase of the first increment when following a staged delivery. In some cases, the result of your spiral, or design thinking approach could be a MVP. At the beginning of an agile approach the MVP could be beneficial too.

Many people see the first product delivered at the end of your staged delivery as the MVP. This could be the case but, in most cases, this is not a MVP but a MMP. MMP or minimum marketable product is the smallest product that can bring value to your customer. See the staged delivery or agile approach where a MMP could be deployed.

How does an agile delivery looks like?

Now it is clear that incremental and iterative are not the same and we understand the usage of MVP and MMP, we can explore in more detail how an incremental and iterative delivery could look like. You probably have seen Jeff Patton’s famous example of the Mona Lisa where the painting is created piece by piece (staged delivery) or in the first increment only a rough sketch and every new iteration more details are added to the sketch and ultimately you have the final painting (incremental and iterative or agile delivery). In the first situation you must already have a detailed idea of the final product and in the second situation you just need a high-level outline and changes are much easier to make. If we look at figure 5, we see a story map for a new product called ABC.

Dia9Figure 5: Story map for product ABC

The product owner envisioned seven features for this product. The first four features are must haves. Feature 5 and 6 are should haves and the last feature is a could have. Many would call this MoSCoW prioritization (Must haves, Should haves, Could haves and Won’t haves). Every feature in itself can be sliced down in smaller parts. In the figure you see features with must, should and could have user stories. A feature can be a must have but that doesn’t mean that all the underlying user stories are must haves too. Or a feature can be a should have but if you implement that feature some user stories are must haves and others are should or could haves.

To implement this ABC product, you see five increments or releases. The first one is the minimum marketable product. This MMP consists of the first two must have user stories of feature 1, and the first must have user stories of feature 2 and 3. Release 2 contains the next two must have user stories of feature 1, 2 and 3 (iterative development). Product development continues by implementing the next releases. With every release the customer value increases. After release 5 the product owner stops implementing user stories. Feedback from the customer showed him that the ABC product is ‘fit for purpose’ and he takes the Agile manifesto’s principle Simplicity – the art of maximizing the amount of work notdone – is essential, into account and stops further development.

Mini webinar Incremental versus iterative

[1] See YouTube for a very simple version of this figure:

[2] See my article with more than 70 agile frameworks or approaches: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.


White paper: Exploring the delta in AgileSHIFT

Schermafdruk 2020-03-18 10.29.34Happy to see that my white paper Exploring the delta in AgileSHIFT is now live on the AXELOS content hub.

Enterprise agility is key. It is not just about implementing an agile way of working in your IT department but a transformation for your whole organization. You have to understand where the market is going, where your competitors are moving, where your customers want to be, and, as a result, where your organization needs to be. One technique to understand this is the concept of the delta. The difference between where the organization wants to be, expressed as ‘what great looks like’, and where it currently is.

This paper explores the concept of the delta, explaining how this is addressed in AgileSHIFT®, and providing practical recommendations and examples on the subject. It is aimed at senior managers, portfolio officers and transition directors who are overseeing fast-moving environments and are running the risk of competitors or disruptors taking over their organization’s market share.

AgileSHIFT helps prepare individuals and organizations for transformational shift by creating a culture of enterprise agility. This cultural change is not driven by simply adopting an agile framework, method or tool, but by understanding and distilling the ethos behind agile ways of working and leveraging them across the entire organization.

A key theme within AgileSHIFT is the delta and the importance to narrow your company’s delta. The delta is the difference between where an organization wants to be and where it currently is. This could be measured in terms of capability, performance, or value delivered. The larger the delta, the greater the vulnerability of the organization to competitors and disruptors. Unfortunately, the delta is not static, so it will grow again. Narrowing the delta will be an ongoing process and you must keep changing to manage the delta, otherwise competitors will be ahead of you and take it all.

In the article I explore what it means where you want to be. This is what you could call ‘great’ and this could relate to your products, services, technology, processes et cetera. I explain that this could be related to the technology. Can you expect a (digital) tech-shift in your company’s work (tech-supported, tech-enabled or tech-centric)? If the delta is large your company is at risk and vulnerable to other competitors who could destroy your own business. What would be the impact of disruptors or exponential organizations on your own business? Will you survive?

I make use of some scenario’s like a dentist practice and a Cyclecity bike shop to explain the concept of the delta and how you could narrow the delta by closing the existing gap. For the Cyclecity bike shop I use a business model canvas to explain the as-is and the to-be situations. I use the GDS/IPS’s 7 lenses of transformation (vision, design, plan, transformational leadership, collaboration, accountability and people) to give a first, but incomplete, impression of how the transformation programme to bridge the gap between the as-is and the to-be could be outlined.

I hope this white paper will be useful and feel free to give me your comments.

To download: AgileSHIFT_wp_Exploring-the-delta-in-AgileSHIFT

Are incremental and iterative the same phenomenon or not? (Part I)

webinarDuring training classes I often notice that students mix these words together. After reading this article I hope you understand the relationship between incremental and iterative development. I will start with a comparison of a waterfall and an agile approach by delivering a payment app. At the end you will find the corresponding mini webinar. In the second part of this article, I position waterfall and agile in an incremental versus iterative cross or matrix and shows what happens in the other two quadrants too (will be part of a next blog post).

The development of a payment app

Waterfall approach

If this app is developed according to a traditional waterfall approach, the following steps could be observed (see figure 1).

It all started with a project sponsor from the marketing department who was able to free up the necessary funds for this app. It was his assumption that the app will improve the retention figures and the inflow of new clients will grow. He visualized three high level function groups.

At a certain moment this project gets the approval to commence. A project manager is assigned, and a project team built. After many discussions and requirement gathering workshops there was an agreement to deliver a payment app with 250 features. All these features are recorded in an extensive and very detailed requirements document and signed by the project sponsor and customer representative (and some others).

In the next step the project team translates the requirements into a design for the app. The architect checks the design towards the design principles. He checks if all needed data attributes are available in the backend system too.

Dia3Figure 1: waterfall delivery of an app

We are now two months underway and the customer hasn’t seen anything working yet, only some progress reports. Probably some sort of ‘melon’ reporting[1] so they have no clue if the project is on track or not. It takes six months to develop the app and when that’s done the customer representative is asked to deliver some people who can help with a user acceptance test. During the test it becomes clear that several features are not working. The project team doesn’t understand why. It’s exactly what was described in the requirements document. Lots of discussions, rework, delays and customers who aren’t happy with the results. If we look at the final result, we can also notice that many of the developed requirements are not or rarely used[2] by the customer. It could even be worse. Suppose the development of the app took 1.5 year and another bank delivers a payment app when you are halfway. What would you do at that moment? Would you still have a viable business case to continue and finish your own app?

If you look at figure 1 it becomes clear that in case of a waterfall approach the scope and underlying quality criteria are fixed with a single delivery. All steps are performed once for the entire project and management control is focusing on cost and time. Value delivery to the customer only takes place after the deployment of the complete app.

Agile approach

If we develop the app in an agile way, we see the following pattern. The development team stated that they are able to deliver the first two features prioritized by the product owner (balance information and submit feedback) in the first iteration. The project team delivers every three weeks (sprint, iteration or timebox) an increment of the product. After the first deliveries or increments we see a customer who has confidence that the project will deliver. He/she already has a working app. He understands that not all features are there yet but what he has is working. Looking at the latest release and the provided features, he mentions a completely new feature. One that nobody had on his mind at the start of the project but a feature that can make his life as a customer much more productive. After every increment the customer feedback results in new features (not on the list) or adjustments of potential features and the product becomes more and more mature. Every time when the customer receives a new version you can see a happier customer.

Dia4Figure 2: Agile delivery of an app

If we look at figure 2, we see a steady flow of delivery within a fixed duration and using permanent agile teams (fixed costs). The scope and underlying quality criteria are flexible (dynamic) with frequent small deliveries (increments). All steps are performed repeatedly (iterative) to deliver a feature or user story until the required quality is reached. Management control is focusing on customer value delivery. Value delivery to the customer takes place after every deployment of an increment of the app.

Waterfall versus agile delivery results

If we take a closer look at the two products from both the waterfall as well as the agile approach, we see a product with 250 features and a not so happy customer and one with only 150 features and a very happy customer (see figure 3).

Dia5Figure 3: Waterfall versus agile delivery results

And if we even look in more details to the product delivered by the agile approach, we only see 100 features from the original list and 50 are new or adjusted features. This is in line with some important principles of the agile manifesto[3]:Simplicity – the art of maximizing the amount of work not done – is essential (only 150 features instead of 250 features) and Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage (50 new or adjusted features were delivered). And as a result, a very happy customer (Our highest priority is to satisfy the customer through early and continuous delivery of valuable software)!

Mini webinar Waterfall versus agile delivery

[1] ‘Melon’ or better ‘watermelon’ reporting is a progress report with green indicator(s). In reality the green indicator is red inside.

[2] Standish Group research shows that 60% of the developed requirements are not or rarely used (


Review Formula X

9781950367221-480x600Jurriaan Kamer and Rini van Solingen are the authors of Formula X – How to reach extreme acceleration in your organization? It’s a business fable that shows which steps you should take to drastically accelerate the time-to-market in your own organization.

In this novel, we follow Ronald Verhulst, the director of a major kitchen manufacturer who is confronted with an advertisement, placed by the major shareholder promising that kitchens can be operational within two weeks from order. If it takes longer, you get the kitchen for free. This sounds disruptive if you know that the current time-to-market is twelve or more weeks. Based on a number of advices from a Formula I team, Ronald shows how to translate these lessons learned into his own organization and to implement them step by step. Do you have any idea how often a Formula I team evaluates the way they operate and how many improvements are being made between two races?

But before Ronald actually gets to work on this advice, he started to work with the Full Control Consulting Group. They helped Ronald to implement Total Efficiency Management with which measurable processes can be accelerated. Completely in line with his own adage “Trust is good, but control is better!” This approach didn’t work, but it took some time to gain that insight. He sends the Consulting Group away and started with the lessons learned from the Formula I team.

QRC (Formula X, 200313) v1.0To Download: QRC (Formula X, 200313) v1.0

From the conversation with the driver and the team boss of the Formula I team, Ronald manages to distil six lessons (the authors call this the FASTER model consisting of six parts, the initial letters together form the word “FASTER”):

  • Focus and clarity – a clear and inspiring goal that works as a compass
  • Accelerate decisions – reversible decisions and distributed authority
  • Simplify – the art of omission and simplification
  • Team Engagement – intrinsic motivation, autonomy and ownership
  • Elementary physics – the age-old basic laws for speed and acceleration
  • Rhythmic learning– learn through a cadence of recurring interaction moments

In the book we get the translation of all these lessons to the kitchen manufacturer and we see the effect but also the struggle to win the organization for taking these steps. In the beginning we see a silo organization in which every department in itself works efficiently, but ultimately it is all about the result of all steps together. By learning on the basis of the aforementioned lessons and making changes based on them, the lead time is improved step by step. In the end, a final drastic step is taken. The ‘walls’ between the departments such as sales, planning, purchasing, production, installment and customer contact are broken down. Multidisciplinary teams are created that are responsible from the first customer contact to the final delivery of a kitchen. It may be clear where it ultimately leads. There are now teams that are able to install kitchens very quickly in a fixed cadence, with a lot of satisfied customers and a happy large shareholder as a result.

Conclusion: The chosen approach in which we learn from a Formula I team and apply it to a kitchen manufacturer shows that you can do a lot in a non-IT company too to improve your organization’s agility and what this means for you in your role as manager ( e.g. letting go and decentralized decision making). Pouring it into a business fable makes it fun and easy to read. Personally, I find the description of the current situation and “improving” through control steps too long. This covers more than half of the book and by shortening that part, the book could have gained in strength. Nevertheless, the book is definitely worth reading and offers plenty food for thought and potential experiences!

While writing this review they came to replace my boiler. A team of 2 mechanics arrived at 8 AM. They were ready around noon. Small problem: the digital thermostat had an error message. No connection with the boiler and therefore no heating! They failed to solve it. A connector between central heating and thermostat turned out to be broken. This happened them quite often when replacing a central heating boiler. However, this energy supplier had a separate team for this. After a 30-minute call, they told me that I would be called back within half an hour. That indeed happened and the team was due to arrive that afternoon between 1 and 5 PM. Around 4 PM another mechanic came with a new connector. Solved in five minutes. Suppose this energy supplier had read this book, they would probably have integrated this thermostat team with the heating installers after evaluating these types of problems. Many phone calls, an extra ride, and the turnaround time at my place would have accelerated by 50% and as a result a cost reduction for the supplier!

A week later I receive a letter for the yearly maintenance of my boiler. This letter still involved maintenance of my old boiler. After a few phone calls, it became clear that the back office had not yet made the changes. Another example of different teams / silos. In the meantime, I have received three more letters about scheduling regular maintenance, so I have to give them a next call and bring this book to the attention.

To order (managementboek): Formula X

To order ( Formula X

How to accelerate decisions: