How to Separate your Project into Manageable Chunks

Splitting your project into smaller parts or pieces that are more controllable helps you to move closer to your ultimate goal of achieving your project deliverables and high user satisfaction. Planning your project thoroughly means thinking of different ways to break your project down into smaller, more manageable chunks of time and work. This, in turn, allows you to have more direct control and, of course, increases your chances of success. Let’s look together at the different areas that can be split out.

 

Accounting it out

Work packages represent necessary work units that need to be completed to finish a project. To have good work package (WP) estimation, it is important for Project Managers and users to know which costs are direct costs and which are indirect costs. This distinction allows a PM to track what is within his control and what is not. A PM is usually held accountable for the “entire” cost, when, in actuality, most indirect costs are beyond the control of the PM. Indirect costs are often combined in various cost pools referred to as overhead. These types of costs could include enterprise machinery, plant, and other indirect expenses associated with the organizational support of the project. These costs are usually allocated (or time-based charges) at the project and/or activity level on a percentage basis with no real explanation.

 

Borrowing it out

Starting out with a blank project plan in Microsoft Project is a daunting task, and the last thing you want to do is start from scratch. You don’t have to reinvent the wheel. Borrow ideas from other PMs and/or similar project plans when developing your work breakdown structure (WBS). This will save you time and add value to your overall project. PMI, Microsoft, and Microsoft Project User Groups, like MPUG, provide many resources and/or online project templates you can use. Consider reusing templates from previous projects from within your organization, too. For example, I was once responsible for annual Disaster Recovery (DR) tests for a global services company I worked for. In the beginning, I developed a standard project plan in Microsoft Project with the help of experienced resources. I then used the plan as a template. It included WBS predecessors and durations. Each time I started out with a new client, I updated the template with resources and dates. Doing it this way only took me about fifteen minutes each time I added a client. When the next year rolled around, I took the previous plan for the same client, updated the dates, and contacted the resources to see if they were still available. The annual update only took me about five minutes.

 

Breaking it out

To improve control and bring in faster benefits, project cycles and phases are best kept as small as possible. After 12 to 18 months, requirements tend to shift, the overall control of the project becomes more difficult, and a PM will likely be spending more time just monitoring a project. Furthermore, it is more difficult to keep a team properly focused on the correct work after a year, and there is a high probability of team turnover. In other cases, success can be decreased because of advances in the technical environment, or other projects might take on a higher priority (which means your project could be temporarily frozen). If a project runs longer than 12 to 18 months, it is prudent to consider how it could be broken down into defined subsets (for example, phases, state gates, or multiple projects), so that the individual parts can be implemented more rapidly.

 

Buffering it out

No plan ever runs according to schedule, and some tasks will come in late, so you will need some wiggle or breathing room. A good idea is to add a buffer task at the end of “selected” phases (for example, limited or no experience users learning new technology). Alternatively, in a case like this, you could manually extend a summary end date for a particular phase by 20% from its’ original duration. If the original phase duration is 100 days, manually extend it to 120 days. If you find out you didn’t need this entire buffer for a major phase, you can always reduce the duration time of the buffer to get an accurate project completion date. Finally, if you find out you defined a buffer task at the end of a major phase and didn’t need it at all, you could delete it or inactivate it (Inactivation removes values from your rolled up schedule). In this situation, I would recommend inactivating the task for historical reasons. Of course, you could always reactivate the buffer task later, if needed.

 

Compressing it out

The requirement to shorten a project schedule or critical path is a shared occurrence, and the following are two common practices for doing this:

• Crashing is the process of adding more resources to a critical task to shorten the time needed to finish a project. This has the impact of adding costs to the task for faster delivery. Keep in mind that adding too many resources can actually slow the task down (for example, getting up to speed, resources getting in each other’s way, training and/or more materials required).
• Fast tracking involves doing activities in parallel that you would normally do in sequence to shorten the overall schedule. Even though this appears to be a cost-free option, a PM must be careful in doing this because it could turn a critical task into a non-critical task and create new critical path(s) and/or increase the risk of redoing the work resulting in a new estimated completion date.

Another approach to “compressing” a project’s schedule is to reduce the scope of the project, which will shorten the length of it. Keep in mind that users and stakeholders must buy into this, and they might not be happy with the end results. Splitting long tasks into several shorter ones can sometimes reduce a schedule. In this case, the subtasks could be assigned to several people that can work in tandem.

 

Owning it out

If you see a play and the first act shows a servant with two masters that own guns, you know by the third act that someone is likely to be killed. Likewise, a project plan is made up of an aggregate of WPs (approximately 8 – 80 hours or up to two weeks in duration) that should have only one performing organization owner with an assigned owner per WP. If you have two or more performing organization owners for the same WP, you are opening the door for finger pointing if something goes wrong with executing the WP, especially if the tasks are on the critical path. In this case, the WP should be broken down into at least two WPs to represent the individual performing organizations.

 

Summary

Following these tips for breaking things down should improve any PMs credibility, performance, and chances of success. Remember, when decomposing your project down into WPs, don’t allow gaps or overlaps. By allowing no overlap, you are identifying all components of the deliverable you are decomposing. Furthermore, you don’t include the same sub-product in your decomposing of two or more deliverables. I’ll be sharing more ways to separate your projects into management chunks in Part 2 of my article.