Every project manager can construct a good project schedule. Great project managers can take that same body of work and deliver it more quickly without reducing scope or compromising quality. The great PMs can cut 10%-25% from a schedule by understanding how teams work and where there are opportunities within the project plan itself.
Parkinson's Law states, “Work expands to meet the time available for its completion." The project corollary is that tasks are not completed before their planned finish date.
Project planning has deep roots in engineering principles. Henry Gantt (developer of the Gantt Chart) worked with Frederick Taylor on his scientific methods of management. The United States military contributed to the project planning canon with the Critical Path Method (CPM), developed for the Manhattan Project, and the PERT chart which came from the Navy’s nuclear program. Consequently, the project schedule—with its work breakdown structure, dependency mapping, and resource leveling—creates a false sense of engineering-like precision.
Once, I was on a team developing a new data warehouse. Before the project started a 'master scheduler' was hired. He developed a thousand-line, 3-year project plan. Like most large projects, we got off to a slow start. After the first month he was reporting that we were 3 weeks behind for the final deployment. The project radically changed direction several times and that original plan became a running joke.
Project plans are great tools that should reflect the best working intentions of the team. An experienced project manager can help the team uncover opportunities to save time by correctly ordering tasks, removing false dependencies, and finding real slack in the schedule.
Here are four easy ways to reduce the duration of the project and improve time-to-market without compromising quality or scope:
1. Establish Scope Before the Project Starts
Clearly establishing scope before the project team is assembled reduces non-productive time at the beginning of the project. In well-disciplined organizations, the project scope, high-level requirements, general design, and level of effort are understood before the full team begins work. This way, the full team is productive from the first day.
At MCI, we established a continuous development process. All of the applications in the sales-to-billing value chain had coordinated quarterly releases. As the project teams were working on one release, the requirements, general design, and level of effort for the next release were being created. As a result, when the project 'started' the team was ready to begin work.
2. Eliminate False Dependencies
Every task on a project plan must have a predecessor and successor. Dependencies are most often expressed as hard, finish-to-start predecessors. In other words, the first task must complete before the second can begin. In reality, much work is conducted in parallel and can be expressed as finish-to-finish or lagged finish-to-start tasks.
For waterfall software projects, hard dependencies generally lie between the project phases. Requirements must be approved before design begins, design must be complete before coding begins, and so on. If the dependencies are documented to reflect the real overlap of work, days and sometimes weeks can be found in the schedule without any impact on execution.
My experience is in software project management. I always thought that construction projects would be constrained by the physical realities of building. When I put an addition on our house, I learned that subcontractor availability drove sequencing and that the kitchen cabinets were on the critical path for completing the entire project.
3. Develop a Comprehensive Testing Strategy
Very large, complex programs often conduct multiple testing phases: system testing, user testing, integrated system testing, integrated user acceptance testing, and sometimes business operational testing (operational dry runs). When you are executing a project of this magnitude, testing can consume the majority of the time and effort.
When you lead one of these projects, develop a comprehensive, integrated testing strategy early. The goal of the strategy is to ensure that there are no gaps or overlaps. In other words, does each testing phase exercise functionality that was not tested in a prior phase? Or, is there functionality that is not being tested?
4. Shave Days
When you manage long projects, you cheat Parkinson’s Law by shaving days from the longer tasks/phases. Task and phase durations are usually estimated in round-lot increments—two weeks, one month, etc. You can reduce the overall duration challenging the rough estimate tasks. See if your team can reduce two-week tasks by a day, 4-week phases by 2 days, etc. In most software projects, there is room in the schedule if we eliminate time-wasters.
Once, I assisted a project team that needed help reducing its schedule. The team originally developed an 11-month project plan. At that point, the sponsor asked me to work with the team to create a plan that would complete the project in 8 months. We reduced the plan to 7-1/2 months by:
- Removing false dependencies and scheduling work in parallel, creating lagged dependencies for the phase gate transitions.
- Shaving time by asking each team to identify options for reducing the duration of their longer tasks and phases.
- Streamlining the multi-phase testing process by testing earlier in lower environments and eliminating redundant testing.
By recognizing that project schedules are not rigid engineering tools but best case plans developed by people, it is possible to find opportunities to reduce the total project duration without sacrificing quality or scope.
Image courtesy of TenSix.com
© 2014 Alan Zucker