Month: May 2014
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.