Project Phases - The Finish line

In the fourth phase of a project (remember I am dividing projects into rough quarters based on time completed) the team should have really accelerated its efficiency.  With only 25% of the time for the project remaining, a lot of work is getting done very quickly at this stage, and your team is about to hit one of those false peaks I wrote about not too long ago.

The reason is that whatever your project is - a new process, a new accounting approach or a new computer system - the work associated with implementing the new thing probably only accounts for 40 to 50% of the entire project.  That's because you've got to document the new approach, test it and prepare to train others to use it.  Unfortunately for most projects, all of these tasks are left until the end of the project.

There are, of course, several reasons for leaving these seemingly small tasks towards the end.  One, it's hard to document a system or process that hasn't been implemented yet.  Two, documenting as you go can be frustrating because minds can change.  It's best to wait till late in the project to ensure agreement on the new approach.  Third, you don't want to distract your team to document something while they are working on it.  Fourth, it is hard to train anyone who is not involved on the project at any time, so most training is done once the project team is complete with its work.

These are all fine reasons (and probably the right reasons) to leave much of this work to the end of the project, but what this all means is that you'd better be finished with whatever it is your project is doing - implementing a new system or changing a business process - by early in the 4th phase of the project to leave enough time to adequately test, document and train the users.  In my experience these are the steps that get ignored or greatly reduced, since most project teams collapse at the finish line having barely finished the implementation by the end of the project timeline.  At that point they are too exhausted to finish up what seems to be insignificant items like documentation and testing and user training.

Avoid the desire to leave all this behind at all costs.  In my experience the number one reason most well-conceived projects fail is that we give short shrift at the end of the project to items like documentation and training.  What often happens is that a new icon appears on a computer screen or a new business process is put in place and users are just expected to figure it out.  Of course they need to keep doing their jobs at the same high level of efficiency as well - so what generally will happen is that they will simply develop work arounds to a system which presents itself with no additional training or documentation.

Give yourself some time at the end of the project do debrief as well.  One of the best times to critically assess what happened in a project, what processes and decisions were correct and what could have been done more effectively is right at the end of the project.  This is one of those "teachable" moments when you and your team can document the great and not so great things that happened along the way and hopefully learn from those events.

Well, that's enough of the project soapbox for a while. 

Comments

[Jag]

Very useful...Thank you