Bob Biddinger used to speak about the, "Footprints in the sands of time." Or as Bob would to say, "There aren't any when it comes to real sustained change in organizations. The next tide will just wash them out." Why I wondered?
We developed this model to illustrate the things that need to be affected in order to create change, where there are still "footprints in the sand" months and years after an improvement intervention is implemented.
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.
Continue reading "Using a best practice framework to assess organizational effectiveness" »
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
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
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.
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 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.
Continue reading "Pull-in the schedule before it slips and "bank" the time" »
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.
Continue reading "cpmAnalyzer: analyze your critical path using a best-practice metric" »
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.
