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.
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 Gant (Gant Chart) worked with Frederick Taylor on his scientific methods of management. The United States military contributed to the project planning cannon 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:
Establish Scope Before the Project Starts
Contents
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.
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, etc. If the dependencies are documented to reflect the real overlap of work, then days and sometimes weeks can be found in the schedule without any execution impact.
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 sub-contractor availability drove sequencing. The kitchen cabinets were on the cortical path for completing the entire project.
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?
Shave Days
When you manage long projects, you can reduce time on the overall project duration by shaving days off of the longer tasks/phases. Task and phase durations are usually estimated in round-lot increments—two weeks, one month, etc.
To reduce the total duration, ask the team to reduce the estimated time of their rough estimate tasks. For example, reduce two-week tasks by a day, 4-week phases by 2 days, etc. Sometimes there will be small overruns. But this strategy lets us cheat Parkinson’s Law.
Once, I assisted a project team that needed help reducing its schedule. The team originally developed an 11-month project plan. At this point, the sponsor asked me to work with the team to create a plan that would support a year-end implementation—less than 8 months away. 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. Each team was asked to reduce the duration of any task that exceeded a week.
- 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.
© 2014, Project Management Essentials