There is not necessarily sequential order between defining (planning) the project and building the schedule and budget. That is, you do not have to completely define the work first and then build the schedule and budget second. Some of the sections of the Project Charter, such as the estimates for cost and duration, cannot be completed without starting to lay out the overall project schedule.
At the same time, you cannot complete the schedule without gaining agreement on the Project Charter. For instance, you cannot build the schedule and budget without gaining a high-level agreement on deliverables and scope.
To a certain extent, defining the work and building the schedule and budget need to be done simultaneously. The main deliverables, the Project Charter, schedule and budget, should also be developed in parallel. You will find that as you gather information about scope and deliverables, you can start laying out a high-level schedule. As you gather more information about the work, you can fill in more details on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information to complete a high-level schedule. You can then use the high-level schedule to estimate the necessary budget – which in turn are used to complete the Project Charter.
Break Large Projects into Smaller Pieces
The days of the mega-project are over. Very large projects are simply too difficult to manage and execute successfully. There are a number of problems with very large projects:
The work is less clear the farther out in the future it is. Large projects are usually always long projects as well and that makes them very difficult to plan successfully.
Since the future work is less clear, it is harder to make accurate estimates for effort, duration and cost.
Business and technical conditions change over time, making planning assumptions in the future very uncertain. The business and technical certainties of today can change dramatically over time.
You risk losing organization support if there is a long delay before delivering tangible results. It is very difficult to maintain organizational enthusiasm and support over long periods of time.
It is very difficult to predict resource requirements and availability far into the future. Again, this gets at the difficulty of estimating accurately as you get further out in the future.
Very large efforts are much too difficult and complex to manage as a single project. The better technique is to break the work down into more manageable chunks, each of which is considered its own project, with its own Project Charter and schedule.
For instance, a long IT development effort can be broken into separate sequential projects based on the life cycle. A project is set up for the analysis work. Toward the end of that project a second project is established, based on what you know then, to do the design work. Then a construct / test project is initiated, and finally a project for implementation. Other large initiatives might be broken up into smaller projects that might run in parallel, or a combination of sequential and parallel projects. Each team will complete its smaller project, but all the work would be coordinated so that the entire effort is successful.
Set up a Program to Coordinate a Set of Related Projects
If you break a large effort into a number of related projects, there may still be a need to maintain overall management and coordination. This is the purpose of setting up a ‘program’. A program is the umbrella structure established to manage a series of related projects that are all trying to achieve a common set of objectives. The program is lead by a program manager. The program does not produce any project deliverables itself; the project teams produce them all. The purpose of the program is to:
Provide overall direction, guidance and leadership for the projects
Make sure the related projects are communicating effectively
Provide a central point of contact and focus for the client and the project teams
Determine how individual projects should be defined to ensure all the work gets completed successfully
Some people think that programs are simply large projects, but they are more than that. Programs are a way to organize work, and they have a different set of work processes than projects.
Make Sure Everyone Understands Project Roles and Responsibilities
For small projects, the organization is pretty simple – maybe just the project manager and the sponsor. The person who is managing the project may be the only person actually working on the project.
However, for large projects, there may end up being an elaborate and formal organizational structure. You may have team members, an executive sponsor, a project sponsor, a client manager, a project director, a steering committee, vendors, clients, and others involved. You do not want to get overly complex, but the more people that are involved in the project the more important it is that everyone be clear on what his roles and responsibilities are. For example, the last thing you want is to have someone give you direction as if he were the sponsor when really he may just be a management stakeholder.
One aspect of defining the project is to define the organization structure and the roles and responsibilities of all the major participants. The typical roles and responsibilities can be defined ahead of time for your organization and then reused as appropriate from project to project.
Tenstep