All schedules are not FTTM schedules
/A schedule is a schedule is a schedule, or is it?
Based on hundreds of project experiences we have learned that specific factors set those fast teams apart from other teams that are less successful vis-a-vis meeting their schedule commitment.
Best Practice FTTM Schedules vs Normal
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:
Get full team involvement in planning and tracking their project (process description)
Plan near-term detail and long term macro (start with top down macro plan)
Do daily refresh planning (update, breakdown, pull-in) -- with complete team
Use the schedule was the driver, not just a reporting tool
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
Track schedule trends so they can see if they are moving towards or away form the target date, this creates before-the-fact behavior
We also know that slow teams don't do these six things. You see, our focus is not just to archive reliable time to market performance, but rather to greatly accelerate projects so they finish sooner.
This thinking lead to a set of questions to determine the degree to which a team had implemented FTTM thinking in their program management activity.
We ranked the questions using the scheduleAnalyzer ranking criteria with respect to the goal of those practices that contribute most to accelerating a schedule. The top six questions (i.e. the things that made the FTTM schedule process different) were:
Do you know the gap between the expected end date and the calculated end date?
Do you update your schedule multiple times each week with actual data and then attempt to pull-in the schedule to close the gap (with the team)?
Has the team been involved in developing & scrubbing the schedule, and are they bought in to the schedule (i.e. do they feel the schedule realistic)?
Has the team been (actively) involved in exploring alternatives ways of accelerating the schedule?
Is there a contiguous critical path from start to end of your schedule?
Is the schedule used as the project driver or just a reporting tool?