Tom Mochal of TenStep, Inc. a long-time friend of mine, writes a regular column in which he dispenses his wisdom in Tip of the Week.[1] In particular, on 03-17-2010 he wrote "There are a number of options for defining when a project actually starts". I found his assessment most interesting and, of course, had my own views - but that can wait until later.
Max:
One of the characteristics of a project is that there is a definite start and end date. This seems simple enough until you start to define exactly what these dates mean. There is no universally recommended standard for either date. In many respects, it depends on what the implication of the decision is. You must consider some of the possible options for the start and end date and see what you think makes most sense. The following options can be considered when determining the project start date.
When the idea is generated
Some companies seriously consider this option. The definition you choose can depend on what the implication is and some companies try to focus on the time between when an idea is generated and when the idea is fulfilled though a project. Their concern is that there is too much time to implement good ideas. Tracking a project from the time the original idea was surfaced provides visibility on this total length of time. Unfortunately, it is very difficult to track exactly when an idea surfaced and there are many variables that might cause projects to be delayed while still in the idea stage.
When a budget is approved
This definition is a little more concrete than the prior idea. In this definition, an idea has been generated and has made it far enough along that a cost/benefit statement has been prepared. The project has also made it through the prioritization process and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year's business planning process. The actual work may not start until the following year. Therefore, this definition again seems to start the clock too early.
When a project manager is assigned
This one is more common. It's hard to say that a project has started before a project manager is assigned. When the project manager is assigned, the project planning and definition begins and the meat of the project starts.
When the project charter is approved
In some organizations, the project officially starts when the customer approves the Project Charter document. Some companies require an approved Project Charter and schedule before the project team can be allocated. They do this to ensure that the upfront agreement is in place before project work begins.
When the project kickoff meeting is held
Using this definition, the planning and definition work is considered to be "pre-project" work. All projects start with a formal kickoff meeting between the client and project team. When the kickoff meeting is held, the planning has been completed, the client has approved starting the work, and the project team has been allocated. The kickoff meeting is the time to tell everyone that the project is ready to begin.
Why is the start date important?
To a certain extent, you might think that it doesn't really matter when the project starts. Having a somewhat undefined start date does not take away from the fact that the work is a project. It's obvious that the project started at some point, since there was a point when the work was not in progress and a point where the work is in progress. So, at some point the project did in fact "start".
The reason it is important to know the start date is that there may be consequences and incentives based on how long it takes to complete a project. The following are examples of these consequences.
Project team accountability. It is hard to hold people accountable for things that are not within their control. For that reason, it makes sense that a project manager is held accountable for the project no earlier than when he or she is assigned. If the project clock starts before he/she is assigned, it is possible that some decisions were made and some resources expended before they were assigned, and therefore they have no control. Likewise, if team members are held accountable for completing a project within budget and on schedule, it is hard to hold them accountable for work and decisions that take place before they are assigned. For that reason, perhaps the project should officially start when the Project Definition and workplan are approved, or after the project kickoff meeting is held.
Process improvement. Many companies keep track of the total duration of projects and attempt to shorten the average project duration over time. It is important that everyone within the company use a common starting and ending point. Otherwise, the project duration numbers will not be meaningful.
Financial / accounting. Many projects are considered capital expenditures. Precisely defining when a project starts has consequences in terms of the work that can be capitalized and the work that needs to be expensed.
Comparisons with other companies. If you compare how long it takes your organization to deliver projects, you want to make sure you have a common definition of start and end dates. If your company considers a project to start when a project manager is assigned and other companies start the clock at the kickoff meeting, it will appear that your company takes longer to deliver projects.
Summary
All projects have a start date. But knowing exactly when a project starts is something that companies can define differently. There are a number of events that would be candidates for the start date. If your company does not capture metrics and does not provide incentives based on completing a project on time and within budget, then it doesn't really matter. However, if there are consequences based on the defined start date, then a company must be careful to make sure that the defined start date drives the proper behavior they are trying to achieve.
As I mentioned earlier, I couldn't help diving in with the following observations.
Tom:
It is true that all projects have a start date, and should have a finish date, but it seems to me that you have in fact missed the definitions of both the real start and possibly the real finish of the project. Of course there are plenty of projects that "sort of just start sometime" and finish by "fading quietly into obscurity". However, for purposes of your analysis I think we have to assume, if not "best" practice then certainly we should assume "good" practice.
"Good" practice requires that every idea with project potential should be subject to a "Value proposition" or more formally a "Business Case". These may be no more than a paragraph to a couple of pages, but as soon as it is determined that either should be given further consideration, then that is when the project actually started. However, this is not necessarily the date that the "On Time, On Budget" clock starts running for purposes measuring project performance. That can be an arbitrary date determined by management that is well down the project's life span, such as the approval of a Project Charter for project execution.
At the other end, it seems fairly obvious that the project is not finished (unless deliberately aborted) until the product is delivered. Again, management may decide to extend the finish date of a project contract by including a period of support and maintenance, for example. However, this is again an individual management decision. So ...
Project Start? My vote goes to when the value proposition of an idea is given the go ahead for further work.
Project Finish? My vote goes to when the product is not only delivered but also handed over to the "Care, custody and control of the User".
In summary, then, good practice does have fairly clear project start and finish dates. However, for purposes of performance, productivity or other administrative reasons, management may arbitrarily set other dates at its discretion - as Tom has suggested.
