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

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. 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. 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. “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