Most projects begin as a basic idea expressed through informal conversations in meeting rooms or around the water cooler: “Let’s build this Web site” or “What if we had an application that helped us do this?” These conversational projects often evolve through e-mails, handwritten notes, or ink on a whiteboard. At this point, the project is in a “shadow” existence, known only to the few people who have discussed it. These types of shadow projects are dangerous because they often take up time and energy without the rest of the organization knowing they exist.
Shadow projects evolve as the result of a number of factors, including the following:
- People want to maintain control of their ideas for credit, power, or for a sense of creative completion.
- Corporate Culture does not support the sharing of information.
- Existing project management practices do not support the capture of “early” stage projects.
- No system (software or otherwise) exists for capturing or sharing information.
IT managers who use the traditional bottom-up approach to project management run the risk of missing the development of these shadow projects. The bottom-up approach seeks to manage the project as a whole by concentrating on the tasks, resources, and work. This approach reasons that if all these factors are addressed, then the project will succeed. To a point that this is sound reasoning. But what about the shadow projects and the affect they have, or will have, on other projects? This is where a different approach, top-down planning, comes in.
Once a project is in the real planning stages and, of course, in the execution phase, the management of work with bottom-up planning is essential. However, this approach does nothing to address the project and its life before specific tasks are assigned. This is where top-down management comes into play—before the project is even a project by the definition of the bottom-up approach.
The top-down approach seeks to gather information about the project as soon as possible after the idea has been developed enough to put a name and maybe a few estimates of dates or cost on the project idea. This initial information acts as the birth record of the project. But the real value of top-down planning comes because you are able to share the idea for the project with the entire organization. Other project managers are informed of what might be on the horizon, and the whole organization gets a clearer understanding of what it is doing. Often, large amounts of work get done on projects that, by the company’s definition and tools, are not even projects. These projects don’t show up on management’s radar. If an organization’s management team is aware of all of its projects and project ideas, then more intelligent decisions can be made concerning where to put resources.
Top-down planning: A case in point
Let’s use an example of top-down planning to illustrate our point. At a meeting of managers it is decided that there should be a new section of the company’s intranet to give workers information about a new benefits package. The managers discuss the rough outlines of what should be covered and assign the project to Steve in the IT group.
Steve’s group has a method for tracking the projects they are working on. It starts with a simple spreadsheet that tracks “Top Down” information about each project. It captures the name and a brief description. It also has things like any dates or deadlines that might have been discussed, the name of the person or group that “owns” the project, the name of the executive sponsor, etc. This spreadsheet is the heart of the group’s project-based body of work. It is the first place anyone looks when a project is being considered.
Steve gets back to his desk from the meeting about the intranet and opens the spreadsheet. He scans the list of projects that are already in progress in his group and finds that a project related to the company intranet is already under way. He contacts the person in charge of that project and finds that, while this project is related to the intranet, it is not dealing with benefits programs. Steve does determine, however, that the project in progress does change all the formatting and layout of the intranet. He gets copies of the new templates so that the benefits site will already be ready for the new formatting.
He enters the information about this new project into the spreadsheet. At this point, anyone else in the group can see that Steve is working on a Web site about benefits. This information will save time and help other employees avoid duplication of efforts if they are charged with launching a similar project.
Steve then proceeds to plan, track, and manage the project using the PM tool of his choice, in this case MS Project. He can update the spreadsheet as time goes on, giving the team a high-level view of the plan.
No project too small
Another area where top-down planning has value is very small projects. Most organizations have unwritten rules about when something requires a project plan. It generally depends on the project’s size, either measured in number of tasks or in duration. Some people do not feel that it is worth creating a plan for a project that lasts less than about two weeks or has fewer than 25 or so tasks. The result is that not only do small projects get no respect, but they also get no visibility to the rest of the world. This can affect the way the organization works.
If work is being done and it is not captured because it is “too small,” then how does an organization know where work is being done? How do you manage your resource availability if time is being spent on these small projects? Another aspect to consider is the psychological affect of having to work on a project or a number of projects that are not “important enough” to even record. Working on a project so small that it doesn’t have a name and is not even documented can be disappointing. Nobody likes to have his or her work hidden from view of peers and management.
Bottom-up planning is critical once a project reaches the stage where you must detail a complex set of tasks, resources, and work.
But all projects should be initiated using the top-down method, capturing details even if they are still sketchy. Maybe all you have at the beginning is a name and a brief description of project goals. Capture it and put it on the company radar where everyone can see it. Then, as you put more thought into the project, capture more data and move to the bottom-up approach.
Do you employ top-down planning?