Greater task granularity takes a little more work, but it’s worth it.
Enables better estimates of work units. It’s a lot easier to get accurate estimates with a bottoms-up approach.
Uncovers hidden tasks. As always, the devil is in the details. In the development phase our high level plan often includes ordering/receiving a boatload of new components for our new design. A traditional high level plan assumes first article inspection happens automatically. Inevitably, new part volume overwhelms incoming inspection resources, and engineers become frustrated waiting for their parts. The project manager is pressed into service as the inspection-backlog-prioritization manager. Wouldn’t it be better to recognize the need for first article inspection explicitly in the project plan, and plan to put the resources in place to handle the activities.
Facilitates divide-and-conquer project execution. Granularity enables multiple team members to tackle different parts of an activity in parallel. Instead of “Perform kink test” being handed off to one person, we might have one person writing the protocol and test method while someone else designs and builds the test fixture.
Enables analysis of skill types. Granular plans may surprise you. You might be surprised by the number of fixtures to be designed or the number of prototype samples to be built, indicating that the project team might need a full time test engineer or assembly technician. This is really hard to see (and really hard to justify to management) with from a high level plan.
Granular gantt charts become quagmires of dependencies, and have fostered our fear of granularity. Project planning has always been a second-class citizen in the development process too, so too little time is allocated to develop clear, granular plans. Granular Critical Action Plans elevate project plans to their true importance and unveil the complexity of projects instead. We wouldn’t be too happy if someone said that our mechanical drawings “don’t need to get down to the details” and that our part is specified to be “a couple of inches long.” We wouldn’t be happy if our software code “doesn’t need to get down into the details” and didn’t detail out all of the error conditions that might occur. Why should we be happy with high-level project plans that mask the complexity and capacity-requirements of our projects?