So this is a topic I have been struggling with, implementing a Kanban type system into the product design cycle, similar to what is being used on the manufacturing line. I believe there are some parallels in some facets of the design cycle, but like most skeptics I can come up with 100 reasons that Kanban would not work for assigning tasks. I am going to explore this publicly and ask for feedback.
What is Kanban? My interpretation is that a Kanban system is like a bulletin board on the manufacturing like which is filled with little cards that describe a task. A worker on a manufacturing line would pull a Kanban card from the ‘inventory’ bulletin board and perform the task on the card, and the card stays with the good. This is WIP. When the worker completed the card he would place the card and good in the finished goods bin, which would act as the inventory point for the next workstation. There are only a finite amount of cards floating around in the system, which would indicate overall system capacity. At the end of the whole system the Kanban card is returned to the initial inventory point. The point of this whole thing is to create demand for inventory in the system by ‘pulling’, or grabbing an item in inventory, which is setting the pace of the system. The opposite of a Kanban system would be a push system, where large levels on inventory are ‘guessed’ up front and dumped on the system, so the work is pushed through in batches or the inventory level is high to eliminate downtime.
An example of a Kanban system that I am familiar with is a bin system on our manufacturing line with an outside supplier. There are 4 bins in this system, one in our inventory point, one in the WIP point, one in transit between the our inventory point at the supplier, and one bin at the supplier. In this system the overall inventory is capped to what will fit into 3 bins at any one time, with one bin floating between our inventory point and the supplier to trigger a refill.
How does this apply to the Product Design Cycle? I’m not exactly sure, but what I can say is that we have a measurable amount of engineering supply, and we have a measurable amount of work in inventory. Currently the team leads look at the inventory and priority of design tasks that enter our group and assign them out to engineers as they have capacity. I see 2 problems with this, first the team lead might not know the actual open capacity of the engineer being assigned, second the engineers are blind to the amount of work being pushed to them, leading to uncertainty in their long-term view. This is the classic ‘push’ of inventory to the processors, which relies on a good deal of manual manipulation of task assignments to ensure there are no gaps or overloads.
Turn this around, why not create a Kanban board with a number of cards that reflect the amount of capacity in the design system? Would it work for the team leads to assign tasks to these Kanban card and allow the engineers to ‘pull’ these cards when ‘they’ know they have capacity, or have an opening for concurrent work? The scary part of this from a team lead perspective is a loss of control over who is doing what, but isn’t that also the point of contemporary leadership as well? Put the people in place and trust them to be honest and reward accordingly, building relationships?
I see a couple benefits, this would reduce the guessing on engineer capacity by pushing the capacity decision right to the person with the most timely information. Another benefit would be the ability to real-time measure performance and make adjustments almost real time. This may mean that if the Kanban cards start to pile-up on the finished goods side, we have open capacity. Likewise, if the cards pile up on the inventory side, we have too much inventory and not enough processing. All of this can be measured real-time, not in chunks over a period of time.
As I am writing, I am thinking about the honesty of people to work to their potential. I am also thinking about how to segregate tasks into difficulty level to minimize task miss-match with employees. I am going to sit on this to clear my head of the ‘why nots’, and revisit again soon.
What are your thoughts? Am I crazy?
So I took a cue from my own book, practicing something I spoke about in my blog on Credible Leadership. At my work we currently have many open tasks, to the point that the staff is getting stressed and projects are becoming delayed. Instead of cracking the whip harder on the team, I rolled up my sleeves and started taking on some of the low-level admin tasks to try to open time for the staff. I say low level, because I don’t want to interfere with the engineers designs, and I am out of practice with the current CAD tools and everyday PDM environment. I took on some BOM tasks, which means releasing part numbers into our PLM system and structuring Bill of Materials (BOMs). I am typically on the BOM approval side, and honestly it has been some time since I was on the BOM creation side.
As I am releasing part numbers into our PLM system I started noticing some strange quirks and bugs in our system. Here is a little background on our system, Part numbers are generated in a PLM system by engineers. A number of attributes and descriptors are added for each part number, such as a description, a vendor in purchased, vendor part number, or engineering files for fabrication if it is an internally developed part. Once a part number is created, it is then structured into a BOM of a purchasable item. Once the part and BOM is ready for production release, it is added to an Engineering Change Order, or ECO and submitted to a change analyst for routing. The change analyst adds information that might pertain to a variety of departments, then places the ECO into an electronic signoff committee for approval. Once the ECO is approved by all it become active in our MRP system to be purchased or sold. Follow all that? It’s a pretty standard workflow.
As for the bugs I am seeing in practice, I started asking around with the engineers I began hearing a number of suggestions and workarounds for the bugs. From a management level, I hear grumbling and comments from the staff on a variety of issues, and I feel it is my job to filter these comments to determine what are simply gripes, and what are legitimate issues that can hamper productivity. Hindsight is 20-20, what is clear now is that walking in an engineer’s shoes for a mile will tell a lot about real problems being faced.
One bug in particular annoyed me as a user, which in turn is a real concern from a management perspective. After I had created about 100 part numbers and structured them into BOM’s, I did an ‘Audit’ on my ECO. This ‘Audit’ is a tool that checks all part numbers created for mandatory attributes. What I found was that every part I had created was missing 3 mandatory fields, which had nothing to do with the parts themselves. This is important: these errors only showed up because I am typically an approver, so I have more rights and privileges than the engineers. These errors do not show up for the engineers.
After a lot of head scratching and asking around, it turned out that the engineers never filled in these fields because they didn’t know they had to. The change analysts knew this was a bug, so they ‘simply’ fixed each part an each ECO as they came through before submitting the ECO to the approval committee. What the hell? This is one of the CPI basics, root cause an issue and fix it systemically at the source, not later in the workflow where it needs to be fixed every time. In the case of this ECO, I found that I had to reopen each part, click to a different tab, update 3 fields to ‘No’ (its always NO, that’s another issue), then save the part, then open the next. I got really good at this after 100 parts, but it still took me 30 seconds or so on each. That’s about hour of my time.
The manager in me is baffled by this, this ECO of 100 parts took an extra hour of processing….. and we release thousands upon thousands of parts every year!
Since I made this discovery we opened the dialog with out IS team to correct the engineers privileges so they are able to see all the errors in their work before submitting ECO’s. We also defaulted all of these fields to say ‘No’, to eliminate the need to select ‘no’ over and over. The bigger question is why these fields are necessary at all, if they are always no. (well, not always, but 499 of 500 parts are ‘no’, that’s close enough).
My take-aways from this whole thing?
- Get your hands dirty as a leader to truly understand the issues going on in the trenches.
- Don’t assume your staff will always correct issues at the source without being trained. It’s all too easy for the staff to ‘just know how to fix it’, rather than systemically correct the problem.
- Listen to all the staff complaints and comments, missing just one time-suck can mean a significant impact to capacity.
Ever have a similar experience?
I read a blog some time back, unfortunately I don’t recall where and I can’t seem to find the path. This blog stuck with me, because at first I did not agree with the point of view, but now it haunts me because I see myself behaving in a manner consistent with the punch line. The blog was arguing against the use of estimates of project schedules at the onset of task. From being in a leadership position in a design team, I though this idea was crazy, and to some extent I still do, however there were some good points brought up that deserve attention.
When engineers are given a task to estimate and create a project schedule for a project of unknown complexity, we are really relying on the engineers expertise to provide good information on the ‘what ifs’ and unknowns. Engineers will typically return at least 3 different potential schedule scenarios; a pessimistic, realistic and optimistic timetable.
Pessimistic: This is the worst case scenario that assumes the challenges are beyond the ability of the immediate team or the available set of resources. This is typically a long-term time table in order to account for all the unknowns, what-ifs and direction changes. This scenario also assumes that the teams will not have focus on the project and will have to ‘fit this in’ amongst their everyday workload. From a leadership position, this scenario usually gets dismissed very quickly because of its doomsday tone, however appropriate it may be.
Realistic: This scenario bases time tables off of past performance on tasks of similar complexity and level of the unknown. Engineers will usually caveat this estimate by saying ‘based on project XYZ, it should take this long, as long as we have similar priority on this task.’ This scenario, in my opinion is the most accurate predictor of the project timeline because it accounts for the team’s ability to solve problems, provide solutions and work through the admin portions of product releases. The problem, from a leadership perspective, is that a realistic project estimate is unsavory, it ‘seems’ like it is too padded, when in fact ‘reality’ can be a bitter pill.
Optimistic: This scenario is caveat-ed right away by the engineers as being possible ‘only is all the moons align, we have no problems and we have nothing else to work on.’ This timeline is based on 100% focus on the task, 100% of the tools available and 100% success on every problem solution. The engineers knows this schedule is unattainable, and the leadership also knows down deep this it is unattainable, not only because things go wrong, but also because daily tasks will preclude 100% focus on a single project.
Now the guilty part…
From a leadership perspective, the optimistic scenario is typically used for planning purposes and to get the project approved through the overall system. This scenario may be used for a variety of reason, although top on this list is a justification that the team can fill the project within the desired timeline to meet customer expectations. The ‘optimistic’ timeline is also used with the assumption that ‘we are better at problem solving now than we were in the past’, so the optimistic timeline is accurate, if not a little generous to account for the unknowns.
If you follow this train of thought, you will see that the optimistic dates slowly become the expected dates, the expected dates become the critical dates and critical dates become the deadline dates. We all know that ‘unknowns’ are ‘unknowns’, and 100% focus is rare, if ever the true case.
I still believe that project estimates are critical from a planning perspective, but I struggle with the idea that I am also guilty of transforming optimistic dates into expectation dates. I am in favor of pushing teams to excel, but have to be cognizant of setting teams up for repeated failure.
What are your thoughts?
Leadership blogs are a dime a dozen, so I will keep this short. I had grown up in the trenches and worked my way into middle management and along the way made a number of observations of meaningful leaders on my path. I have also observed a number of poor leadership choices that have served as good examples of what not to do. I figure my best approach is to put these into writing to help me become a credible leader by example and avoid some pitfalls.
A colleague of mine posted a picture on twitter a while back that caught my attention on a number of levels. It’s a simple graphic illustrating the difference between a boss and a leader. I could put a thousand words around this and not do it justice. In a powerful nutshell, bosses place demands without guidance, whereas a leader sets direction, removes barriers and shares the burden. This is a literal example of a workforce that can get behind its leadership because he/she is showing the way, not yelling from behind. I recall the folks that I considered leaders early in my engineering career. These were the folks that were not afraid to get dirty, carried a toolbox full of well-worn tools and were always teaching their skills through hands-on demonstration. I don’t recall ever being told what to do, more being shown how to do things and empowered to go from there. Keen lesson for a leader here, get dirty and share your skills to build the whole group, don’t protect your knowledge like some power trip.
Second big key for me is to trust your staff, empower your staff, and back your staff. Sounds simple right? The good leaders in my career have shown a direction, provided the tools then granted the latitude to take it from there. Sure, guidance was needed from time to time to ensure I didn’t wander off the path, but for the most part micro-management was not a part of the process. At the time I thought the leaders in my life had all the answers, but from a practical standpoint if the leaders knew exactly what and how things should be done, what the hell would they need me for?
As I have found in the engineering management field, sometimes firm direction does need to be dictated to jump-start a solution or meet a timeline. This is a reality in business and a necessity when tough decisions need to be made. My observations of both good and poor leadership approaches to dictating direction hinge on credibility. I have experienced poor approaches where the staff is given enough rope in the hope that the desired conclusion is made, just to get overruled in the end. I have also experienced effective approaches where the direction is dictated and expectations set upfront. Even if it was not a popular direction, but it was honest and respectable. Keen lesson? Don’t jerk your staff around, trust them, empower them. If direction is needed, be honest and upfront, don’t rely on hope as a strategy.
Lastly, be humble. Simple as that. Treat your staff as you would like to be treated, not because of a title or tenure or as a means to express power. As a manager I expect the staff to be punctual and engaged, in reverse I also need to be held accountable for being punctual and engaged with the staff. This is a basic servant-leadership tactic, but dammit, leaders need to be on time. Of course a CEO’s time is probably in more demand than a design engineer, but if the CEO makes a commitment to meet with an engineer, he had better keep that commitment. If he does, trust will be formed, appreciation will be formed, engagement will be formed, all of which will generate performance as a byproduct. If the CEO blows off the engineer, well, the engineer has friends and bad sentiments spread fast.
What are your thoughts on the memorable leaders in your career? Please leave a comment.
Ok, so I talk a lot of about design for manufacturing, it’s probably about time that I describe exactly what I mean. In a nutshell, Design for Manufacturing is a design philosophy and product release strategy that tailors the assembly of a product to the operational structure of the firm. This ties in with the earlier discussion on Competing Commitments where engineers must balance the design process to serve the end user, as well as the company’s need to turn a profit. A good and successful product is one that both exceeds customer expectations for the price, and is manufacturable a cost low enough to generate profit.
Easy right? Not so much.
The key to Design for Manufacture strategy is for engineering and operations to build a good 2 way relationship and communicate the needs and structure of both units. Engineering must have a good understanding of the specific manufacturing process of the firm, and Operations must have a good understanding of the capabilities and product intents of Engineering.
For example, Engineering might intend for a product line to be offered to customers with a number of configurable options. Think of the automotive industry in the 70’s, cars could be ordered with an extensive menu of options from colors to engines to curb feelers. In reality this would mean that thousands of permutations may be possible for a single line of cars. In order to accommodate this, the manufacturing line would need to be set up in a manner that allows for a bunch of non-standard work steps based on selected options. Engineering on the other hand would need to structure its BOM’s in a ‘kit’ type format, which would group all of the components together that would go into a particular option. This might include a radio kit, an air-conditioning kit, or an engine kit, and a configuration tool that would bunch all the kits together to equal a complete product.
From a product design perspective, there are 2 main areas of emphasis for a design for manufacturing strategy.
- Match the operational model: Operational models may vary from a vertically integrated structure where raw materials are processed into components then into finished goods, or could be a contract manufacturing structure where raw goods and sub-assemblies are outsourced to contract manufacturers (CM), the brought in-house for final flavoring and assembly. The big difference for product designers in these scenarios is in BOM structure. Vertically integrated firms will benefit from a flat BOM structure that will list out every raw material and bottom level component so Operations can purchase, store, pick and assemble. In a CM model, designers are challenged with ‘kitting’ or sub-assembling groups of parts in the BOM structure in order to create ‘buyable’ assemblies. This ‘buy level’ kit or assembly is driven by how Operations would like to receive the components in the door for final flavoring of the overall product. This model requires a higher level of communication through documentation to the CM’s, specifically for revisions of parts within assemblies.
- Optimize for the operational process: This is a higher level of Design for Manufacturing. Optimization of sub-assembly BOM’s is intended to balance sub-kits to accommodate configurable options with assembly line load balancing to reduce down-time between steps on the manufacturing line. That is a mouthful. Simply put, an engineer will structure BOM kits so they take equal time to assemble. An air-conditioning kit should take twice as long as a radio kit and headrest kit, which is intentional in order to balance out assembly stations on the line.
Design for Manufacturing can be complicated upstream and require a good amount of coordination between Engineering and Operations, but the whole organization benefits with components come together efficiently into a finished good. Poorly run manufacturing organizations are often structured into silos, where Engineering will release product without regards for manufacturability, rather ‘throwing their work over the wall’ for Operations to figure out. Conversely Operations does not provide feedback to Engineering due to the siloed barriers.
Hopefully I didn’t confuse the topic, it’s a simple concept that can be tricky to implement. What are your thoughts?
So I was doing some reading on Switzerland, specifically Swiss products and business processes. My stereotype going into the reading was that the Swiss are known for banking (obviously), but also known for engineering and precision products. It’s a country with a high GDP per capita, high education levels, and a highly skilled labor force. All these would indicate an engineering powerhouse, but my reading suggested the opposite. The subtle suggestion is that Swiss are lacking in innovation, which didn’t make sense right away.
So it is true that the Swiss are known for precision manufacturing and product development, largely in the medical and machinery field. I believe the lion’s share of worldwide timekeeping mechanisms and watch movements, as in high-end watches are all supplied from Switzerland. So what’s with the lack of innovation?
Turns out it is caused in part by the institutionalized practice of Continuous Process Improvement (CPI) in the Swiss engineering practice and product design. I know this is contrary to my general view that CPI is a good thing, but for the Swiss it may have gone too far. The Swiss openly practice CPI as a means to standardize work and increase quality, which characterizes products that come from the region. Watches from Rolex, Omega, Hamilton, etc, etc are super high quality products that demand high dollars in the marketplace. Cracking one of these watches open will show an amazing level of detail in springs, gears, levers, metalwork and finishes, all working in unison to tell time. Now take a look inside a Japanese watch, you will see a battery and some plastic that houses a tiny quartz crystal that vibrates crazy fast to produce accurate time.
Am I saying a Timex from Japan is better than a Rolex from Switzerland? No.
What I am saying is that the Swiss have invested an enormous amount of time and effort into CPI in order to produce an intricate mechanism that can tell time from a wound-up spring. The Swiss are very good at what they do, but their scope of expertise is relatively small. The quartz and digital watches from other regions are technologically far more advanced than the mechanical units from Switzerland, far cheaper, far longer lasting and far more accurate, but definitely far less precise from a component level and far less cool. Careful telling a Rolex guy that a $10 Casio is more accurate and longer lasting than a $12k Rolex, but he still has to wind his daily whereas the Casio will last years on a $2 battery. (I know, I know, the Rolex is a self-winder, but you should see the point) I would not say the Swiss missed the innovation boat with Quartz watch movements, rather they chose to stick with the old-school high quality mechanical movements.
What do I mean by Institutionalized? Well, the Swiss are conservative by culture, they have a high Uncertainly Avoidance and are pretty risk-adverse. All of these attributes combined would suggest that culturally the Swiss prefer to do the same thing that worked previously, but do it better than everyone else to maintain their competitive advantage. I’m a little biased here, but look at the US in comparison. In the US we are not afraid to take risks, culturally and infrastructural we actually promote it. The vast majority of businesses that start in the US fail for a variety of reasons, but the point is that in the US we have a try-it mentality with little downside. If an idea fails, try another. Heck, we even have tax structures that reward and subsidize risk in development.
Don’t get twisted, I’m not suggesting the US system is superior. The ‘try it’ mentality can produce innovation in abundance, but it can also lead to sloppy implementation and poor quality. Look at the US Auto industry from the 70-80’s, arguably into the early 2000’s. Lots of good ideas that were poorly implemented, and the Japanese put more effort into perfecting these ideas and selling them back to the US in high quality product offerings.
So if I haven’t offended everyone yet, what is the take-away from all of this? My takeaway is that of balance. Too much CPI in your design and manufacturing can tie your hands from trying new things, or it can slow the experimentation process and allow your competitors to jump by. Evolutionary changes are good, but one revolutionary idea can change the landscape. Think iPhone and killing the competition. On the flip side, too little process improvement will lead to poor implementation and poor quality. This will put you out of business before getting to the next idea.
What are your thoughts? Please leave a comment.
Mark Graban posted a great video showing the dramatic differences between the same process being performed 60 years apart. Formula 1 Pit Stops 1950 & Today… a Huge Difference. I love seeing videos like this, because it can show huge advancements in a short clip, while cutting out all the incremental changes needed to get there. Often in our business roles we (should at least) change things incrementally for the better, day by day so it is hard to see the overall impact of our actions.
I am also a car guy, so this video is just plain awesome anyways.
What I really like about this clip is that it shows a couple major components of lean and CPI being practiced ‘out in nature,’ not in the business environment. In the motorsports community it is well known, races are won or lost in the pits, not on the racetrack. Of course no one goes to the races to watch the pits, and that’s a shame. Assuming the average speed around a racetrack is 100MPH, that means every additional second a racer spends in the pits compared to his competition means 147 feet lost on the track. That means 2 extra seconds means the racer is now a football field behind, which is difficult and risky to make up on the racing track.
Value Stream events teach us to map out a workflow or process and identify individual steps than can be ranked in terms of their impact, and in terms of their effort level to change. Take racing for example, the goal is to decrease overall lap time to be quicker than all your opponents. To do this you must be faster on the track then your competition. This takes a lot of effort, and the risk increases significantly the more you push. Overall, high impact and high risk.
Pit stops are another part of the process that apply to everyone in the race. The effort required to decrease time in the pits is relatively low effort through coordination and technology, and can be highly impactful on the race course if it can mean a football field of advantage every 2 seconds. Seems like the easy areas to streamline would be the pitstop!
Now, zoom in on the pitstop.
In the case of the 1950 Formula 1 stop, it is pretty clear that there are too few people doing linear tasks with too much time in between steps. If you competition is also taking 60 seconds in the pits, no big deal. Once your competition figures out how to drop 5 seconds, you are in a world of hurt. Hindsight is 20-20, but the 50’s pitstop was full of opportunities! Look at mapping out the subtasks, and determining which steps have dependencies. You have to jack up the car before changing the tire, check. Once the car is lifted, why not change 2 tires concurrently by adding another resource? Big time savings. To go a little further, why not jack both sides of the car up at once? Then all 4 tires can be changed at one time, brilliant!
Tools and technology obviously take a big role here, but evolution can still play a part. In 1950 the crew member used a hammer to beat the lug-spinner off the hub to change the tire. Of course air impacts were not available in 1950, but I’m sure a BFH was (Big F****gin Hammer to non-gear heads). Instead of beating on the spinner for 10 seconds with a small hammer, do it in 2! Now give each resource at each wheel (workstation) the right tool, and you have another big opportunity that multiplies itself by 4. Jump forward to 2013 and you will see the result of 60 years of evolution, multiple coordinated resources on the same task, each with his own tools, each with his own work step instructions. The result is impressive. What took 70 seconds in 1950 took less than 3 in 2013. Don’t split hairs about the exact work not being one-for-one between these stops, just marvel in their beauty.
Some big-hitters of time and effort waste can be cut from the early pitstop with ease. Once those have been corrected there are still a number of CPI steps that can, and have happened over the years. Staging of workstations, staging of tools, balancing of work steps to minimize idle time of resources, combination of steps such as pre-loading of lug nuts into the tools, of in the 2013 case have 2 sets of tools at each wheel, one pre-set for ‘off’, one pre-set for ‘on’. All fractions of a second, but all add up.
In the end, the race is won through coordinated efforts in a low-risk environment when the car is stopped. This is less risky than relying on the driver to make up football fields on the track while barreling towards a corner at 100MPH +.
Call me a car nut, but I love it.
Can you apply any of this in your business?