Project Management

What event signals the end of your project?

The question of when a project formally ends is one that most people take for granted. However, there is not an easy answer for every organization.

We all know that a project is a temporary endeavor. All projects have some start and end date. However, when I teach project management training classes I like to ask the participants exactly what they consider to be the end of a project. After some discussion, we realize that there are many candidate events that could signify the end of a project and, in most organizations, the definition is not consistent.

One idea is that an end-of-project meeting could mean the project is officially over. Although ending the project at the end-of-project meeting helps a little bit, it doesn't answer the total question, since you still need to decide when to schedule this meeting. You could hold the meeting after a number of events, for example after you go live or 30 days after you go live. The ultimate definition of project completion is not resolved by this answer.

Tips in your inbox
Looking for expert IT project management advice? Get the help you need from TechRepublic's free Project Management newsletter, delivered each Wednesday.
Automatically sign up today!

The second definition that doesn't help is that the project ends when the money runs out. Although in many projects, this is actually true, it doesn't help you in terms of the basic definition. Ending a project when the budget runs out is a financial answer and it is highly arbitrary. It doesn't answer the more fundamental project management question of how to define the end of a project.

There are a number of events that could signify that a project has ended.

Sign-off

Perhaps the earliest date the project could end is when the client sponsor formally approves the project deliverables. This definition is probably valid for almost all projects. You're building the deliverables for someone or some group. It makes sense that the project has not completed until the people who requested the work are satisfied. This may involve presenting the deliverable for approval, and then performing rework based on their feedback. However, for the project to end successfully, the deliverables must be approved. The project could also end if the final deliverables were rejected and no further work is planned.

Implementation

Many projects result in the implementation of a product or service. IT projects are typically this way. In most cases, you need sponsor sign-off before you would implement and so this implementation event would take place at a later date. Implementation may be a single event, or it may be a complex set of activities. The project doesn't end when implementation starts, but when implementation ends. For instance, if you're implementing a solution in multiple locations in close time proximity, the project would end when all of the locations were successfully implemented.

Turnover to support

If your project builds a solution that has a longer term life-span, at some point the deliverables go from being in "development" to being in "support." Sometimes this change in status also means that there's a change in the organization that's responsible for the solution. If your project solution is turned over to a support organization, that would also be a typical time to consider that the original project has completed. If there's a point where it's clear that the solution is in support mode, it's at that point the project would officially end.

Implementation plus one production cycle

If your solution has a production cycle, many times it needs to be run in production before the project is considered complete. For instance, if the solution has daily transaction processing, and a monthly closeout cycle, the solution needs to be implemented and then supported by the project team for at least one month. This makes sense since the project team knows the solution best and can respond the quickest if initial problems occur. This also helps ensure that the solution is stable before being turned over to the support team. 

Implementation plus first year production

This is typically based on the budget cycle rather than a project management definition. There may be some accounting reasons why a project needs to exist until the end of the fiscal year. When the new fiscal year arrives, the project ends and support begins. Again, this would not answer the basic question from a project management perspective, but it may be the way that project end dates are defined at your company. This definition might especially be applicable for large projects.

Some end date options might not make sense for certain types of projects. For instance, if your project results in the creation of a study or recommendation, it would make sense that the project ends when the deliverable is approved. However, on that project, it would not make sense to say that you would run in production for 30 days.

The question of when a project formally ends is one that most people take for granted. However, there is not an easy answer for every organization. There are probably one or two answers that make most sense from a project management standpoint, but there may be cultural or financial factors that cause your organization to define the project boundaries differently. To a certain extent these dates just need to be understood up-front and agreed to for each project. This agreement will keep you from being in a position where you declare victory only to discover others that think you have more work to do.

8 comments
mikifinaz1
mikifinaz1

The project crashes. The client runs out of money or they discover they can't get from here to there.

michael_junk
michael_junk

The real answer: A project isn't finished until the last user dies.

dspeacock
dspeacock

In the first, the government did away with the crown corporation I'd been at for 6 years. NAturally, IT was the first to go. Payback was interesting though, my next job had me back where I'd just left as the contract administrator.(for more money even). In the rest, the money or time had run out.

TheChas
TheChas

At a place I used to work at in Central Michigan, we knew when a project or product had reached maturity and would need no further support or development. The final phase for every project was the litigation phase. About 75% of the time, we ended up suing our customer. The remaining 25% of the time was mainly suing suppliers. The really successful projects went into litigation before the initial engineering phase was completed. This bypassed the messy and costly production phase. The owner of this company fancied himself as many things including a back seat lawyer. When I parted ways with the company, the owner was in the process of suing his law firm for not properly litigating his cases. An interesting side note we found when searching the companies name on the web is that it showed up on a number of law school web sites. Turns out that law schools were using some of the companies legal battles as examples of how not to litigate. The last word I had on this company is that they are in bankruptcy and the owner is NOT allowed to be involved in any financial dealings of the company. Chas

Why Me Worry?
Why Me Worry?

I do my best to document my day to day work and provide updates, but there are idiots in charge that will always look to scrutinize every hour being billed and will do their best to nickel and dime us consultants. When that starts happening, I give them the one finger salute and walk out of the door, whether or not the project is finished. If they expect me to get things done, given the limited amount of time I have to do it, then they should expect for me to put in late hours and work well past the 8 hour workday of most 9-5 employees. What annoys me the most is when I am being pushed out of the door at 5pm on the dot because they don't want to pay me more than the standard 40 hours workweek, yet they expect me to complete a task in a week that most people can't complete in a month.

NOW LEFT TR
NOW LEFT TR

When I leave 'the company' my project ends!

Cnanovic
Cnanovic

Having been an IT consultant for 25 years, I recognize the situation described by Why Me Worry?, and have experienced it myself. This sort of situation is not limited to small businesses, but seems to thrive in large corporations as well - perhaps to an even greater extent! Groups and departments within the corporation can take on personalities of their own, have differing agendas and politics, all of which has an impact on which projects are selected, funded, supported and otherwise given priority. So much depends on the support of executive management and customers, not to mention alignment with strategic objectives and clout, which can change. Don't forget that all projects in an organization compete for limited resources - people, money, equipment, materials. And IT departments today are running leaner, ofen with the workload of exiting employees being added to other already overloaded workers. If the value of a particular project is not recognized by those approving the resources, it's unlikely the project will continue to be supported. OK, so we all understand that. So what? I agree that there are and should be formal ways to determine the end of a project. Until the last user dies? - no, because a project is by definition unique and temporary. If we allow changes until the last user is satisfied or dead, we have not contained scope. Changes or enhancements beyond scope can become the basis of the next project. Until we get so frustrated by unrealistic demands that we salute and walk out? - arriving here suggests we have failed to properly communicate and document status and issues all along, given inaccurate or no estimates, or not taken a stand when asked to do something unreasonable. Being asked to do something unreasonable can also be a political move to derail a project perceived to be unnecessary or in competition with another favorite. Understanding this, does it then justify attitudes and unprofessional behavior? No - you never know down the road who your boss will be, or whose boss you will be. Don't burn bridges! To make my point, we as consultants need to use wisdom and professionalism in all situations, no matter how unfair they seem to be. When we have done all we can and followed good PM procedures, if we decide we must walk then by all means do so, but do so with integrity and professionalism - no saluting, please. I know one company who can't say "consultant" without putting "G.. D..." in front of it. That's a legacy that will hurt us all.

Why Me Worry?
Why Me Worry?

Of course I don't act unprofessional on my way out and actually flip them the bird in full view, but I will not pull any punches and openly express my frustration and aggravation with the project because I feel my hands are being tied. I don't know why many consultants are so fearful of openly stating that the internal politics are hurting the project and affecting the bottom line. If they don't like what I have to say, then too bad, because if I am contracted to do a job, I will do whatever it is I need to do to complete it within the scope of work, time, and cost. If someeone in charge wants to play politics with me, I will simply pack up and take my business elsewhere. I try not to burn bridges, but sometimes, one has to have the "balls" to tell the managers that they are their own worst enemies because they create obstacles that we'd all rather do without. As far as giving them the one finger salute, I do that when I am outside of the premises in full view of their security cameras. :-)