Product Development Archives

Product Development Page 22

Lately we’ve been talking about the problem of engineering efficiency and the amplification of that problem through overburden; work coming into the engineering group without increasing capacity. To get engineering efficiency we think there are seven things that are necessary:

Understanding what work is active in your organization
Understanding what work is waiting to become active (backlog)
The ability to reprioritize work on a regular basis
The ability to estimate the effort required for any project

Those are the four ideas that most organizations are familiar with. There are three more that are tied to the time box concept.

A standard for capacity utilization
How much engineering efficiency and time do you hope to get out of each engineer in creating value for customers on a regular basis?
Right-sized Communications
How do your engineers communicate with each other. How is communication for forward looking work managed? And how is progress communicated from the technical side to the business side. Ideally this is done using visual communication. In he Time Box concept this is done easily at the end of each cadence period.
Operating your team as a team
We tend to operate our engineers as individual contributors and simply call them teammates. But, when we take their capacity and distribute it across multiple projects we really disenabling their affiliation with a team and operating with team behavior.

This problem, the problem of teams and breaking engineers into tiny chunks, will be covered in other posts. But for now we’d like you to understand that the concept of time boxing can be a huge driver in the increasing of your engineering efficiency.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive.

Follow Bill at http://www.twitter.com/systhinking

Today I want to talk about one of the key lean concepts, the concept of cadence. We’ve been talking about engineering efficiency and we’ve talked about getting projects off to a clean start. Today I want to talk about keeping projects moving forward and keeping a high level of engineering efficiency within projects. To do this let me talk first to Michael Kennedy’s concept of two value streams within product development. Mike’s thesis says there are two value streams — The knowledge value stream and the product value stream. Many of you will think of these as research and development.
In Mike’s concept all of the knowledge gaps, the things we need to learn to be successful in the projects we’re undertaking are the first things you do. You invest your upfront work to close the knowledge gaps. The second value stream is where you take all of your knowledge and march the development of the project to market. In the way Kennedy lays it out, the backend or value product stream can actually be put on a schedule or clock and run to hit time-to-market. The front end, the knowledge value stream, can’t be put on a schedule. You can’t put learning on a clock. You don’t know when the actual learning that necessary is going to occur.

So, how do you drive work in this upfront learning cycle of product development? The answer is simple. You use a recurring period. Many of you probably have a recurring meeting with your supervisor every week or every couple weeks. That recurring period is to keep things moving forward progressively. The same can be done with the work in engineering. The use of a regularly repeating periodic pattern is Cadence — a key Lean concept.

You can use Cadence in driving learning by putting in place short-term deadlines. This helps keep focus on the learning work that is being undertaken. It gives the people doing the learning or research a chance to demonstrate progress or get feedback. It also gives the supervisor of the researchers a chance to nudge them back on course if they’re moving off course and following a different bend or path that may be cutting into their straight-line path to engineering efficiency.

This concept of Cadence is used in product development in various places in various contexts. It’s used in Japan in what is called “integration Events.” The leader of a project will meet regularly with a team to check their progress and provide instruction for what should be included in the next cadence period. It’s used in software development. It is seen most clearly in the “sprint” of Scrum software development. Recently it’s also been used in hardware development. There is an emerging concept called “Time Boxing” which uses cadence as a way of keeping progress on track. We’ll be speaking more about Time Boxing in this series, but for now, just understand that if you’re interested in increasing your engineering efficiency from the pathetic levels that are standard in the US now to something that resembles a cost effective use of those resources — Time Boxing is really something that is worth investigating.

Follow Bill at http://www.twitter.com/systhinking

We’ve been talking about some of the issues with Product Development. Today I’m going to talk about a problem present at the start of projects. There is consistently a lack of clarity in the goals or requirements coming into engineering. Software development has made significant progress in managing this problem, but in hardware engineering it persists.

Clarity of goals is important. Clarity is one of the hallmarks of an achievement culture. If you’re trying to achieve something in a project the more clear things are at the beginning the faster you can make progress and the better you can make headway towards the accomplishment you’re trying to achieve.

We used to hear about engineering “throwing things over the wall” to manufacturing. There is a similar problem at the beginning of a project where work is thrown over the wall into engineering without any kind of clear objective or explanation of what is trying to be accomplished. In our consulting experience we’ve run into companies where individuals have spent the beginning of a project just trying to understand what is being asked of them and what a project is all about. Once they’ve figured it out they still need to gather whatever supplies or materials they need to start making progress towards the goals of the requested work. Both of those steps are absolute efficiency killers. If you’re familiar with the efficiency statistics in engineering, then you know that the amount of time engineers typically spend engineering and creating value for customers is pathetically low in US industry.

Software rather than hardware has made significant progress in improving efficiency. They have done two things to increase the efficiency of their resources: implemented the use of use cases (Use Cases explain how somebody is going to use their output product), they also use “stories” in software development techniques such as Scrum. In the case of stories, someone making a request of software engineering will make a request and the request will have three specific parts. The request will say 1) who it came from (name and role of the person making the request) 2) what is being requested (generally the statement of “what” is very simple) and 3) what is the benefit that will be recognized by the organization (the benefit statement of executing the work)

When something like a Scrum “story” is generated, it doesn’t go directly to an engineer’s desk to be executed. There is another step that is fundamental to the role of managers. This step ensures engineering efficiency is optimized and removes anything other than the executable work from the engineers. This is the role of filtering the requests. Filtering requests can take various forms and is done by managers. It is in place to make sure that when that work arrives on the desk of an engineer, the goal of the work is absolutely crystal clear. This is the primary lever of change that will enable significant increases in software and hardware engineering efficiency at American organizations.

Follow Bill at http://www.twitter.com/systhinking

We’re habitual beings. We tend to do things the way we’ve always done them. I want to write about specifications in that context today. A lot of the organizations we work with utilize a specification sheet or template in to which a fill-in-the-blanks exercise is executed to create a spec sheet and communicate design intent to engineering. The problem with boilerplate templated spec sheets is they don’t distinguish the value that differentiate one spec from another —e.g. which spec is important, less important, arbitrary, etc.

A way of dealing with that issue is to divide your specifications into three categories: Musts, Coulds, and Shoulds. The Musts are those requirements that without which you don’t have a product. Without them you don’t have a competitive position in the marketplace. The Shoulds are the things on which your competitive advantage is built; things you’re trying to accomplish in your value proposition. The Coulds are things that would enhance the value of your product, but may not be worth focusing on and investing efforts to achieve.

These three categories still could be communicated as point specifications, but we can increase the value and information being communicated by expressing them differently. One way would be expressing them as ranges. Instead of having a point spec you then have a range of values. Hitting any of the points within that range would provide value as perceived by the market place. Those ranges can be communicated to the engineer and used to guide whether they reached sufficiency in their design effort.

You can take these ranges and enhance them further and make them communicate better information by placing them beside a graph to show how the market value will change over the range. That way an engineer can see that they’ve achieved the target, but with a little more effort they can achieve more value. It’s meaningful information to them for their design.

The third way of communicating the Should to engineering would be as goals, as word/statement based ideas of what you’re trying to accomplish with a particular design. The communication of goals takes this point focus defined by specifications and opens it up broadly — bounded only by conceptual boundaries defined by the goals.

The communication of Shoulds as goals allows the focus to shift from achievement of various points to the generation of new knowledge and looking for alternative ways of solving a technical problem. It allows us to rethink the very nature of how we manage engineering and product development. It also frees us from the pain and misery of testing to spec – pass/fail testing – to testing for knowledge and learning. And this knowledge that we gain from testing a full range of technology allows us to capture and apply knowledge as innovation within product design.

Follow Bill at http://www.twitter.com/systhinking

I personally have a problem with the term “problem solving”. Let me explain it to you. First problem — whenever we deliver problem solving training for organizations people have a very difficult time organizing their thoughts into a problem. If you take a problem and look at it as current situation, future or better situation, and the gap between the two, then you have defined your problem in a way that will allow you to improve the situation.

The other problem I have with problem solving is the word “solving.” Solving implies a total solution – a “fix it once and for all” mindset. In Lean we look not to solve or attain a perfect state. Instead we look to make measurable and cost effective progress towards an ideal state. We look for intermediary desirable states and balance out the costs of getting there against the gains in the situation that this better state will provide.

Even though I have issues with the term “problem solving”, and much prefer the term “continuous improvement”, problem solving is so well known and so accepted in organizations that we will accept the term. But please understand, when we use the term problem solving we really mean continuous improvement and making progress towards a better state.

Follow Bill at http://www.twitter.com/systhinking

The Pareto Principle comes to us from quality guru Joseph Juran. He named it the Pareto Principle in honor of Vilfredo Pareto who was an Italian economist. Pareto himself first developed the concept by recognizing that 80% of the land in Italy was owned by 20% of the people. This was reinforced when he realized that 80% of the harvest of peas in his garden came from 20% of the pods. This has been generalized in business into the Pareto Principle that states “80% of your sales come from 20% of your customers. And that 80% of your problems come from 20% of your issues.”

In it’s most general sense Pareto says that 80% of gain comes from 20% of the effort. And the last 20% of the potential gain requires 80% of the effort…four times the effort required to reach 80%.

The Pareto principle argues for the lean concept — which is the concept of the interrupted journey. The cost benefit ratio favors limiting your aspirations to 80% or less of your way to the ideal state. When you execute an improvement effort in Lean — when you apply PDCA or the Deming Cycle — you make this targeted state explicit. You look for the balance between your opportunities and your constraints. You get done what is available to get done at manageable expense. This is all done in the effort, not of a complete and total trip to the ideal state, but a trip to a better state and improved situation.

Follow Bill at http://www.twitter.com/systhinking