• http://business901.com/wp-content/uploads/2015/06/MWL-5-Pack990o.jpg

A Lean Interpretation of Professor Christensen’s Talk

I base my Lean Thinking on 3 principles. Standardization, Improvement, and Exploration. The little “i” of innovation is provided through SDCA and PDCA. Standard Work (SDCA) creates a can-do attitude and frees up time for problem-solving. Applying PDCA, allows you to “see” opportunities for improvement and leverages the resources in your environment. I like to use the term EDCA learned from Graham Hill to designate the Explore aspect of Lean. I view it as more of Design Type thinking content that allows for that collaborative learning cycle with a customer.

Companies need innovative practices. It is where development and the Big I of innovation (EDCA) occur. Companies need all three. These components along with your attitude influences and defines the Lean culture. PDCA is the glue. Without that mindset- it is difficult to traverse between the 3 and I think all successful companies have a mixture of all three. Some may be more innovative, some may be more standard, but having a practice in place for each, is what makes Lean successful (IMHO).

Lean Thinking

I was in a discussion the other night with Mike Rother on the adoption of Toyota Kata thinking in the Lean community. He asked me if I had viewed the Clayton Christensen video on YouTube where Mike had commented, “Professor Christensen explains why just pursuing efficiency is not enough, which is an important message for the next generation of Lean thinkers.” After viewing the video, my thoughts, drifted back to how well the Gateway of SDCA-PDCA-EDCA applied to this Christensen presentation.

Toyota Kata is documented in Mike Rother’s book Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Evolution of the Product through Configuration Management

Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management. Jon Quigley

Jon has won awards such as the Volvo-3P Technical Award in 2005 going on to win the 2006 Volvo Technology Award. Jon has secured seven US patents and a number of international patents. These patents range from human machine interfaces to telemetry systems and drivers aides. Jon is on the Western Carolina University Masters of Project Management Advisory Board as well as Forsyth Technical Community College Advisory Board. Jon also teaches Project Management classes at City University of Seattle via distance learning. Jon also is an expert at ITMPI (IT Metrics and Productivity Institute) giving webinars on numerous product development topics. Jon’s latest book is Configuration Management: Theory, Practice, and Application.

Download MP3 of Podcast

Business901 iTunes Store

Mobile Version

Android APP

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Jobs To Be Done Matrix

I have been pretty vocal in the past about using Value Stream Mapping, Value Stream Mapping should be left on the Shop Floor, and along with a couple other blog posts, Shaping your Customers Vision and Kill the Sales and Marketing Funnel. I think these types of tools lead us down a precarious path when used in sales and marketing. The approaches prematurely foresees a solution for the customer without ever understanding their needs.

In the Job To Be Done Thinking created by Tony Ulwick (What Customers Want), Ulwick claims that these three distinct outcomes are what organizations need to know in their marketing practices. Expanding on them….

  • Jobs (to be Done) are the tasks or activities that customers are trying to get done
  • Outcomes are what customers are trying to achieve
  • Constraints something that may prevent a customer from using a product or service

If you would like to learn more about JTBD thinking, I would recommend following Mike Boysen’s blog, Effective CRM. In one of his past blog posts, The Customer Process: The Five Things You Need To Know Now, he discusses the use and importance of Mapping. Many might seem a direct contrast to my above thoughts. The problem that I have always had is that all this mapping and journey stuff has typically been done without the customer involvement and/or a method to validate the assumptions we make. How I solved it presently for myself is with an old tool, Logframe Matrix that I have waffled using for a decade or so. I had first used it working with Non-profits and later revived it as I worked on some outcome mapping tactics. A quick description of the process:

A LogFrame Matrix is a document that outlines the key features that lead to a project achieving its goal. A LogFrame consists of a 4 columns and 4 rows.

  • The first column represents the hierarchy of activities to outcomes that needs to occur for the project to succeed.
  • The second column represents the indicators that are appropriate measures of whether the activities, outputs or outcomes have been achieved.
  • The third column represents the data source or means to verify the indicator.
  • The last column outlines the assumptions that need to hold true for that particular activity, outcome or purpose to occur.

LogframeThis reminds me somewhat of a SIPOC (Suppliers – Inputs – Process – Outputs – Customers). The SIPOC offers a high-level view of the process, and I always recommend using before the mapping process begins. However, the LogFrame could be used to validate the steps of a Customer Journey Map, after the mapping event and as we put our findings into action. It allows us to test our assumptions and put some granularity to our mapping process. I did an outline based on how a Job To Be Done LogFrame is viewed.

Job To Be Done

The objectives, of course, would look a little different. A short description follows:

Who the Customer Wants to Be: Michael Schrage, author of Serious Play, published a book taking these concepts one step further. Who Do You Want Your Customers to Become? challenges us to take our value proposition of use to a longer term growth platform. He dares us not only to have a corporate vision statement, but a customer vision statement saying that our future depends on their future. He phrases all this in something he calls “The Ask.” I discuss this concept in more detail in a blog post, Shaping your Customers Vision. When we flip this thought to Job To Be Done Thinking it allows us to have that impact statement or that larger goal that our customer is striving to achieve.

Job To Be Done:  JTBD is broken down into a couple of components. The Main jobs would describe the tasks that customers want to accomplish, and the Related tasks are what they want to accomplish in conjunction with the main tasks. They can be further broken down into social, emotional and functional aspects. Depending on the complexity, we could make a separate LogFrame for those components but you can have separate multiple Jobs to Be Done on each LogFrame. Since, I usually start with Post-it-Notes, I sometimes will color-code them based on the social, emotional and functional aspects. I will also keep the color-coding for the remaining two steps if needed.

Outcomes: The specific results of the activities ? used as milestones to what is being accomplished during the process. these remain the same concept though I may have current, intermediate and long-term outcomes.

Activities: The actual tasks to produce the outcomes. This is usually a high-level view and can be turned into a project plan or a Kanban board for execution.

I am in the process of creating a generic outline to follow in more detail, but this is just a starting point. What are your thoughts? Does this add some opportunity for better measurement and verification? Could you monitor and evaluate your efforts better this way?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Evaluating a Sales or Service Control Point

In a recent podcast with Evan Leybourn (Related Podcast and Transcription: Agile Business Management), we had a discussion about Project Closure. In the past I thought it was a good thing to do. It ties into my most recent work. We have been discussing projects in general and how project management has changed. Especially from the plan-do style to the envision-speculate models. The plan-do assumes that you have acquired all the knowledge up front and can guide you to the desired outcome. The Envision-Speculate assumes you will be learning along the way and making adjustments accordingly to reach your desired outcome.

The traditional style of project closure has also changed. I grew up working projects and always understanding that every project had a beginning and an end. And in the end we had a Lesson Learned or project closure. We even used to have project stage gates or control points where we would get things back on track. This was during the days of Product Dominant Logic Thinking and transactional thinking which still exists but in the SaaS industry it is getting less common. We used to sell something hang on for dear life during the warranty period and hoped at the end we came out ahead.
Now that has changed. Car dealers make their money after the sale for example in their service departments. Rolls Royce sells aircraft engines over the lifecycle of the plane it goes on and handles all service of the product. I can go on with Kindles, mobile phones, etc. But that is not the point. Service-Dominant Logic is based on the principle that there is no value derived till the product/service is used is becoming dominant; pun intended, in our culture. Even LinkedIn and Slack credits your unused credits. Rewards cards can also be an example. What has happened is that we now view lifecycle and projects are minimized or non-existent.

Customers are now being looked at on a lifecycle basis and for good reason, especially in a SaaS company that is funded by a subscription model. When you think about project closure, it really needs to be more of a transitional step that leads to further integration between the companies versus minimizing the gains and relationships. A good transitional step that I referenced several years ago and use it quite often in SaaS type developments and on-boarding is looking through the lens of that term MoSCoW. Moscow_thumb.jpg

• M – Must Have: non-negotiable principles that every activity must comply with me in order to be considered done.
• S – Should Have: teams need to comply with these principles or justify their non-compliance.
• C – Could Have: optional principles that act as guidelines at the discretion of the team.
• W – Won’t Have: negative principles that teams should avoid.

In sales and service processes, we are always trying to evaluate the marketing funnel or in most recent terms the customer journey. How do we know when a cusotmer is ready? Are we evaluating it from a transaction-type experience or a system-type, more holistic view? Setting guidelines on how we get to the next level is imperative in a world governed by use. What is the next obstacle or target we must overcome? What is the next horizon not just for us but for the customer and for the two to co-create value together? How can we make it easier to do business with us? What is the largest risk we have? Questions like this are always popping up. However, using a consistent guideline described in the term MoSCoW may lead to more consistent results.

About: Evan Leybourn pioneered the field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. You can find out more about Evan on his website, The Agile Director.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Have you done a Customer Relationship Audit?

I know your thinking that all you need is the Net Promoter Score and I will not disagree that it is an important question. However, sometimes just a good old audit and questionnaire might still have some value. You may not be able to do it all in one setting or even ask all the questions the authors of Building Better Teams: 70 Tools and Techniques for Strengthening Performance Within and Across Teams might suggest. The audit is divided into 5 parts with 15 total questions that can be rated 1 to 10 and 2 open-ended questions. My suggestions is to have not only your customers complete it, but your own salespeople and managers. The discrepancy itself might be alarming.  Pain Point

From the Book:

The process involves sitting down with your customers and identifying opportunities in five key areas:

  1.  Accessibility: How available is your team to your customers?
  2.  Responsiveness: How quickly, and with how much enthusiasm, do your team members respond to customers’ requests and inquiries?
  3.  Listening skills: How much attention does your team pay to customers’ inquiries and concerns?
  4.  Information sharing: How open is your team about sharing information with customers?
  5.  Collaboration and conflict resolution: How effective is your team at being collaborative, especially when resolving problems or conflicts?

The other part of this audit that I liked that it asked how collaborative you were doing conflict. Always a difficult thing to do. Are there other areas they are missing?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Do We Still Need Documentation?

In this day of being adaptable and agile, should we really spend time to document everything? Sure we need some documentation done but heck — it seems like I’m creating work for myself sometimes. Is there a fine line on what goes into configuration management and how strict of a practice we keep? -jd

Jon Quiqley: I think there should be, and I think there probably is. If you are in a company who is building Website applications, and you’re all self-contained and you know where the source code is at and it’s only in one place or two places, then maybe the risks associated with that make you inclined to take one approach that might be a little streamlined. The same is true with Agile; if you’re building something that has no potential for harm and there’re not many downstream consequences in terms of build, then you might strip away some of it. But the thing is this, it adds time but if you don’t do it, it’s probably going to add a lot more.

I will share a little story that’s a little embarrassing but, fortunately, it was 25 years ago, so I learned from it and moved on. When I was first out of school, a job at an industrial applications, I was building or designing 8051 embedded type control systems. I’m writing the software, I build a little bit, and it works, and I build a little bit more, and it works. They get a little complacent because I think I’m the deal because everything I build works fine. Then I sit down and I write, write, write, write, write, write, write and build, build, build, build, build, and compile it and I compile it with no errors. Now all along, I had not changed the source file name. I build a lot, I compile it, I burn it into the target integrated circuit, and I put it into the system, and the things that were working no longer work. In fact, nothing works; not what I added, nor what was there that used to function. I think to myself, oh man, I’m in trouble. Because my source code, I kept no traceability on what rev was attached to what. I didn’t bump the revision; I just kept on writing, and the compile was the same way. The only thing I had that worked was in an integrated circuit in another one of the prototype systems. I had to take the IC out of that system, put it into a reader and the hex code out of it and turn that into the assembly language.

That was a lot of work; a lot of unnecessary work. Why? Because I chose not to keep an iteration that I knew worked separated from an iteration that I was building in terms of source code and in terms of a compiled version. In fact, I got very lucky in that I didn’t just choose to overwrite the existing memory location of that IC with this new compiled version that gave me a good compile but didn’t do anything. That’s an example of a CM failure, and I will attribute it to my youth.

Jon is next week’s Podcast guest and this is his 2nd time on the Business901 podcast. The first time can be found here Discussing Project Methods.

About: Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)