Adrian-Slywotzky's Art of Profitability is a business noval set in a very simple plot: a teacher (David Zhao) with many years of practical experience and a willing student (Steve Gardner) who is committed to move his organization forward.
The book covers 23 profit models in a way that hits the little gray cells. By no means what is written is sufficient in itself, but I found by rereading some chapters I filled in more details than actually are there.
Another interesting and sometimes bothering thing is, is that a lot of the homework assignments for Steve are to read other books.
Back to the Switchboard Profit model.
Switchboard Profit identifies the components that led to the business success of the Hollywood agent Michael Ovitz who took the bundling-of-talent concept that he so successfully perfected in television, and applied it to film-making, but with a difference, because it was much more difficult to create a concentration of power in an industry fragmented by many movie studios. Ovitz' first step was to assemble talent; the second, to find a source of stories through a great literary agent; and third, the creation of critical mass. In the author's words, "The more critical mass you build, the higher your probability of putting together a package that works. That, in turn, means that a star, a writer, or a director will be better off being represented by you rather than any other agent, because the odds of being part of a winning combination are so much higher. …So now the studios have to deal with you, and the stars want to deal with you." Thus the analogy of the old-fashioned switchboard Ovitz became that all his various contacts needed to plug into. The lesson, of course, isn't that simple. Predictably, much work is needed to arrive at the numbers constituting the critical mass that is required to generate revenues seven to ten times greater than in the traditional model for that industry.
With this in mind I discussed a business model for a professional-association and a university. The interesting part is that with a model like the Switchboard Profit model one can quickly translate it to the specific situation and drive down into the particular crucial nifty gritty details. And the Switchboard Profit model is just one of the models that can be used to evaluate and develop profound sounding business models.
Of course the real interesting and challenging part is what is coined in the book as the drudgery part of innovation. Where people need the most pressure and encouragement: turning a new idea into people working processes, procedures, etc to deliver the real products; from marketing to sales, from purchasing to manufacturing and delivery. However interesting, it is outside the scope of the Art of Profitability.
Wednesday, May 26, 2010
Wednesday, May 12, 2010
MAYA-principle: a successfactor for implementing change
| The key to any well implemented change is how well the change is embedded inside the minds, behavior and actions of the involved people. They MAYA-principle, Most Advanced Yet Acceptable, can be very useful for planning the change to maximize the embedding of the change. |
The MAYA-principle is the invention of Raymond Loewy, an industrial designer. He believed that, "The adult public's taste is not necessarily ready to accept the logical solutions to their requirements if the solution implies too vast a departure from what they have been conditioned into accepting as the norm." Calling the concept "beauty through function and simplification," Loewy spent over 50 years streamlining everything from postage stamps to spacecrafts. "I'm looking for a very high index of visual retention," Loewy explained of his logos. "We want anyone who has seen the logotype even fleetingly to never forget it." Among Loewy's highly visible logotype designs are those for Shell Oil Company, Exxon, Greyhound and Nabisco.
What we learned from the MAYA-principle is that in order for something/somebody to be well placed and ‘sticky’ in the mind of the target audience, the basic message must be simple, recognizable, and at the same time very different from past experiences.
To give an example. We’re in the process of developing a product for the time being called “Project Portfolio Management the Symbision Way”. We believe from our experiences that we have a way of implementing and managing the Project Portfolio of an organization that is both very effective and practical in terms of realizing the organization’s objectives.
Of course there are others that claim to be similar, even better, and/or that it is done already 30 years ago. This is like ‘fighting a battle uphill’, you need to be hugely outnumbering the others and accept high losses. Well Sun Tsu claimed that the best way to win is to position yourself in such a way that you don’t need to fight. And here we believe the MAYA-principle can be very useful.
When the objective is to implement a change, the best way to have it implemented is by not fighting the people that are confronted with the change. Of course there are plenty of alternatives to the one that is chosen to be implemented, possibly some of them even are much better. Of course any good change is sound in its basic and of course people did in the past sound things as well, thus it resembles what was done years and years ago. If we have to address this kind of energy we’re fighting a battle uphill.
The change should be communicated visually with a high degree of retention. The communicated change should be simple enough to directly grasp directly the essence and apply to every detail of the change. And yet, the change must be experienced as something unique as something invitingly new.
During my career I’ve seen some people hopelessly fail in well implementing a change. I’ve stood aside people implementing the seemingly impossible as it was the easiest thing in the world. Even in situations that were ‘tainted’ with many years of failure. One of the key differences was how the change was communicated. If ‘not advanced’ enough, people ‘resisted’ because they kept asking why this change and not something like …. If ‘not acceptable’ enough, people ‘resisted’ because they couldn’t grasp it directly and needed more ‘time’ and ‘understanding’. The change agents that were successful had an easy to grasp message that was very different from what most, if not all, knew.
A very good example is Demings’ PDSA-circle. Over 60 years later it is still an essential part of improvement and quality programmes. The PDSA is so different from anything else before and after. The PDSA it is so simple and yet very profound. The PDSA grasps you visually. All the key ingredients of Loewy that he formulated into one single term: MAYA; Most Advanced, Yet Acceptable.
Labels:
collaborating,
continuous improvement,
creativity,
product development,
project management,
team
Friday, April 30, 2010
Finding the cause for the majority of the issues
Wouldn't it be wonderful by following some simple steps it is possible to find the root of what is causing the majority of the issues?
One has to remember, often, if not the root, the solution lies outside the periphery we tend to look for solutions. Therefore out-of-the-box thinking is required to address the root of the majority of the issues.
The Cloud is a tool that finds its origin in ToC (Theory of Constraints). It is excellent for finding root causes of the majority of the issues.
Basically it is a very compact description of a dilemma. When examining several dilemmas it is usually possible to extract a few, or even one, generic dilemma: a description of a reoccuring dilemma. There are many uses for this: explanation of what happens in the past and now, prediction for the future ...and a good guide to effectively deal with the reoccuring dilemma.

There are several techiques and instructions around to construct a cloud and a generic cloud. Here I present the technique I developed over the years. The technique is very reliable and others are quite successful in using it as well. Best of all, same input usually generates very similar conclusion ...this can't be said of some other techniques.
The following is a real case where I'm the coach of a programme manager who feels he needs to improve himself. You might recognise yourself or a generic issue. Fine, but the scope of this blog is the specific case for this programme manager. For home work I asked him to following:
We practised together two:
Two interventions are not enough, but after little more than one week I got a list with 15 interventions. This is more like it, following some rules it structured the data in such a way that all what was required to see if there was a commonality between one or more dilemmas.
One has to remember, often, if not the root, the solution lies outside the periphery we tend to look for solutions. Therefore out-of-the-box thinking is required to address the root of the majority of the issues.
The Cloud is a tool that finds its origin in ToC (Theory of Constraints). It is excellent for finding root causes of the majority of the issues.
Basically it is a very compact description of a dilemma. When examining several dilemmas it is usually possible to extract a few, or even one, generic dilemma: a description of a reoccuring dilemma. There are many uses for this: explanation of what happens in the past and now, prediction for the future ...and a good guide to effectively deal with the reoccuring dilemma.
There are several techiques and instructions around to construct a cloud and a generic cloud. Here I present the technique I developed over the years. The technique is very reliable and others are quite successful in using it as well. Best of all, same input usually generates very similar conclusion ...this can't be said of some other techniques.
The following is a real case where I'm the coach of a programme manager who feels he needs to improve himself. You might recognise yourself or a generic issue. Fine, but the scope of this blog is the specific case for this programme manager. For home work I asked him to following:
- List all the interventions you took or wanted to take in the past 3-6 months
- For each intervention:
- List why it was / would be good to take that intervention
- List why it was / would be good NOT to take that intervention
- What goal did you aim for that required both above
We practised together two:
| Intervention | Why good to | Why good not to | Goal/Aim |
| Call resource manager | - personal contact - keep a project member | - maintain relation - steering committe takes their role | maintain relationship |
| Escalate to senior supplier | - project member will return - senior supplier takes his role | - maintain relation - respect the decision | to force a solution |
Two interventions are not enough, but after little more than one week I got a list with 15 interventions. This is more like it, following some rules it structured the data in such a way that all what was required to see if there was a commonality between one or more dilemmas.
In this case there was, to be precisely everything seem to fit into one generic dilemma:
Two question had to be answered:
- Do you ever let something go wrong?Answer: seldom
- Does the formulated objective (green box) match what you feel is what you are trying to achieve and seems so hard to achieve?Answer: yes
Then we discussed the validity of the generic description of his core dilemma. It matched.
So how to read the cloud:
- You demand people (steering committe members, resource managers, etc) to live up to their roles and responsibilities in order to improve the probability for succes in your project.
- However, you feel you should not demand people to live up to their roles and responsibilities because you must respect their positions and this makes you look powerful.
- If you demand people to live up to their roles / responsibilities, you do not respect them (you know better and act like a boss rather than a subordinate or equal) and you look weak because you can't manage.
- On the other hand, if you do not demand people to live up to their roles and responsibilities it is very hard or impossible to improve the success of your project
- And, you need both to improve the probability for success of your project and to respect people's positition and to look strong in order to fulfill your objective: make steps forward in the project and that people associate you with delivering good results.
We explored his generic dilemma using his home work and other situations. It was a very good respresentation for his situation.
The theory of the cloud says: as long as you are captured in the dilemma, you will not achieve your objectives. You might do a bit of both, make some trade-offs, you will never achieve what you want because you need BOTH necessary conditions. Any solution MUST positively contribute to both necessary conditions (the blue boxes) at the same time.
With this we have the focus, we have very clear criteria for any solution or idea to improve his situation.
He is going to talk to some senior programme managers he knew who are quite successful and try to learn how they deal with the dilemma. What do they do to ensure that stakeholders take-up their responsibility and that respect is paid to the position of the stakeholders? He knows how to value any suggestion or proposed idea.
So, with a couple of simple questions and following some rules to construct the generic cloud, the dilemma that caused so many issues latetly for this programme manager became very explicit. And, at the same time we have focused his attention on the characteristics the solution must have in order to work for him. This is very helpful to think-out-of-the-box.
Labels:
continuous improvement,
creativity,
out-of-the-box thinking,
Theory of Constraints,
Thinking Processes,
TOC
Wednesday, April 21, 2010
Team Forming
In forming the team three things are important:
Style
Shared vision
The creation of shared values and a shared vision go nicely together. To make a change last it is necessary that the implementor is part of this process. Not only to ensure that the momentum of the change continues, but it is harmonius as well. This will make the transition much smoother and increases the overall success. A good start is a job half done.
|
| In any change that has some impact, it is important to have a quick start. Momentum must be created and all the basic processes, procedures, tooling, etc must be in place as soon as possible. The style, start-up'ers, that is required is quite different from the next phase. Usually this phase takes between 3 to 6 months. To make the change lasting, slowly but with persistance, people have to be guided in the new way of working. The time frame associated with this is in the order of 18 to 24 months. The style, implementors, is very different from the style needed in the previos phase. One of the biggest pitfalls we experienced in many organizations in every type of industry, is that good people are in charge with the inappropriate style given the phase. The most success has been achieved by having a person with start-up style in place in the beginning and that the implementor is already present in the team. When the start-up nears completion, the implementor becomes more and more dominant and will take full charge at a given moment. The start-up'er will stay available and will emerge when a crisis might take place. |
Shared values
Too often people want to start working too soon on the change. A change is never a one man show. People have to work closely together and sooner or later differences will pop-up. Having strong binding shared values ensure speedy and proper solutions whilst ensuring the relationship; making it usually even stronger. Shared values come into existance via the well known steps Forming-Storming-Norming-Performing-Adjourning. However, each of these steps must be carefully prepared and managed. People with natural leadership skills can do this on the fly, however, to ensure the right outcomes they do well by doing what others for sure must do: following Plan-Do-Study-Act for each stage.A start-up'er must embrace and breath-and-live the shared values that are created together very quickly. Implementors usually require more time and tend to focus on those shared values that in the implementing stage are so important. |
Shared vision
| Very quickly the team must embrace a strong, compelling and above all shared vision. It must be felt in the gutt. Frequently the initial vision changes during the process. If people only agreed, or can only agree to an initial explicit made vision, success is very unlikely. And, at the same time a strong shared vision is required to make people enthusiastic, to mobilize them. It is almost mandatory that the start-up'er has a strong vision. A strong vision provides certainty in times of uncertainty that any change will bring. The shared vision must address the why, the what, and the how-to. |
The creation of shared values and a shared vision go nicely together. To make a change last it is necessary that the implementor is part of this process. Not only to ensure that the momentum of the change continues, but it is harmonius as well. This will make the transition much smoother and increases the overall success. A good start is a job half done.
Labels:
product development,
project,
project management,
team
Saturday, February 20, 2010
PDSA
No, not a typo. There is definitely an "S" in PDSA rather than a "C". Most likely the "C"-version is best known because of the same behavior Deming tried to correct on so many occasions.
The well-known PDCA and SPC were invented by Walter A. Shewart The impression he made on W. Edwards Deming was such, that Deming became a great advocate of Shewart's methods. It lay out the foundation of how Demming helped Japan after being defeated in WOII to become one of the biggest industrial players in the world.
The idea of PDCA was to act as a guide for all projects, not just quality projects.
The well-known PDCA and SPC were invented by Walter A. Shewart The impression he made on W. Edwards Deming was such, that Deming became a great advocate of Shewart's methods. It lay out the foundation of how Demming helped Japan after being defeated in WOII to become one of the biggest industrial players in the world.
"I called it Japan in 1950 and onward the Shewhart cycle. It went into immediate use in Japan under the name of the Deming cycle, and so it has been called there ever since" Out of the Crisis by W. Edwards DemingStill, some of the credits have to go to Deming as well. In the words of Deming "Shewhart has the uncanny ability to make things difficult". So Deming spent a great deal on figuring out Shewhart's ideas, and devise ways to present them with his own twist. In this way the simple concept of PDCA came into existence.
The idea of PDCA was to act as a guide for all projects, not just quality projects.
PLAN |
|
DO |
|
STUDY |
|
ACT |
|
When looking at the last bullet under Study, summarize what was learned, it is not hard to imagine why Deming changed the "C" into an "S". A check will only look whether something did or didn't meet the expectations. A study will look as well into why the deviations occured; both in a positive and negative sense.
In orde to do the Study correctly, the Plan must minimally contain the predictions (second bullet under Plan). And, ideally the Plan should contain the fundamental assumptions on which the predictions are based.
If you want to read a bit more about the background, there is a nice paper called Evolution of the PDSA Cycle.. It step-by-step shows how Shewhart's original ideas evolved into what we now know as PDSA.
If you want to read a bit more about the background, there is a nice paper called Evolution of the PDSA Cycle.. It step-by-step shows how Shewhart's original ideas evolved into what we now know as PDSA.
Labels:
continuous improvement,
Deming,
PDSA,
project,
project management,
quality
Wednesday, February 10, 2010
Problem Solving vs Goal Realizing
During my education I wrote an application letter for an internship pointing out my problem solving skills. The reply was short: "we don't have problems". At that time my mindset was such that I only could laugh; who doesn't have problems to solve?
Later when working for the A. Goldratt Institute in The Hague I became interested in how NLP would fit in the ideas of the Theory of Constraints (TOC) and in particular the Thinking Processes and MSW.
Problem solving vs goal realizing, two sides of the same coin? Semantics?

Because if you solve all your problems, you achieve your goal. Or, what blocks you from your goal are problems that must be solved.
Well, for some time I thought this as well. However, then I came in a stage of life thinking of a serious relationship and having a family. Slowly it started to dawn on me. The best way to solve problems is by preventing them. The amount and depth of problems I would encounter with having a serious relationship would go up. They would sky rocket by having a family. So, the problem-solving strategy would be not to start a relatinship and have a family. Yet, this would create a situation that would seriously limit, block would be a better word, the achievement of my goal.
Of course the above example is my own personal one. Other people have different goals and different requirements. However, I feel most can relate to the above personal example and possibly see a similar situation for themselves. It is quite possible, sometimes necessary, to create additional problems in order to achieve your goals. Equally, it is quite possible, very often I presume now, that you can solve most if not all of your problems and still be far away from achieving your goal.
So far most, if not all, the tools, methods, approaches or whatever that is usually associated with problem-solving that I learned and practised can be used for goal realizing. The key difference between problem-solving and goal realizing is not the skills and tools, it is the attitude and mindset. And, it makes all the difference. Both for myself and my customers.
Goal-realizing means stepping outside the seemingly obvious. Finding out what is really being pursued and ensuring that this is being realized. It also means that the rapport you create with the customer is based on what the customer finds important. And, if you are your own 'customer', this is even more important.
Intended or not, that short reply I got "we don't have problems" triggered a very nice understanding many years later.
Later when working for the A. Goldratt Institute in The Hague I became interested in how NLP would fit in the ideas of the Theory of Constraints (TOC) and in particular the Thinking Processes and MSW.
When I confronted the TOC-community with the question whether TOC is problem-solving or goal-realizing, all chose problems-solving. Interesting to note, the break-through of TOC was the book called The Goal. One of the first steps in the Thinking Processes is to define the goal and how to measure it. This is very similar to Lean or Six Sigma.One of the NLP things that struck me was that if you focus on something you will create a perpetual situation. Let me explain. In relation to problem solving it would mean that you will create an ongoing situation where problems must be solved; e.g. self-fulfilling profecy of ongoing problem solving. NLP therefore tends to focus on what one wants to achieve, rather than what one doesn't want. So rather saying that you're good in problem solving (which is a 'negative' thing), you would say that you're good in goal realizing (which is a 'good' thing).
Problem solving vs goal realizing, two sides of the same coin? Semantics?
Because if you solve all your problems, you achieve your goal. Or, what blocks you from your goal are problems that must be solved.
Well, for some time I thought this as well. However, then I came in a stage of life thinking of a serious relationship and having a family. Slowly it started to dawn on me. The best way to solve problems is by preventing them. The amount and depth of problems I would encounter with having a serious relationship would go up. They would sky rocket by having a family. So, the problem-solving strategy would be not to start a relatinship and have a family. Yet, this would create a situation that would seriously limit, block would be a better word, the achievement of my goal.
Of course the above example is my own personal one. Other people have different goals and different requirements. However, I feel most can relate to the above personal example and possibly see a similar situation for themselves. It is quite possible, sometimes necessary, to create additional problems in order to achieve your goals. Equally, it is quite possible, very often I presume now, that you can solve most if not all of your problems and still be far away from achieving your goal.
So far most, if not all, the tools, methods, approaches or whatever that is usually associated with problem-solving that I learned and practised can be used for goal realizing. The key difference between problem-solving and goal realizing is not the skills and tools, it is the attitude and mindset. And, it makes all the difference. Both for myself and my customers.
Goal-realizing means stepping outside the seemingly obvious. Finding out what is really being pursued and ensuring that this is being realized. It also means that the rapport you create with the customer is based on what the customer finds important. And, if you are your own 'customer', this is even more important.
Intended or not, that short reply I got "we don't have problems" triggered a very nice understanding many years later.
Labels:
Lean,
MSW,
Six Sigma,
Theory of Constraints,
Thinking Processes,
TOC
Friday, February 5, 2010
Dealing with Half-Backed Ideas
Plenty of situations where you, or others, might have an idea. The idea sounds okay or even great, but ...there is a but. The idea is not 'perfect'. The idea has some serious negatives as well. Result: some people try to chop the idea down, some are resisting the chopping.

The NBr is part of what is known as the MSW (Management Skills Workshop). A subset of the Thinking Processes of the Theory of Constraints.
The NBr is a process in two phases that is simple, organic and very effective. The two phases are:
- Construction of the NBr
- Trimming the NBr
The best way is to use post-its.
A short video on how to read an NBr
The basic steps for phase 1, the construction of the NBr, are:
Note: Some of the items put aside will be used in a 'because'. Some of them will not be used for different reasons.
That's all and now you have a pretty good NBr on the idea that is not only verbalizing clearly why some oppose the idea, it is also easy to communicate.
The next phase is finding where the best place is to trim the NBr; the place to look for some additional ideas to prevent the negatives from coming into place.
The basic steps for phase 2, finding a pivot point in the NBr, are:
Why the NBr works so well
The NBr isn't a guarantee a solution will be found. What the NBr as a process does is to ensure a proper and shared understanding is created. Further more, it moved the focus of the discussion towards were the energy is needed. The point were a solution must be found for the idea to work without the negatives.
A very smart way of slowly but steadily changing the perception of both the idea generator and the one(s) who see negative ramifications on the idea. A very novel way to help people think out-of-the-box.
Labels:
NBr,
Negative Branch,
Theory of Constraints,
TOC
Subscribe to:
Posts (Atom)
