Documenting the Project at Closeout Time
Posted by Brad Egeland
Documentation always seems to be the most difficult part of the project to complete. There is little glamour and no major kudos in doing documentation. That does not diminish its importance, however. There are at least five reasons why the project manager and team need to do documentation on the project:
Reference for future changes in deliverables. Even though the project work is complete, there may be further changes that warrant follow-up projects. By using the deliverables, the customer may identify improvement opportunities, features to be added, and functions to be modified. The documentation of the project just completed is the foundation for the follow-up projects.
Historical record for estimating duration and cost on future projects, activities, and tasks. Completed projects are a great source of information for future projects, but only if data and other documentation from them is archived so that it can be retrieved and used. Estimated and actual duration and cost for each activity on completed projects are particularly valuable for estimating these variables on future projects.
Training resource for new project managers. History is a great teacher, and nowhere is that more significant than on completed projects. Such items as how the WBS architecture was determined, how change requests were analyzed and decisions reached, problem identification, analysis and resolution situations, and a variety of other experiences are invaluable lessons for the newly appointed project manager.
Input for further training and development of the project team. As a reference, project documentation can help the project team deal with situations that arise in the current project. How a similar problem or change request was handled in the past is an excellent example.
Dealing with Project Failure
Posted by Brad Egeland
I’ve mentioned in recent articles that the many surveys and studies are putting the project failure rate in organizations at anywhere from 51% to 75%. Given this alarmingly, but not surprisingly, high rate of project failure, it seems only fitting that we discuss how to deal with project failure. After all, when a project fails it doesn’t just happen and then you move on to the next project. There’s always an aftermath …. there are always repercussions.
Some of these potential repercussions can include (depending on the size and visibility of the failure and the reasons behind it):
- Reprimanding or termination of the project manager
- Reprimanding or termination of project team members
- Lost future business with the customer
- Bad press for the organization damaging its reputation
- Bad feedback to other current or potential customers
So how do we deal successfully and proactively with project failures? When you’re a project manager, even if you’re an incredibly skilled, successful, and lucky project manager you’re going to experience failure at some point. So we all need to know how best to deal with this impending failure both for our sake and the sake of our team members who we may end up working with again on a future project.
I can’t say I’m always successful at performing these steps and thankfully the failures have been fairly small in very infrequent, but these are the processes that I believe the project manager needs to go through in order to best deal with the project failure in terms of his customer, the project team, and his executive management…
Lessons learned session with the project team
Hold a lessons learned session internally with the project team. Let them all air their issues. Better here than in public or in front of the customer. Many may feel that the failure is the customer’s fault and that can and should be discussed, but aggravations should be aired here, not in front of the project customer or even executive management.
The Difference Between Project Success and Failure May be in Your Head
Posted by Brad Egeland
I’ve written a lot about project success factors and thoughts on why projects fail. It’s even a topic on this month’s project management surveys (go here to take part 1 and part 2 of the June PM surveys – we’ve had great turn out so far so the results will be interesting … so please participate).
Depending on your organization or your customer or even your own perception, the definition of project success or failure can be very different. Usually it’s one of three possible options:
- On time project delivery
- On budget project delivery
- Satisfied customer upon delivery
However, it can sometimes be a little gray. The fine line between project success and project failure may not be that clear.
An example of different perceptions
Case in point – I once led a project for a company where the client was a major airline. The client who was receiving the customized software implementation wanted it done in 90 days – something we had never done before in industries we were familiar with let alone in the airline industry where our software had never been implemented. A new industry meant new configurations to the software – to promise 90 days was absolutely crazy. What was Sales thinking? What was our company leadership thinking?
In the end, it wasn’t a 90 day implementation. At the 90 day mark I was onsite with a team doing everything we could to get things up and running but there were too many issues – too many things missed in the early requirements phase because we cut it short at the customer’s request based on the fact that they wanted an out of the box implementation. Yeah, right. That really wasn’t the case. Finally, about 90 days later, I finally handed off the system to them as close $38,000 over budget – most of which the customer did agree to pay.
June PM Survey: Managing the Project – Part 2
Posted by Brad Egeland
Part 2 of the June PM survey is now available. This 2nd part of the monthly survey again deals with concepts associated with the ongoing management of the project.
The survey is now active and ready for your participation at:
http://www.bradegeland.com/june-survey-part-2.html
In this 2nd part of the survey, we’ll be looking at the following topics:
Definition of project success
For this question, I’m looking for how either you or your organization primarily defines project success. Is it on time project delivery, on budget project delivery, or customer satisfaction? And for those of you who feel it’s something other than those three options, there is a write-in ‘other’ response area available.
Percentage of successful projects delivered
This one will definitely a best-guess scenario because I doubt that anyone has compiled hard numbers on this plus it’s somewhat subjective as to what one would call a ‘successful’ project. I’m trying to get an idea of where our readership stands in regards to successful vs. failed projects. Recent studies – as I’ve reported here in recent articles – place the percentage of failed projects between 62% and 75%. It will be interesting to see where PM Tips readers fall in that spectrum.
Percentage of project revenue from change orders
Change orders are always a love – hate thing. For the PM and team, they are a great way to increase project revenue and executive management loves them. However, it’s often difficult and even uncomfortable for the project manager to present the customer with change orders – unless they are the result of direct customer requests. Also, change orders are a necessary tool to bridge the gap between the originally defined requirements and what reality fleshes out over the course of the engagement.
If the BP Oil Spill Were a Project…
Posted by Brad Egeland
If the BP Oil Spill were a Project, would the cleanup and well capping process be going differently? I’ve been asking myself this question a lot this week so I figured it was time to put words to down and see what our readers come back with.
I have to believe that British Petroleum (BP) actually is treating this issue like a project, but I’ve never seen so much back to back failure in any project I’ve ever managed or witness from a distance so it’s truly hard to believe that PM best practices are being applied to this one.
Here are the facts we have so far:
- Oil has been flowing freely for 46 days so far
- A low end estimate of per day oil flow is 210,000 gallons
- That’s 9,660,000 gallons spilled over the 46 days
- The White House has just sent BP a $69 million bill for cleanup efforts
These numbers are amazing and shameful all at the same time. And there’s almost no end in sight due to BP’s repeated failures to make progress on capping the well.
Questions we have to ask?
- Did BP do on-going risk analysis?
- Have laws been broken?
- Should any BP executives still have their jobs when this is finally over?
- Do you think the BP Project Manager will ever get another gig?
This may not be the case, but each new attempt to cap the well or channel the oil flow to a surface ship seems to be a new shot in the dark and continually ends in failure. It’s easy to say that customer confidence is at an all time low right now for BP. Each new attempt needs to be treated as a separate project – or at least a separate sub-project with planning already in the works for the next attempt. Potential issues need to be reviewed, risk analysis and risk mitigation discussions need to be happening 24/7.
