Project Management

Utilize a common definition for project start date

Here are some of the options for identifying a project start date.

One of the characteristics of a project is that there is a start and end date. This seems simple enough until you start to try to define exactly what these dates mean. There are no universally recommended standards for either date. In many respects, it depends on each organization and whether there are any implications for choosing one alternative over another. Here are some of the options for identifying the project start date.

  • The idea is generated. This takes the start date back a long way before the project is actually formalized. You may choose this definition if your company is trying to focus on the time it takes between when an idea is generated until the idea is fulfilled though a project.
  • A budget is approved. In this definition, an idea has been generated and the idea has made it far enough that a cost/benefit statement has been prepared, and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year business planning process. The actual work may not start until the following year. Therefore, this definition may also start the clock too early for many organizations.
  • A project manager is assigned. This one is more common. It may be 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. 
  • The Project Charter is approved by the sponsor. In some organizations the project officially starts when the customer approves the Project Charter document. They do this to ensure that the upfront agreement is in place before project work begins.
  • The project kickoff meeting is held. Using this definition, the planning and definition work is considered to be "pre-project" work. The kickoff meeting is the time to tell everyone that the project is ready to begin.

Why the start date is important

You might think that it doesn't really matter when the project starts. Having a somewhat undefined start date doesn't take away from the fact that the work is a project. 

The reason it's 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's 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 is assigned.  
  • Process improvement. Many companies keep track of the total duration of projects and attempt to shorten the average project duration over time. Everyone within the company should 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. 

The comments made by you are relevant and helpful, but i feel that the conceptualisation, analysis, and design of the project are of utmost importance. I unfortunately dont have the time to explian these phases, but i strongly reccoment that you download the Logical Frameworks Approach document. this will clarify everytthing, and is based on public participation, which results in empowerment and skills development. shaheem


We tend to use a pre-kickoff event, as well as a kickoff event for the following reasons. The pre-kickoff event brings the PM and the key team members together to plan the kick off. Here we identify other team resources and verify availability of hardware. More than once we have had projects get off to a rough start because of unexpected hardware delays either in shipment or staging. Once we are resonably sure the hardware will arrive as planned and we have identified other project team resources, we schedule the Kickoff ... that includes a lot of fanfare but also includes the finalizing of the project charter by the team and sponsors. The Kickoff signals the actual commitment of resource time ... particularly when some recources are drawn from the end usr community ... to project activities.

Nico Zwaneveld
Nico Zwaneveld

You're forgetting that a project has lifecycles, while trying to define "a start date". There is idea conception, possibly followed by any number of common lifecycle models that can be used to build deliverables. The definition of a start date can differ per lifecycle model. So in my opinion there is no generic way to define project start dates. Each project will need to address this question time and time again, even if inside a single organization. Even if there seems to be a common assumption about what the start date is, I would still double check it!


I resolve this issue slightly differently. I start from the position that a project only exists when you have both a good thing to do (aka scope) and the resources to do it with. Say you have a good idea for a new product, but you need to do more work on both the design and implementation details, as well as getting the necessary resources assigned. Your boss is prepared to let you to develop this new idea to the point where you have a business case that can be reviewed. The development of this business case is the 'approved' scope of your project, and the resources are your time and associated support, and any other support that has been specifically allocated. Your project scope is not (yet) the full development of your idea, even though your business case will address this. Your mandate so far is only to get the business case complete. Accepting the business case that you are developing might be a significant investment for your organization, and you are given approval, say, to only complete the work to produce an architecture and design that can be reviewed by senior management. One way of looking at this is that you have a new project - the good thing to do is to complete that architecture and design, and the resources are those that you have now been allocated. Once again, your new business case will need to contemplate the complete development life cycle, but your mandate is still limited to the development of the architecture and design. If your work on this shows that there is still a sound business case to complete development and production, your organization will then be in a position to commit further resources to your work. In these circumstances, your new project scope will cover the remaining activities to complete the development life cycle. In this example, the software or systems development life cycle has been split into three discrete phases, each phase run as a separate project. Both the initial and each subsequent plan should have considered the complete development life cycle - not just that part for which you were seeking approval. That much is critical for the organization's commitment of resources to the overall development activity. Many organizations will label the overall development activity a project, and each tranche of approved work as a sub-project. This approach only works if the organization approves the complete development at the very start. Only in this case will both the development and project life cycles align. Otherwise this practice is mis-leading. If the organization limits approval to specific intermediate objectives in the development life-cycle, they are implicitly creating separate projects to achieve each of these objectives, and any one development life-cycle will be implemented in several project life-cycles. The key issue here from a time management perspective is when resources were made available, and when the project manager completes delivery of the agreed scope. I think that the issues Tom identified in his original note are still valid within the framework I am suggesting, but what is also needed to to keep track of the development life cycle as well as the individual project life cycles.

Editor's Picks