It seems odd to ask this question (Why accelerate?), since it’s obvious in the technology business that you die if you don’t release new products faster than your competition. Fast teams know this reality and communicate the “need for speed” to the engineering teams. In slow environments, this critical information is insulated from the technical teams and only reserved for marketing, finance, and leadership forums.
We advise clients to refresh their schedules twice a week (at a minimum).
Often, we observe that teams only seem to look at their schedules once a week, when they do the refresh. So increasing the frequency increases the awareness of the schedule, and time in general.
Best-in-class teams do refreshes three or more times a week. The fastest teams we’ve worked with do it every day (<15 min/session). One client recently had six teams doing it twice a day on a very time senstive program.
Refresh Planning... The weekly rhythm of refreshes is what makes them work. Team members know they are accountable to their colleagues every week at a set time. It can’t move and it can’t be postponed. And doing them more than once a week is even better, but they must be short and crisp value-added events.
The rhythm is what makes it work. It is the first regular discipline that most teams experience and it is the start of gaining control over the schedule. Late, postponed, missed meetings never help a project finish faster.
I’ll review the concepts underlying our Acceleration Workshop in this screencast.
We’ve successfully used this process to “discover” strategic schedule pull-in opportunities on complex projects. By “strategic” I mean large schedule acceleration opportunities, for example in one recent case… a 6-month pull-in on a 20 month program by using this team engagement approach. The trick is to harness the collective intelligence of a group of people in order to get them to “innovate” on the schedule, in the same way they “innovate” to create technology.
One problem when assessing a multi-project portfolio is knowing where to focus. In some cases there can be hundreds of projects in various stages of completion.
The trick is to focus on the exceptions; those projects that have the greatest gap between their expected completion date and the committed target date. In addition, we want to see those late projects who’s gap is potentially too great to close. These are the projects that are really in trouble and need help. This is where to focus finite resources if TTM is critical.
A number of clients have asked for screencasts that track with the lectures we give in our class called "Introduction to FTTM Program Management." I've collected (below) a series of posts that roughly follow the flow of the class.
FTTM is fast-time-to-market. In this screencast, I’ll discuss a project planning and tracking process, which has evolved over a 20 year period and through our work on thousands of client projects.
The foundation of this process is based on the best practices of fast teams, who we’ve been studying since the early 1990’s.
“It’s better to roughly right, than exactly wrong.” Roughly right is the philosophy of fast teams, since they know that things can be continuous improved over time. The same idea applies to their schedules, which are “a common base for change.” They are dynamic living tools that must reflect what is actually going on in the project in order to be of predictive value.
We implement this concept through continuous and frequent “low-overhead” cycles of refreshes, more on that idea later.
Refresh Planning is a core practice of fast teams. Refresh Planning involves three steps; update, break-down, and pull-in. It’s a weekly team activity. They look back in time to record what they did and didn’t get done, then decompose near-term long duration critical path tasks, and then use the more granular and detailed schedule to reconfigure the work in order to accelerate it. In order to be on time, they know they need to pull-in the schedule every week.
