As the words imply, 'project initiation' simply means starting a project. The reasons for having some methodology around starting a project are as follows:
As a sponsor or project manager, ensure that you know who the project initiator is. The project initiator is the individual or group of people in your organization who has authority to authorize a new project. If you have been in your organization a long time or know it very well, then you will know who the initiator is, but if not, then ensuring that you are clear about who it is may save you much time and effort and avoid you expending effort and building the wrong relationships for getting your project signed off.
Factors affecting the means of project initiation
How the project should be initiated depends on a number of factors besides lessons from the history of project management and general best practice. There are factors that will vary from project to project. These include the following:
Figure 4.5 shows the effects of the initiating processes.
Figure 4.5. Project initiation, before and after
Understand, document and communicate planning assumptions
Assumption and limiting factors, such as time, cost or resource, must be recorded so that the project manager can manage changes in them. Write them down! A simple way to do this is in a spreadsheet or word processor document: have a simple list of what the assumption is, the date, and for each assumption the main consequences if the assumption is wrong.
Do not think that you will remember changes in key assumptions. And even if you do, no one else will, if their interests and status are threatened by the fact that there has been a change. Write down the assumptions, and show the sponsor. In a large project or a bureaucratic organization, get the assumptions signed off. In the early stages of a project, that is in the initiation stage, it is not uncommon for assumptions about cost and scope factors to change significantly as a better understanding of them evolves. This is normal, but by writing down the assumptions, even if there is consensus that they are merely 'strawman' and are almost certainly wrong, you will protect yourself from being blamed for senior management not realizing that what started as 20,000 for a database is not 2,000,000. More positively than protecting yourself, sufficient a reason though it is, you will be helping key people to develop their understanding of the issues in the project, and quite possibly some key strategic issues facing the organization.
By documenting assumptions and factors early on, the nature of the project can be understood better by all involved. For example, if a project assumes that there will be six experienced middle managers available to join it next June, and before then a 10% headcount reduction is announced, there may no longer be the middle managers available next June, for example, which could have cost, time, risk and quality ramifications, and the time to manage those is as early as possible, not next June. But, to continue the example, if the availability of a few middle managers has not been documented as an assumption, then in the excitement of the headcount reduction its ramifications may get forgotten.
Top of Page