Herding Cats – 7 Deadly Sins of Project Scheduling

Kiron D. Bondale posted about the Seven Deadly Sins of project scheduling. After you read this very useful post here’s my experience of putting this advice to work in ways you’d see if you were on the site of one of our defense programs.

1. Scheduling Tools are necessary but not sufficient – we use MindJet to capture the Work Breakdown Structure (WBS), the Integrated Master Plan (IMP), and the Work Packages under the IMP’s Accomplishment Criteria. The structure of the IMP/IMS can be seenhere. The WBS is similar. The great thing about MindManager, is the “export to Project” button. Once you get close to what you want, just export the map to Project and continue working. When the WPs are sequenced, this is called the Integrated Master Schedule (IMS). The details inside the WPs are supplemental schedules held by the WP Manager. In other domains there are Tasks under the Accomplishment Criteria.
2. Scheduling constraints are forbidden in any credible schedule. Just don’t use them, period. The only constraint should be Must Start On (MSO) for the milestone titled “Authorization to Proceed” (ATP). All other constraints are As Soon As Possible. You should avoid like the plague leads and lags. In some of our defense domains (NAVAIR, the Navy’s aviation division) not leads or lags are allowed longer than 5 days. On a large program 5 days is the same as zero days. If you need leads or lags, make a “holding task,” label it as a “holding task,” and put it between the two tasks you want to lead or lag.
3. Automated resource leveling is an oxymoron, used by morons. Do not let a machine do your work for you. Touch every resource issue. Confirm the resources are what you need, their availability and what they are capable of doing. In some organizations there is a separate “resource management planning tool. Use it. NEVER let MSFT Project do this, it simply screws uop the entire IMS. This is a transition to the topic of Work Packages (WP). WP’s are resource loaded but resource leveled. The WP manager figures out how many people she needs over what period of time. Then looks after assigning them work inside that period of performance.
4. Too Many Tasks – use Work Packages to collect detailed work. In formal scheduling domains, changes to the schedule go through change control. There is no way anyone can know what work is going to be done at the detailed level in 6 months. Or even in 2 months, let alone 18 months. Work Packages collect these tasks and the assigned staff and define a period of performance, the tangible outcomes of the work effort. the WP manager looks after the details. Put the WP in the schedule as a “task.” For future work create a Planning Package (PP), with a period of performance, forecast resource loads. This WP and PP is the standard in the US DoD Earned Value Management approach. Don’t let anyone talk you out of this. Make thew WP manager accountable. The PM can then see physical progress without all the gory details of tasks. Push responsibility down. Make the PM accountable.
5. Out of Date Schedules - if you don’t status your schedules every week, you should look for a new job. On large – I mean billions of $’s manned spaceflight programs – we status the schedule every Thursday afternoon in preparation for the “stand up” meeting on Monday to answer the question “what have you done for me lately?”
6. Outline Levels – match the structure of the Work Packages that sit at the bottom of the Integrated Master Schedule (IMS), shown in the notional picture here. The construction of the IMP/IMS is more subtle that a narrow bandwidth blog can deal with. But, the indent structure of the IMS should only go to level 5 – Program Event or Major Milestone, Significant Accomplishment, Accomplishment Criteria, Work Package or Planning Package, and maybe a sub-WP. Details are in the Work Package. The WP can be no longer than 60 calendar days for big projects.
7. Starting Over – once the Performance Measurement Baseline is “set,” making changes means a change control process. The way out of a continuous change process is to use Rolling Waves. Planning Packages are in the the “out years,” Work Packages in the current (active) Rolling Wave. Future Rolling Waves contain the remaining budget, define the future deliverables at a macro level and always have a critical path through them to the end of the project. But the details are defined yet. So as the requirements emerge (become definitized as we say), then the actual contents of the Planning Packages in the future Rolling Waves also becomes definitized. What this avoids is having to replan the work that never should have been planned in detail in the first place.