SMALL BUS HOME
|
Define the Work - Techniques |
Work on the Project Definition and Project Work plan concurrently
There is not necessarily a sequential order between defining the project and building the work plan. That is, you do not have to completely define the project first and then build the work plan second. Notice that some of the sections of the Project Definition, for instance, cannot be completed without starting to lay out the overall project work plan. At the same time, you cannot complete the work plan without gaining agreement on the Project Definition. For instance, you cannot build the work plan without gaining a high-level agreement on deliverables and scope. Defining the project also involves describing an overall project approach, which is needed before the work plan can be completed.
To a certain extent, defining the project and building the work plan need to be done simultaneously. The two main deliverables, the Project Definition and project work plan, should also be developed in parallel. You will find that as you gather information around scope and deliverables, you can start laying out a high-level work plan. As you gather more information on the project, you can fill in more details on the work plan. When the deliverables, scope, assumptions and approach are complete, you should have enough information to be able to complete a high-level work plan. You can then use the high-level work plan to estimate the necessary budget, effort and duration - which in turn are used to complete the Project Definition.
Break Large Projects into Smaller Pieces
For the most part, the days of the hundred million dollar 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.
In general, 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 Definition and work plan.
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. Some large initiatives can have a combination of smaller projects - some of which must be done sequentially, but others that can be done in parallel. Each team will work to 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 down a large effort into a number of related projects, there is still 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. Each project has a full-time or part-time project manager. 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.
The Client May Not Know Enough to Completely Define the Project
Sometimes we place too high an expectation on the amount of foresight and vision that clients have. In many cases, the project manager will go to the client looking for answers to help define the project, and the client will not have all of the information needed. This happens all the time, and it does not mean that the client does not know what they are doing. In many cases, especially for large projects, the client has a vision of what the end results will be, but cannot yet articulate this into concrete deliverables. They may also not know all of the answers on scope, risks, project organization, etc.
Based on having less than complete information, the project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining.
If possible, the much better alternative is simply to break the work down into a series of smaller projects (as described above). Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, in turn lead to the information needed for the final solution. You should only define a project to cover as far as you can comfortably see today. Then define and plan subsequent projects to cover the remaining work as more details are known.
If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. Again, you plan the short-term work in more detail, and leave the longer term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more detailed level.
Project Organization - Roles and Responsibilities
For small projects, the organization is pretty simple - maybe just the project manager and the client / sponsor. The person who is managing the project may be the only person actually working on the project as well.
However, for large projects, there may end up being an elaborate and formal organisational structure. You may have team members, an executive sponsor, a project sponsor, a client manager, a project director, a steering committee, vendors, customers, 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 their roles and responsibilities are. For example, the last thing you want is to have people give you direction as if they were the sponsor, when really they may just be management stakeholders. You also don’t want people acting as team members, when really they are stakeholders.
One aspect of defining the project is to define the organization structure and what the roles and responsibilities are. Usually the typical roles and responsibilities can be defined ahead of time for your organization, and then reused as appropriate from project to project. Many of the common project roles and responsibilities are outlined in Define Work - Roles and Responsibilities.
Project Approvals
Once the project has been defined, the project manager should seek formal approval from the appropriate sponsor and management stakeholders. There are many ways to gain formal project approval. Like most other activities, a little bit of planning is the key. For small projects, one signature from the main client or Project Sponsor is probably sufficient to show approval of the work to begin. This approval could also be via email confirmation. However, it should not be verbal.
For larger projects, ask your manager and the Project Sponsor who should have explicit approval of the Project Definition, who should have implicit approval and who needs to get a copy for informational purposes only. In general, use the following approach as your starting point.
Project Sponsor and key stakeholders. Get an explicit approval. This approval can be a formal signature on a paper copy of the Project Definition. It could also be an email specifically stating approval. You might also have some type of formal workflow approval. The key is that the approval is explicit and that you save a record of the approval.
Other management stakeholders. Get an implicit approval. Implicit means that you assume they approve the Project Definition unless they get back to you otherwise. You would first send them a soft or hard copy of the Project Definition. Let them know you would like them to review the material and provide feedback if they are in agreement or if they have any concerns. Then give them a date for replying, and let them know that if you do not hear back from them before the date, you will assume they are granting their approval. If they come back to you with concerns, address them or take them to the Project Sponsor for resolution.
Other interested parties. Send them a copy of the Project Definition. Let them know that it is for their information only. You should be available to discuss any content so that they can better understand the material, but you are not sending it to them for their approval.
