Complex decision making

2 Comments »

When you are working with complex project it can be hard to make decisions because you have to consider so many different variables at the same time and when you later realize you were right or wrong you wonder what I thought.

 

On tool in order to help you make complex decisions and at the same time document your decision making so you can reflect on the decision is the decision matrix. A decision matrix is a list of values in rows and columns that helps you to identify and analyze the performance and relationships between a set of values and information. Elements of a decision matrix show decisions based on certain decision criteria. On the rows you put the different alternative and on the columns different criteria’s. Then you weight how well each criteria feels on each alternative. After that is done you weight each criterion to see how heavy they shall be.

 

Cost Flexibility Guaranties Supported by 3-part products
Alternative 1 0 (expensive) 3 3 2 0*3+3*3+3*1+2*3 = 18
Alternative 2 3 (free) 1 1 3 3*3+1*3+1*1+3*3 = 22
Alternative 3 2 1 1 1 2*3 + 1*3 + 1*1 + 1* 3 = 13
Value / weight 3 (important) 3 (important) 1 (good to have) 3 important

 

Alternative 2 is what we know right now and value in this situation the best choice. If you later learn that you over estimated the value of some criteria you can go back and see how that changes you outcome.

 


Timetable Slipping

4 Comments »

Milestones are like progress bar indicators for internal stakeholders’ use. They provide feedback on progress to everyone involved.  In different software programs, I have come across at least three different progress bars:  the first easily reaches 90% then stalls, making you wonder if it has stopped.

The second one just shows that it’s working and does not stall but you don’t know how much work remains to be done. The third one gives you the impression of accuracy because it provides a realistic estimate. Even if the progress bar indicates there is still a lot of time left, you tend to prefer it over other time bars because you know you have time to do something else. Let’s look on some aspects of tracing progress.

Your project is getting closer to a release deadline and you ask the lead developer, “How’s is it going? Are we going to ship on time?”

 

“Hmm, something has come up!”, she tells you, “I have done really great for the last 4 weeks, but today I found something no one thought about and the timetable slipped 3 months.”

 

What’s the chance of that happening? I’d say it’s a small chance. The reason is timetable slip-ups don’t happen at the end of the milestone or project. Slip-ups show up at the end. Yet they happen every day and every hour. As soon as someone answers an unexpected e-mail, rushes home because of a sick child, or tracks down an intermittent but catastrophic bug, slip-ups happen. The sooner you can identify how much time is left and prevent slip-ups, the better you can estimate time periods, assuring team members and stakeholders that the timetable is still reliable.


Collective Ownership

1 Comment »

Collective ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or re-factor. No one person becomes a bottle neck for changes. People what are running their own raise becomes dangerous for the rest of the team. If you hear someone says “That module I dare not touch its Lotta’s code, it’s to complex. Only Lotta can do that!” you got a problem. Your “bus-factor” (How many people that need to be run over by the bus in order to need to redo that knowledge) is 1, if Lotta is run over by the buss all knowledge of that is gone. Collective ownership is quite closed linked to the practice of unit testing and continuous integration. In order for people to dare do change and not have 100% overview of how other modules might be affected on an accidental way a lot of automated unit test helps the developer to handle parameters that he don’t know by heart. And in order for everyone to be able to work and overview the project frequent check-ins shall be done. If mastodon check-ins is done, people don’t learn as much from each other’s code and it’s has a tendency of develop into that one single person is responsible for a specific class.

 

Dilbert.com


Managing Key Positions

9 Comments »

Identifying key positions

Within any group there are things to be done.  The outcome of some challenging activities is more important than others for your unique project/system/organization.  For your project to be successful, identify the key factors/positions for success. I recommend starting with identifying the different roles and responsibilities.

When you have identified key positions to be filled, investigate what abilities and experiences will make success possible. How can you minimize risk by recruiting people who have worked on similar projects or systems? Who has the ability to fill the position either now or later because they have the potential to become great at that role and position?

Many projects start in the reverse order. I have the following persons and resources, what can I do with them and who fits in what role? Person X is best suited as IT Quality manager looking after the process, documents and so on. You don’t start with roles have to fill. Person X might not be an asset at all for this project. It might work out, but when filling key positions, it might be wiser to cross your fingers and wish for luck.

What Might the Key Positions Be?

It is difficult to come up with a general answer.  I’m mainly looking for two different factors – managers and very specialized roles. There will probably be fewer of them than the rest of the team so it is more important that you get the right person. It might also vary over time, when a project is small and the key positions are mainly developers.  However, later in the technology life cycle, it might be the product owner or project portfolio manager/assistant.

Hiring for Key Positions

There are a few general recommendations for hiring for key positions. If you can match people, roles and projects perfectly, I’m confident you will have a much better chance for success.

  • Values – Does the person share the core values of the organization/project/company? You cannot teach key values to people just to make them fit in. As Harry Truman once said, if people don’t know right from wrong when they are aged 30 they probably never will. You cannot teach people the right attitude, you can only teach them the right skills.
  • High standards – Look for people who you don’t need to manage. If they tend to have high standards from previous work they tend to exhibit the same high standards. People with low standards look for the easiest way out, they’re into short cuts.  The quality of their work shows these low standards. You will have to define what’s expected from them and they need constant supervision and control. Your job is easier if you work with team members who maintain their high standards.
  • Ability – Does the person have the ability to become the most suitable person for this key position? He doesn’t have to be the best suitable right now, but does he have the potential to become the best suitable person in the future?
  • Neurotic responsible – don’t hire someone for a key position, hire for a key position responsibility. It’s important that a person doesn’t think of the work as just another job. He must think of it as a sacred responsibility. You want a person who wants to fix a hole – even be neurotic about it – as soon as he spots a hole. They won’t rest until it is fixed.  This is an ability that you can’t detect immediately, but over time, you will be able to identify these neurotics who take their tasks very seriously. They’re the ones you want in your team because you know they won’t let problems fester and leave them unsolved.

How to Manage Key Positions

When you recruit people for key positions, invest the time to know them right from the beginning. Getting to know people and their abilities is a challenge so make the effort to know them, their work habits, their values and their strengths and weaknesses.

People are different so it’s good practice to be 100% familiar with these differences and how to handle them. A key position person is like a captain or helmsman on a boot. They give clear orders and steer the ship away from dangerous rocks. Each person on that ship may be following orders, and meeting targets, standards, and plan. But what happens if these targets, standards and plans are wrong?

Ask yourself: do I have the right seat or do I have the right person in the wrong seat? Maybe another position would be better? However, if you had the good fortune of hiring the right person for the right task, so whatever it takes to motivate, coach and develop them.


Agila projekt till fastpris!

Comments Off on Agila projekt till fastpris!

(About my talk on the Strategy Day 2011 about Agile and Fixed Price with my college Niklas Florén, it’s in Swedish).

 

På Sigmas strategidag höll jag i ett föredrag om ”Agila projekt till fastpris” här ser du min presentation.


Three trends that affect your business: Mobility, Social Media and Clouds.

Comments Off on Three trends that affect your business: Mobility, Social Media and Clouds.

My second post for Sigma is about the three largest trends right now – Mobility, Social Media and Clouds. Read the article here Three trends that gets your business: Mobility, Social Media and clouds.

Picture on Patrik from ICT Easy Fair in januari 2012


The Product = the Teams Creativity and Knowledge

14 Comments »

Up until the industrial revolution, success came from personal competence. You were judged on how well you mastered your craft. When industrialization took over, mechanization became the winning process.

Both craftsmanship and manufacturing have well-understood and static problems – demand is predictable.

Software development, however, is not a product of a well understood and static problem. It is more about exploring unknowns and adapting to reality. It is about collaboration and social learning based on knowledge and creativity. It is therefore a more demanding process combining methodology, process, and leadership.

How the product have change over history!


First blog post on my new position: The Digital Future is Mobile

Comments Off on First blog post on my new position: The Digital Future is Mobile

Yesterday I wrote my first blog post for Sigma. My new position as Enterprise Mobility Manager for Sigma includes some promotion and marketing. It’s in Swedish but here is an English google translated version.

Best Regards
Patrik Malmquist


Beyond the Horizon!

Comments Off on Beyond the Horizon!

 Understanding what to do, where to go and what the end result will become like is important for planning, understanding and motivation of all teams. This is sometimes called establishing a vision, but the word vision is too grand for me; it sounds like a prophet, Martin Luther King or Gandhi mixed together. Especially when undertaking greater challenges where the destination is beyond the horizon it’s important to discuss the direction. It’s about start giving people an idea of the end result. If people do not know where they are going or how they are going to get there, they are soon going to become very frustrated.

In order to set a destination you need to look beyond the horizon that promote change and improvement but at the same time says something of what we can do to reach it. The destination can consist of many goals but often not focusing on the measurement of the goals. For example “Our new product shall help knowledge based workers to collaborate over long distance. It focuses on collaboration and simplicity and enables high-quality teams to brainstorm, prioritize and reflect. It is not a project management tool or a tracking tool; it’s more of a sandbox that can help knowledge based workers to reach their goals.”

What is so great about a common, accepted and understood direction is that different stakeholders and team members can start working and at the same time has some idea what it will result in so that the can take micro-decisions that is based on that direction.  

Don’t forget to document the “destination” with what success is, why it’s important and how you know you’ve achieved it. Post it prominently and involve you visionary destinations in you planning and demos. But remember you will not reach the destination because it’s just an imaginary goal, when you traveled beyond the horizon the world will not be as you imagined it; it will be less colorful but more real. Then you need to adapt to reality make the best of it. The best and most valuable ideas will probably present them on the journey. If you plan everything from a total imaginary map your journey will become lined with failures! So setting a visionary imaginary destination isn’t about defining goals and planning the trip, it’s about setting a direction so you can look on the compass when you wandering in the dark.

Related article: Creating a Push from the Past or a Pull from the Future!”


Ideal Time and Velocity

15 Comments »

One management practice in is that you might estimate everything you do in ideal time. Ideal time is how long a task takes if there were no interruptions. And when you plan you don’t plan that all work is 100% focused and non-interrupted. Instead you can calculate with a velocity. Velocity is the number of user stories (or user story points) you can do in one iteration (or sprint) in Scrum this is known as the focus-factor. If your team (4 persons) under a 3 weeks sprint working 40 hours a week completes user-stories that where estimated to be 360 hours of ideal time your focus factor / velocity would be 66%.

Advantages of the velocity term is that it is much easier to estimate in ideal time, it’s what comes natural when you think of how long something will take to do. You get a focus on prioritizing to work with only planed work tasks. People avoid interruptions. You don’t need to plan to do more work than time available × the focus factor per iterations so you don’t get false expectations. You are able to trace the velocity over time, velocity has ability to peek in the middle of a project and become lower in the beginning and in the end of a project. In the beginning it can have with that people are stumbling on how they will work and they might not have all infrastructure and roles on place. In the end of a project new unplanned work have a certain ability to appear. It often takes between 3 to 6 iterations for velocity to stop fluctuate and become more stable.

This doesn’t mean that 34% of the time was wasted it, is not just spend on things that where planed and prioritized from start.


Stakeholder Analyze for Project Managers

48 Comments »

There is a different level of engagement among stakeholders. Some are really involved because their stakes are high and their risks are greater, while some are more interested in being informed. Scrum has a small story to show the difference between a stakeholder you really need to focus on and one who is not as involved.

A pig and a chicken walk down the road. The chicken says to the pig, “should we start a restaurant together?”

The pig answers, “What a great idea! What should we call it?”

“We can call it Egg and Bacon”, says the chicken.

“Hmm, I will be really involved putting my ass in the pan, but you will not be as committed when you are just laying eggs!”, answers the pig.

This is the difference between stakeholders with stakes and stakeholders who don’t.

When starting a new project invent everyone that might have expectations on the project. Then you can organize them after their interest and power over the project. This gives you a clue of you will need to manage that specific stakeholder so that you put your energy on the right ones. This helps you see identify key people not just the one that sounds much.

 

Everyone who is affected by the project will have an opinion on how the project will affect them personally and their organization. Users want the best software and customers want it for free. Sales people want a unique product that creates a great business value for as many potential customers as possible. Suppliers want a larger share and your development team wants to use only state of the art tools and technologies.

 

Your responsibility as a software development manager is to make sure that the right thing gets done, in the right time and in the right way. To make this happen, understand the needs and strategies of the different stakeholders. The responsibility of the software development manager, therefore, is to make sure that everyone gets what they want. This makes him the middle man negotiating with all stakeholders. Your aim is to give everyone something – so they feel like a winner. I want to point out that making everyone happy to a certain extent is a key role of the software development manager.

 

The Process of Managing Stakeholders

If a project manager’s main concern is to get all stakeholders satisfied lets analyze the flow of the work. Stakeholders have interests in the project and communicate their expectations, when all expectations are recorded a prioritization can be made based on strategy and stakeholders power. Because you got limited resources you will not be able to do everything that everyone wants so you will need to make a lot of trade-offs in order to get everyone committed and satisfied. The worst thing you can do is not to be clear that all expectations will not be fulfilled

Many companies just record expectations and write down requirement but never sit down and really prioritize what is important and really drives business value; therefore, it is common for developers working on features that are more of a decorative art and good to have stuff than real business value. This is not the developers mistake is the business and project managers’ mistake, programmers might implement a function perfect. It’s quite common to make the wrong thing in the right way.

.

 


Min Pensions was appointed to one of Sweden’s top 100 sites 2011 by IDG!

Comments Off on Min Pensions was appointed to one of Sweden’s top 100 sites 2011 by IDG!

Internetworld 100 bästa sajterna i Sverige 2011

Real glad to hear that IDG/Internetworld has appointed www.minpension.se to on of Sweden’s top 100 sites in 2011. Anders Lundströms the CEO of Min Pension i Sverige AB comments the appointment at Min Pensions blogg. For more information about the nominations and the top 100 sites look at Internetworld.


At point of Action and at point of Decision

Comments Off on At point of Action and at point of Decision

For me enterprise mobility is about enabling companies to get their strategic information at point of action and point of decision. People have become used with specialized context application in their personal life from there smart handheld devices. Now almost every knowledge based worker has a device that enables them to have internet wherever they are. People will expect to have the same important information about their work life as accessible as personal life information. This is of course a big challenge, there is many aspects like; Security, Integration, Infrastructure, Governance, Deployment, Maintainability and so on.  Over the next years we will see allot of change within the enterprise mobility area. Now the infrastructure and the devices have developed so that this is possible to do for the ordinary company. This will result in many intreresting solutions.


Enterprise mobility and point of action


The value of choise is only valueble if you are competent to handle the choices.

Comments Off on The value of choise is only valueble if you are competent to handle the choices.

Today my guest blog post on http://blogg.minpension.se/2011/11/08/vardet-av-valfrihet/ was published. I’m wrote about the value of freedom of choice is only valuable if you are competent to handle the choices. If you have more choices than you can handle you only becomes stressed out.


Pressure and Agility

Comments Off on Pressure and Agility

In a TV episode of the show Mythbuster, Adam and Jamie are investigating what can be done with duct tape. They build a rope bridge that is over 10 meters (30 feet) with duct tape, then they both walk over the bridge. They show that it’s possible to build a 10 meter (30 feet) rope bridge with just duct tape, thanks to its elasticity – it stretches when it’s weighed down.

But there is a difference between Adam and Jamie. Jamie is about 10 pounds heavier than Adam. When the duct tape reaches its maximum elasticity, vibrations start to interfere with the construction. It takes Jamie 5 times longer to climb the bridge than Adam because of the vibrations.

You’re wondering, how does this relate to software development?

When increasing pressure (and expectations) on a group to stretch to their maximum ability, the group needs to focus more on fending off all vibrations than on getting over the bridge. This slows down people. Plan-driven processes are harder to stretch because it isn’t as flexible.

But when working under high pressure, plan-driven processes can be a good thing. It’s when you don’t have clear lines or possibilities that generate much discussion. How far are we prepared to go this time? Can’t we make an exception this time? Can we squeeze that in?  This elasticity creates vibrations and the focus on the project isn’t as good. Negative vibrations become noise as we talked about earlier.  A more bureaucratic organization doesn’t stretch and therefore there is less noise under pressure.

Going back to Adam in Mythbuster, the conclusion is that he might use duct tape to build a bridge, but Jamie, who is 10 pounds heavier would gain if he builds it with rope that doesn’t stretch as much. Using the same argument, high pressure projects probably would gain if they were more bureaucratic, to help project members focus more. Being bureaucratic helps increase focus on a project and keep the speed up.  Too much pressure under uncertain circumstances, on the other hand, lowers the speed because you have to adapt to all vibrations.

A Small Anecdote from my Carrier

My team had plans for a big release in a couple of months.  Two days before the release,  some business managers were nervous about us closing down the system for too many hours. They had pressured another partner and convinced him about the need of the system’s availability and uptime.  So it didn’t look good that we were closing the system for 8 hours on primetime.

They started putting pressure on our development team by asking them to start earlier and finish deployment more quickly. We thought of a way to satisfy this demand.

We worked on a new plan, beginning with doing a full backup starting at 10 pm the day before and closing down the system at 6:00 am instead of 9:00 am. This lowered the planned downtime by 3 hours.

When the vice president started calling specific developers and maintenance personnel, they felt the pressure and focused more on the pressure than on the actual plan. When people felt pressured, quality suffered and the downtime became much longer then planned.

What did this all cost? Coming with an alternative plan took one day and five more people – longer time than if the original plan was executed. Hope it was worth the value of the relationship with our partner.

If you’re always flexible and preach the value of flexibility you could some day be pressured to go a little too far. Everyone probably would have gained if I only dared to stick to the original plan and not allowed a late change. Changing plans the night before actual battle is seldom a good idea.

Have you missed the Dubt tape hour on Mythbusters? Here is the episode MythBusters: Duct Tape Hour 2


Leadership vs Management

Comments Off on Leadership vs Management

Leadership is about understanding direction while management is administering the journey as efficiently as possible. A leader shows the way, develops long-term strategies and plans, and inspires others so they have a clear understanding on the project’s future success.

By informing others, the organization will have the ability to adapt in a self-directing way. Leadership is about pulling the organization towards the future. Management is more about short-term planning.

Complex organizations need managers to coordinate the work, so that the right priorities are established and reached. Managers push the organization towards goals on a daily basis. Leadership is about helping people to cope with change, while management is about helping people coping with complexity. Leaders set direction, mangers plan and budget. Leaders align people, managers organize and supervise staff. Leaders motivate managers’ control.

You can quickly see the important differences between leadership and management in this classic story. A group of workers is cutting their way through a jungle. The workers in the front will be cutting the undergrowth and cleaning it out. The potential managers will be behind them, sharpening their machetes, writing policy and procedure manuals, holding development programs and setting up work schedules. The potential leader is the one who climbs the tallest tree, surveys the entire situation and yells “wrong jungle” (Covey, 1989).


Organizing Software Development

Comments Off on Organizing Software Development

Organizing work is a combination of doing the right thing, in the right way in an optimal way. This is hard and what makes it even harder is that the right thing and the right way are constantly changing. Over the years I work with software development; first the traditional project management schools with their view that if you only know what you did, success would come from making good plans and them focusing on executing that plan as effective as possible. Then the agile and lean view became the dominated methodologies that was convinced that if people was just empower, self-organized, became more business oriented and changed to adaptive planning great things would happen.

 

What was the Problem with the Traditional Project Management School?
The traditional view of project management was focusing on administrating passive resources that needed to be managed are not a view that was optimal for knowledge based work. The problem with the traditional view of organizing software development was foremost the underlying view that we were doing something repeatable, if we only was experienced enough we would be as effective as any manufacturing industry. A factory has a deterministic process, where you can expect a certain outcome based on the input, this works when the variation within the process is quite small. But the problem with our craft is that we develop products based on knowledge and collaboration, and then the variations within that process comparing to factories or building buildings are much higher. Software development is therefore a non-deterministic process that actually has more to do with developing new products than building houses or producing something in a factory.

 

The Agile Problem!
The biggest trend in organization of software development the last years are probably transcend to more agile methodologies. My view of the agile manifest is that many people foremost reacted against bad leadership and management style that wasn’t adapted to the knowledge based work people performed. The underlying idea of just empower everyone and give them give them the right to self-organize, isn’t optimal in all situations. I believe that when people realized that the plan-driven view wasn’t working they all started to look on those who shouted most and earliest, (and with all respect to the old gentlemen’s that wrote the agile manifest) they were a little to overrepresented by the anarchists. Don’t miss understand me, I’m a pro agile methodology. I just felt that leadership somewhere was lost in the focus on new process and tools. The problem with scrum trainers is that they value the scrum process and tools over individuals and interactions.

 

The Future
The traditional view of project management and the agile view both have its pros and cons. In the future both worlds will need to connect better in order to get the best from both. I believe that software developments sometimes are a deterministic process where you only install an out of box system and just tweak some things, and sometime it’s more of an exploratory journey into the world complexity.

 

P.S.

I know all Scrum trainers are in London this week, on the Scrum Gathering 2011. Goto Jurgen Appelos sessions he seams to be the only one besides D Snowden that understand the basis of our work, complexity. I’m in London this week as well but unfortunately without attending the Scrum Gathering.

D.S.


Agile means that you are Business Value-Oriented

2 Comments »

Traditional plan-driven methods focus on keeping to the timetable. Agile methodologies focus on consistently delivering maximum business value. New information and knowledge about a problem are more valuable; therefore, Agile methodologies encourage change and try to make changing requirements and systems less painful. If new knowledge is better let’s adapt and not stick to a plan that is not based on that knowledge. To do this, you need to adapt some practices; otherwise you face too many risks. For example, you need to do a lot of automated tests to validate there are no new bugs.

Don’t Waste Money on Features Never Used

If you’re working with the waterfall model and are in the requirement capture phase, tell the stakeholders, “Give me all your requirements now or it will cost you much more later if you change your mind”. Not planning everything from the start will entail additional costs later. The next phase is the design phase and all required drawings of what’s to be built are produced. If new things are learned during the construction phase, going back and changing EVERYTHING becomes too expensive for the customer. So what does the poor customer do? He tells them everything he might need for fear of not getting what he wants. In a 2002 report from The Standish Group, an investigation was made into failed projects to see how much the built-in features were used. They found that 20% of the features were used either always or often. The interesting part was that 45% of the features were never used. There could be many explanations for why features are never used in a system or product. But if you ask stakeholders to give you all the requirements up front, you end up with a lot of things that will never be used. If you deliver work in small pieces and work first on the first priority and also allow stakeholders to re-prioritize work, this problem can be addressed.


Top 10 posts on my blog!

Comments Off on Top 10 posts on my blog!

I have looked on the statistics on what people read on my site and this is currently my most read posts:

Happy reading!


SECI: a Model of Dynamic Organizational Knowledge Creation

2 Comments »

To understand how knowledge is spread throughout an organization, we need to understand the SECI modell by Prof. Ikujiro Nonaka (Hitotsubashi University). When Prof. Ikujiro Nonaka introduced the SECI model (Nonaka & Takeuchi 1996) it became the cornerstone of knowledge creation and knowledge transfer theories. He proposed four ways to combine and convert knowledge types, showing how knowledge is shared and created in organizations. The model is based on two types of knowledge – explicit knowledge and tacil knowledge. Explicit knowledge is visible knowledge, it is easily explained, quantified and documented; tacil knowledge is unseen and grows with habits and hands-on work, but is not easy to share or document it.
The Seci modell
The model also consists of 4 different process situations: Socialization, Externalization, Combination and Internalization.

  1. Socialization
    This process focuses on tacit to tacit knowledge transfer. It’s done when knowledge is passed on through practice, guidance, imitation and observation. This is when someone who is learning a new skill can interact with a more experienced person, ask questions and observe. This occurs in traditional environments where a son learns the technique of wood craft from his father by working with him (rather than reading books or manuals on wood working).
     
  2. Externalization
    This process focuses on tacit to explicit knowledge transfer. Externalization is about making an internal understanding more quantifiable like writing documents and manuals, so that the knowledge can be spread more easily through the organization. The processes of externalization are good at distributing knowledge for repetitive work or processes. An expert describes different parts so that readers can understand “if this happens do the following in order to succeed”.
     
  3. Combination
    The process of combination is about transforming explicit knowledge to another person’s explicit knowledge. A typical case is when a financial department collects all financial information from departments and consolidates this information to provide an overall profile of the company.

     
     
  4. Internalization
    The process of internalization is about transforming explicit knowledge to tacit knowledge. Through reading books, manuals or searching on the web, explicit knowledge can be learned.

There is a spiral of knowledge involved in their model, where the explicit and tacit knowledge interact in a continuous process. This process leads to creation of new knowledge. The central thought of the model is that knowledge held by individuals is shared with other individuals so it interconnects to a new knowledge. The spiral of knowledge or the amount of knowledge grows all the time as more rounds are done in the model.

The basis of all change is that the need for change is known and communicated. If it’s not on the agenda it will probably not be valued. If spreading of knowledge is important for your organization, talk about it with the people involved.