Future State for Lean Prod Dev by Ron Mascitelli Ame10.2


Published on

AME 2009 Workshop presentation. Ron Mascitelli, leading expert in applying lean to product development, explains how to do it.

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Future State for Lean Prod Dev by Ron Mascitelli Ame10.2

  1. 1. Envisioning a Lean Future State for New Product Development Focus: Capacity Management and Project Prioritization by Ron Mascitelli, PMP President Technology Perspectives 1.0 Executive Summary This monograph describes an integrated approach to achieving the maximum productivity and profitability from finite product development resources. Specifically: • The ability to handle more development projects, in less time, with the highest quality delivered to the customer. • The ability to plan and execute development projects to shorter, more predictable schedules, and deliver the most critical “tent pole” projects on time, with all critical success factors achieved. • Accomplish the above with a high level of agility and flexibility to accommodate a dynamically changing business and technology environment. 2.0 Portfolio Management and Project Prioritization It is almost inevitable that a highly creative firm will generate far more opportunities for new products than can be achieved with the development resources that are available. This typically due to a lack of clear and current capacity data. Unfortunately, a mismatch between the list of projects being pursued and the available resource capacity will result in unpredictable schedules, delayed launch dates, and a great deal of unnecessary turbulence in the organization. In this section, I will describe several straightforward steps that can lead to effective, fact-based management of a firm’s project portfolio. These measures will ensure that finite development resources will have the greatest impact on the future balance sheet of the company. Capacity-based Project Prioritization Metric Sometimes all it takes is a new metric. The classical approach to selecting and prioritizing new product development projects involves two dimensions: projected profitability (net present value or the like), and strategic importance (typically based on a subjective scoring system). Ideally, the highest priority projects will have both a high economic impact and will strongly support the firm’s strategic goals. There is a critical consideration that is missing from this two-dimensional world, however. Nowhere in this portfolio management scheme is the finite capacity of the organization to execute development projects considered. Instead, the matching of the project list to capacity is often done subjectively. Functional managers are asked if they have adequate capacity, and in the absence of hard data, they tend to err on the optimistic side. Moreover, some of the “high priority” projects identified using this two-dimensional approach may be capacity hogs, whereas other opportunities might yield a far higher return from available resources. A third dimension (and a third metric) is needed to make truly informed decisions in a finite capacity environment. I propose the addition of a productivity metric that divides the future profits generated by a proposed new product by the estimated hours of design / development time. This ratio, in units of profit dollars per hour of design / development time, offers an important new perspective on the desirability of a proposed project. If taken in concert with the other two traditional metrics, portfolio management now becomes a three-dimensional 1
  2. 2. world, in which a truly excellent new opportunity will yield high total return, have positive strategic impact, and will make efficient use of scarce development resources. The “Global” Priority List One of the most critical factors in successful project execution is the alignment of the entire organization around a common set of priorities. Since virtually every function within a firm “touches” the product development process at one time or another during development, this mandates that the entire firm agree on a common (i.e., “global”) priority list for all active projects. Note that it is not sufficient to prioritize just major projects; all projects that consume resources must be included. Why is this so important? Because any misalignment of priorities among contributing functions (or by individual team members for that matter) can lead to delays in the most important projects in the firm. Hence, a published list of all projects, in priority order, should be available to anyone in the firm that participates in new product development. The challenge in achieving this ideal is that tough choices will have to be made. This is hard work, but consider the alternative: if the executive team in your firm doesn’t make these tough calls, then by default, the calls will be made by the designers and developers themselves. It is far better that the decision be made by the strategic visionaries of the company, than by working-level individuals on a day-to-day basis. A / B / C Project Prioritization Imagine that we knew our product development capacity, by function and by month, and that we have established the global priority list described above. With this knowledge, we could begin allocating resources to projects in priority order, based on the stated needs of each team leader. Once the first project was fully staffed, we would move on to the next project on the priority list, and so on. At some point, we would find that project leader’s needs cannot be met, at least for some constraining functional area(s). Projects that are above this point on the priority list have been fully staffed, and hence should have minimal schedule risk (assuming manageable technical risks). We will classify this fortunate group as “A Projects”, as shown in Figure 1. Now we continue the process by allocating the remaining (albeit limited) resources to projects in priority order until we cannot realistically consider the project to be viable from a staffing perspective. These intermediate projects will still make progress, but will suffer from an increased level of schedule risk, and hence will not have predictable completion dates (at least not down to the day – perhaps predictable to the quarter). We will classify this group of less fortunate projects as “B Projects”. Finally, those projects below this intermediate group we will classify as “C Projects”. This last group of projects we will put on hold, pending the availability of freed-up resources from completed projects in categories A and B. This A/B/C prioritization will serve to arbitrate most resource conflict situations through a simple rule: A Projects always win over B Projects. If an assigned team member can move forward the critical path of their A Project, that would always be the correct course of action. Only when they cannot make progress on their A Global Priority List Project 1 Fully staffed – Project 2 High degree of …. “A” Projects schedule predictability Project X Staffed with some Project X+1 resource constraints – … “B” Projects Increased schedule risk Project Y but still viable Inadequate staffing Project Y+1 to be viable – …. “C” Projects On hold pending availability of resources Figure 1: Classification of projects into A/B/C priorities, based on the availability of adequate resources. 2
  3. 3. Project assignment would they work on a B Project to which they have been assigned (essentially as their “back-up” project). In this way, a firm would be assured that the most important projects in the company have predictable schedule outcomes, at least from a resource availability perspective. This desirable situation cannot be achieved, however, without an understanding of resource capacity, by function and time, as described above. In Section 3.0, I will discuss how this data can be efficiently harvested, and how actual project performance can provide feedback to the system that will allow increased accuracy of both project schedules and resource capacity over time. 3.0 Capacity and Workflow Management In this section, I will describe how development capacity can be quantified, tracked, and optimized. Note that once this process is in operation it will not be excessively time-consuming for any individual to maintain. Also note that it is fine to begin with very rough data, since the process provides feedback to refine capacity estimates over time. Fortunately, even poor accuracy in this process is better than not having any fact- based methodology for capacity management. A “Hoshin-like” Capacity Management System Let’s take it from the top (of Figure 2, that is). The process begins with a global priority list of projects from all sources within your firm, divided into the A / B / C categories described above. As each A or B project progresses, the project team leader (with help from functional management, if necessary) develops a calendarized initial plan for resource requirements, by function and month. Although this initial plan may be crude, it forms the starting point for a continuously updated, monthly planning activity. This information is fed in two directions: it is provided to the “strategic” committee for future capacity planning purposes, and it is provided to each functional manager to enable real-time capacity management. Note that the update periods shown in Figure 2 are just recommendations, but the functional areas should be reassessing (and potentially reassigning) resource capacity on a monthly basis, using a simple spreadsheet tool as a means to allocate their resources, as individuals with unique skills. Note that the functional managers must include in their plans any drains on resource availability from sustaining operations, and only allocate resource hours based on realistic availability to development projects. Initially, the capacity demands due to sustaining support may be rough estimates, but over time these estimates will become more accurate as feedback is provided from visual project boards (described below). Two simple rules apply to the allocation of resources in each functional area: 1) No development resource is allocated to more than two major projects, or three minor projects, in any monthly period. This is critical to maintaining focus on A Projects, and avoiding the waste and turbulence associated with an individual having too many projects. Among these project assignments, there should always be clear understanding of which projects can slip, if necessary, to ensure that “A” projects always meet their schedules. 2) No development resource is allocated beyond 100 % of their realistically available capacity. Each month, the project team leaders will provide updated estimates of their resource needs to the functional managers. If there is ever a resource shortfall, the A Projects always get their needed resources first. If all A Projects cannot be satisfied, this should immediately raise a flag, and if the situation is serious enough, should trigger action by upper management to resolve the conflict. Based on the monthly assignments of individuals by functional managers, project teams will meet on a frequent basis to hold “stand-up meetings” in front of visual project boards. The output of these workflow management meetings is a continuously updated understanding of project status, progress, and future resource needs. Hence the loop can now close. As projects proceed, team leaders will determine if their staffing levels are adequate, and will use that understanding to update their monthly resource requests as their projects move forward. Functional managers will update their understanding of resource availability as better data on both project and sustaining support demands are understood. Ultimately, the strategic management team will update their high-level capacity model to incorporate this feedback, and so it goes. If this process seems complex, then you should begin slowly, perhaps only focusing on functional areas that are known to be critical to project 3
  4. 4. “G lo b a l” P ro je c t P rio rity L is t (A / B / C ) (U p d a te d o n 3 m o . R o llin g W in d o w ) P ro je c t T e a m s C o n d u c t P ro je c t P la n n in g / R is k M it. E v e n ts (O u tp u t: In itia l R e s o u rc e P la n s ) 1 2 M o n th C a p a c ity P la n b y F u n c tio n a n d M o n th (U p d a te d o n P ro je c t 1 – C a le n d a riz e d R e s o u rc e 3 m o . R o llin g W in d o w ) R e q u ire m e n ts b y M o n th a n d F u n c tio n P ro je c t 2 – C a le n d a riz e d R e s o u rc e F e e d b a c k to P ro je c t T e a m s R e q u ire m e n ts b y M o n th a n d F u n c tio n o n A v a ila b le C a p a c ity a n d W o rk P ro g re s s P ro je c t 3 – C a le n d a riz e d R e s o u rc e R e q u ire m e n ts b y M o n th a n d F u n c tio n M u lti-P ro je c t B d . fo r S m a lle r P ro j. Naresh Cassie Priority Renee Cathy Harry Nada Dave John P r o je c t L is t Jane Thor Fred Sara Dick Tom Ron Sue Tim Liz (C u rr e n t & P la n n e d ) U n p la n n e d A A v a i la b le H o u rs * W id g e t 1 . 3 8 0 1 2 0 1 2 0 1 6 0 1 2 0 1 60 1 6 0 1 6 0 1 4 0 8 0 1 2 0 1 2 0 1 6 0 1 2 0 1 6 0 1 6 0 1 6 0 1 4 0 40 80 160 40 80 160 A T h in g a m a jig A 3 60 120 40 80 120 40 S u s ta in in g A D o hicky U pd ate 80 40 100 100 40 60 S ta n d -u p M e e tin g s / A W h a t c h a m a c a llit 40 80 40 100 S u p p o rt / B B W id g e t 1 . 4 T h in g a m a jig B 6 40 20 40 120 20 40 20 40 120 40 P ro je c t B o a rd s B M in i -D o h i c k y 40 40 O th e r D ra in s C C B l u e s k y 6 .0 D r e a m 1 .0 C o n C a p a c ity C W is h 1 .0 P ra y e r 1 .0 S u s t a in in g S u p p o r t 20 20 20 C u s to m e r S u p p o rt 20 20 20 O th e r? ? ? 20 20 M o n th ly R e s o u rc e P la n b y F u n c tio n a l A re a S in g le P ro je c t B d . fo r L a rg e P ro j. Figure 2: An integrated system for product development project prioritization, capacity management and project workflow management. schedule, and on projects that are “tent-poles”. As the system begins to function, additional depth can be added until all projects and all resources critical to new product development are included in the process. Visual Project Boards / Stand-up Meetings Basically, the visual project board is a central repository of information required for a team to plan and execute their daily work. There are several types of visual project boards, and although the specifics are slightly different, they all follow the same general format and are intended to accomplish the same purpose. In all cases, the visual project board has, at its core, a task-tracking tool referred to as a “Wall Gantt”. This simple tool allows real-time tracking and allocation of resources, and has the flexibility to accommodate rapidly changing demands and unexpected tasks. Other information is typically included on a project board, including high-level status, project schedules, problem-solving initiatives, risk mitigation strategies, and so on. Regardless of the format, the boards are highly interactive, and are the focus of frequent (ranging from three times per week to daily) stand-up meetings. The stand-up meeting is a short duration (typically less than 15 minutes), high energy forum for updating the Wall Gantt, and as necessary, the other higher-level tracking tools on the project board. Unplanned work (e.g., sustaining support) is captured on the project board along with planned project work, such that all demands on team members’ time are accounted for. * * * Thus, we have a system for tracking, managing, planning, and optimizing the utilization of project resources, from the highest strategic level, to the day-to-day activities of team members and support personnel. As challenging as implementation of this system might seem, this methodology can provide a sustainable competitive advantage to any firm by maximizing the output of new products, ensuring that the most critical projects are completed on schedule, and allowing accurate future planning for growth. For more information on our practical and integrated approach to lean product development implementation, please contact us at 818-366-7488 or by e-mail at techper@att.net, or visit our website at www.Design-for-Lean.com. 4