Size Matters

The size of the project, the size of the team, the size of the deliverables, and the size of the checklists - everything in a project depends on its SIZE. Size changes the rules of how the game is played.

The bigger the project gets (in size or complexity), the more important it becomes for a project manager to break down the project into manageable modules and share the delivery responsibility of these modules with capable people. This will ensure that key project members, including the Project Manager, can see the “big picture” without getting lost in the details while scouting for project health statistics.

Distributed projects usually tend to be bigger in size than other projects types; hence, the tactics the Project Manager uses to manage the size actually impacts the bottom line of the project. The word “big” conjures up a variety of images. It can mean anything from eight people working for 12 months (if you are a small vendor) to hundreds of people working on annual maintenance contracts (if you are an enormous IT partner for your client).

Here are few suggestions on how to carve out the right size for the project and then make sure that everyone understands how the small parts of the puzzle can make or break the big picture.

• Break down the project into as many independent, yet manageable, work-streams as possible.
• Make sure each work-stream has at least one key contact point responsible for its delivery.
• If possible, try to have key members play overlapping roles in these work-streams so that the “big picture” is shared across the teams.
• Track the progress (use any tool) of each work-stream separately, and tie up the metrics at regular intervals to feel the pulse of the overall project.
• Document and share the risks, issues, assumptions, and dependencies of each work-stream separately.
• Organize regular team meetings to share the status of each and every work-stream.
• Publish an overall project roadmap, including release plans from all different work-streams.
• Use online tools aggressively to share user requirements, milestone updates, bug reports, report timelines, and risks.

For example, imagine you are entrusted with building three versions of the same website (North America, Asia-Pacific, and Mid-East). You decide it is best to create three different work-streams, each with an independent delivery contact person. Since all three sites are basically the same sites in a different version (leading to medium customization) have a few key resources float across all three work streams. This way they can ensure the overall integrity of the sites and suggest re-use of implementation details.

Another example might be that you have multiple integration vendors for a single project. It might be ideal to separate out each integration point (or a related collection of them) into an individual work-streams. This will allow simultaneous channels of work and may shorten the delivery time. Involve the different teams in daily meetings to coordinate the overall quality of the delivery.