You probably arrived here because you are looking for some Microsoft Project examples. You are in the right place, but you are looking for the wrong thing. It is the right place because I have some ideas which may help you to develop a solid project plan. You are looking for the wrong thing because each project is at least partly unique and so are the people who are involved in those projects.
Project Scheduling and the Bard
Shakespeare would be disgusted to hear that I could compare a project schedule to something like King Lear. And indeed there are a number of projects which end up looking more like Waiting for Godot. It is unlikely that your schedule has the intrigue or audience appeal (unless perhaps it is Steve Batt's infamous "Purple Schedule") But the basic idea is actually rather similar.
The first task is in developing the plot. In a project schedule getting to the finished project is usually sufficient to warrant some applause, unless it has taken so long that the audience has gone home. The point here is that you need to be very clear about what it is you are undertaking and what you hope to achieve before you start working out the schedule. Defining the scope of the project is what you are after here. It must be clear to everyone involved what that goal is. The schedule you are going to put together is not going to help much if people have different interpretations about what the work is. I'd suggest that each of the major milestones along the way are also documented and more importantly discussed so that they are clear and well understood. You can modify them along the way if you need to, but unless you have the key team members in agreement and understanding about them, you will truly get nowhere.
Five Acts
Once the goals of the project are set, we can take another lesson from the stage. It is rare, and painful to sit through a single act which stretches over a couple of hours. Attention is stretched to a breaking point and it becomes difficult to understand the entire thing. So, since the time of the Greeks tragedies have been structured with 5 acts. There is no inherent limit to the phases in a project, but it is useful to have at least one major milestone periodically so that progress can be measured and more importantly as a near term goal for the people working on the project. And when they meet that goal it is time to call out the chorus and celebrate a bit.
So what sort of plan would you have at this point if you entered it into project? Actually a quite sparse one. Just a handful of milestones, but doing this work before you set into building the schedule will help you avoid problems later. The schedule is more than just a tool to account for the time spent on the project. It is a tool for communicating the plan to people who are executing the plan and to the people who are responsible for managing it. It must be clear and logical.
One of the benefits of breaking it down into phases is that working out the details of each phase is an easier task than doing the whole thing at once. Additionally, you can use a technique called "rolling wave planning" in which the near term activities are highly detailed while those later in the project (and which you may have much less visibility into) can be less detailed. As you near the end of a phase, the schedule for the upcoming phase is refined further as you gain higher certainty about it.
Plagarism
Now that you have the phases mapped out (including what you are actually going to produce or accomplish in each phase) it would seem like an example project would be helpful. You could just paste in a generic flow that you copied from somewhere. And of course you could. But there are a number of reasons not to do this. The first is that except for highly repetitive projects, there are usually some peculiarities about certain elements of the work, or site conditions that need to be taken into account, or people or materials which are not completely interchangeable. Furthermore, if you are working off of an example from somewhere you have no idea of what sorts of assumptions about productivity or dependencies were made by the original author. This is why I say that example projects are largely useless. On top of that, there is a level of understanding of the work that comes from putting the plan together. This building of a mental model and testing your assumptions gives YOU an understanding of the project which is invaluable. In years of scheduling, I have seen many large schedules being transferred from one person to another over the life of the project. In almost every case, when the schedule changes hands it goes through major remodeling as the new owner remakes it in a way which makes sense to them.
That being said, there is no reason to throw out sections of plans from previous projects.
I'll cover the rest of this analogy in later installments. Meanwhile there are refreshments in the lobby.
