 |
Is Complacency Impacting Design Execution? |  |
|
|||||||||||||||||||||||||||
Dear Subscriber, In talking with many design organizations over the last couple years there are two concepts that are a common thread across the majority of teams. These notions are insidious in the way they confirm the acceptability of the status quo for a team. Complacency becomes the norm through the affirmation of these two perceptions. We are Doing OK We Can Work it Out on Our Own Jeff Jorvig
Take a look at the “ideal” no surprises goal pictured here. If you can say without hesitation that you have attained all aspects of that goal then I would emphatically agree that things are going OK for you. I have never personally seen the goal accomplished in teams that I have worked with or managed over my 24 years in the industry. The crisp level of deliverable and receivable expectations that would allow that ideal goal to be attained would be the mark of the ultimate design team. If the ideal goal is unattained for your organization then I maintain that things are not OK and there is work to be done. The ideal goal can simplified into who, what, when, how and where for deliverers and receivers of information. Two areas of this goal that are frequently attained to a high degree include who and when aspects of deliverables. In a preponderance of cases the what, where and how portion is what keeps a design team from asserting success in meeting the totality of the ideal goal. The what, where and how inhibits the team from being able to say things are OK. Other indicators that things are not OK: Note that these items are actually due to disconnect in expectations. Hence, they can all be mapped back into failing to meet some aspect of the ideal goal. I carry that goal around, show it in presentations, tout it to my clients and point to it as an indicator of execution problems. Why? Because deliverable and receivable expectations are the root of disconnects that lead to surprises in design projects. Those surprises lead to diversion of resources to unplanned tasks and tank the design plan every time. That goal says it all in managing towards being OK in the ability to execute design in a predictable fashion. Are things OK for your team?
Faced with a specific execution issue, in countless cases a team will elect to identify and work through them on their own. This is commonly viewed as the best alternative based on incremental costs to the business organization. Using internal design resources to fix a design teams own headaches can be viewed as zero cost, at least to a first order. Getting into some type of arrangement where there is a dedicated resource involved immediately raises the incremental cost flag, creating a barrier to real improvement. A decision based solely on incremental cost is a myopic cost/benefit view of any improvement project for a design team. Bringing loss of revenue into the equation elicits a total impact view of fixing an execution issue. The addition of a revenue loss figure yields a time-based component that quantifies the impact of not addressing an issue in a timely manner. Revenue loss is defined as the income that could have been generated had the execution issue never existed. In essence, it reflects the revenue loss associated with a delayed production ramp due to additional design spins, schedule slips, quality issues etc. When analyzing the cost vs. benefit of various approaches to the solutions of an execution issues, revenue loss must be included. A simplified approach I have used to incorporate revenue loss is to create an impact term that is essentially the ratio of revenue loss to cost, the impact ratio. To minimize revenue loss the assumption would be that a cost increase of some level would produce a shorter timeline to solution. A higher impact ratio would be a less desirable scenario than a lower one for a given set of solutions. With the impact ratio defined let’s take a look at
the broad spectrum of tradeoffs that need to be
reviewed as you decide how to proceed towards
implementing a solution. The figure below identifies
three possible scenarios in implementing a specific
solution. One where the design team handles it
themselves, another where the solution is
facilitated via program management resources and a
third being a solution facilitated by Jorvig
Consulting. You think it’s biased, don’t you? Well, that is within the realm of possibility. My point is that you need to map out your potential solutions in some fashion and weigh the merits of each approach. A decision based purely on incremental cost is rarely the best-case scenario.
If you have any specific design process questions that you would like an opinion on (my opinion) please email them to me and I will address it here. I will maintain your anonymity, unless you indicate otherwise. Go ahead and throw me to the wolves - give me something that you have been struggling with for a while. Also, please let me know of any general design process topics that you would like to see covered in future newsletters.
|
|||||||||||||||||||||||||||
 |
 |
