notebook

Measuring maturity

Many of our clients measure how well teams have adopted the FTTM Planning Method. We’ve seen many different assessment systems. 

We’ve developed a common and reusable metric by which teams can assess and track their growth or “maturity" in using the methodology on multiple projects. Clients that use this system are typically running FTTM on tens if not hundreds of concurrent projects. 

But lets not forget, the goal is to accelerate projects and finish them on or before schedule, per customer requirements. Matturity Level (ML) is less important than actual project performance. However, we have found teams that have achieved Maturity Level 3 (ML3) are most likely also those teams finishing fast.

These (above) are the process maturity learning cycles teams migrate through over time. They are serial and a team can’t jump a step. Starting with ML0; which indicates no use of FTTM methods. A team can achieve ML1 in 2-3 weeks, if they are focused and committed, while ML2 and ML3 are much harder to achieve and take significantly longer to realize. Over time, the idea is to get a team independently (i.e. without outside help)  accelerating the schedule and continually improving their skills and methods.

Using a best practice framework to assess organizational effectiveness

View quicktime animation

We developed this multidimensional best practice framework to assess new product development organizations. The model is divided into host issues (i.e. the infrastructure above and around the team) and those that impact the team.

We look at the problem in four categories; systems, knowledge/skills, motivation, and resources. All four of these areas need to be considered to improve organizational effectiveness.

The delivery system is necessary but not sufficient without addressing skills, motivation, and resources. We often see management focusing on "motivation problems" in order to fix performance issues. We find that these are symptoms of the problems that originate when teams lack the delivery system, skills, and sufficient resources to be effective.

Example of a team assessment map

View full question set in a mindmap format (PDF)

What happens when the expected outcome is not being realized? When a development program fails to meet the time, cost, or specification targets set for it by your customer? How do you evaluate the root cause(s) of the problem(s)?

We developed a mindmap of discovery topics. This tool evolved over hundreds of project investigations around the world. This provides a framework for our analysis. It also serves as an excellent tool for facilitating group discussion in order to determine root causes and improvement action plans.

When we look at a new product development program we attempt to analyze the complete picture (above). Here is a down-loadable example (PDF) of what one of these maps looks with actual data gathered from a program team. The information was generated by our colleague Sigi Hart, through a series of interviews he conducted with program team members (company and product names are removed for confidentiality).

Links | Mindmanager software (used to create mindmaps) | ASSESSING A PROJECT TEAM AGAINST BEST PRACTICES 

Assessing a project team against best practices

Download project assessment map (pdf)

We assess teams prior to engaging. It is important to define the boundaries of the problem and understand root causes or barriers to fast cycle time.

This is a typical assessment map that we use during the interview process with selected team members and executives involved with product development.

Additionally, we use npdCalc to understand the project economics and scheduleAnalyzer to analyze project schedules against our best practice model. These tools combine with 1:1 interviews to form the basis of information about potential problems and guide possible solution paths. Through this process we are trying to understand the reasons for the gap between the best practice framework and the desired performance.

Links

cpmAnalyzer: analyze your critical path using a best-practice metric 

What does being late to market cost you? 

scheduleAnalyzer: Analyze your schedule for best practices

scheduleAnalyzer: ranking best practice

If I only had 5-minutes, what would I want to know about your new product development project

Fast autonomous teams

View quicktime animation of slide

What type of development team structure are you using now? Functional or Autonomous or somewhere in between?

We first came in contact with Steven C. Wheelwright's work (Harvard Business School) at Sun Microsystems and Quantum (the disk drive company) in the mid 1990's while doing our first best practice project.

He consulted to both CEOs on the establishment of fast time to market processes. We studied the results of this work with very fast teams at both companies. He had a great impact on both company cultures. Scott McNealy, Sun's CEO at the time was a student of Wheelwright's from HBS and implemented most of his ideas. The result was great success in the engineering workstation segment, pushing DEC, HP and IBM out of this segment.

"I already have a schedule, what's so different about your schedule?"

View complete list

A schedule is a schedule is a schedule, or is it?

In another posting this week "Looks like generic project management, what's so different?" I listed six factors that differentiated fast teams from what we called "normal" or typical teams.

Based on hundreds of project experiences we have learned that these six factors really set those fast teams apart from other teams that are less successful vis-a-vis meeting their schedule commitment.

In that same posting I placed a detailed comparison of "best" and "normal." However, here are just those six factors a "best" and "norm" comparison. We've found that contrasting this way helps readers to grasp the best practices. Of course I have exaggerated to prove the point with those "normal" teams, but they are really not that far off from what we continue to observe in both large and small organizations. 

Pull-in the schedule before it slips and "bank" the time

View animation of moving up the process maturity curve --- levels of schedule pull-in maturity (i.e. pulling-in the schedule before it slips)

Pull-in Concept

You need to pull-in the schedule just to be able to meet the schedule. This is called "time banking." You accelerate to gain time now, since you know unexpected things will happen in the future where you will need to use that banked time (i.e. loose that saved time). What is certain is uncertainty!

When we say, "Accelerate the schedule," we are trying to hit the committed target date "on time." So you need to pull-in all the time, just to be on time. We are always trying to accelerate the schedule, regardless of being late or early. The larger discussion though is, "Should the committed target dates be accelerated?" This is real schedule acceleration. This thinking is characteristic of the best practice-fast teams. They were always trying to accelerate, they would accelerate even if they were not yet late, since they knew that they would need that "banked" time in the future.

Looks like generic project management, what's so different?

We recently sat with an executive team starting a new venture. The CEO challenged me to explain why our FTTM (fast time to market) approach was different from traditional project management practices. He said "we already have a schedule, what's so different about your schedule?"

My answer was marginal at best. I knew I needed a better answer. He made me think more about the differences between "normal" teams and the really fast teams we've worked with over the years. We know that fast teams:

1. Get full team involvement in planning and tracking their project (process description)

2. Plan near-term detail and long term macro (start with top down macro plan)

3. Do daily refresh planning (update, breakdown, pull-in) -- with complete team

4. Use the schedule was the driver, not just a reporting tool

5. Make schedules that are real, show the gap between target date and the "real" end date, and use the gap to create urgency early rather than later

6. Track schedule trends so they can see if they are moving towards or away form the target date, this creates before-the-fact behavior

cpmAnalyzer: analyze your critical path using a best-practice metric

We've added a cpmAnalyzer to the current release of fastProject.

This tool generates a chart (Excel) of your .mpp project file showing the rate of completion of activities if you worked to the early schedule (Grey line) and the rate of completion of activities if you worked to the late schedule (yellow line). The green line indicates completed activities.

Best practice (i.e. fast) schedules typically have about 50% of the activities on the critical path and about 10% delta between early and late schedules, i.e. the maximum difference between the rate of completion of remaining activities on the early and late schedules should not exceed 10%. The greater the delta (gap) between the early and late schedules the more time activities have to float. When activities have a lot of float time people tend to work on the late schedule and typically do not finish in time which then slips the schedule.

What is your freedom to act?

Recently a client proposed a new idea to the CEO. The CEO pushed back. We looked into why. We found that our client tried to get the CEO's "buy-in" rather than taking action.

Getting everyone's "buy-in" takes time and tends to force all decisions up the hierarchy. Eventually, senior managers complain that their people "don't take initiative and just make things happen, rather they wait to be told what to do." The inefficiencies in this model are enormous and expensive.