Are You Using the Tools, or Are the Tools Using You?
Posted by Brad Egeland
We have all kinds of tools to get information concerning our project distributed to the right people, don’t we? We have MS Project or similar projects like Seavus’ Project Planner to use for managing our project schedule. Word helps up put together project status meeting notes, project document and plan deliverables, and status reports. Sometimes Excel can do the same – plus it’s great for project budgeting and forecasting. For resource management it’s back to MS Project or another project scheduling tool or you can do it the old fashioned way with a spreadsheet like Excel. And Visio helps us put together meaningful flowcharts for functional and technical design documents and other related project materials. Finally, email is often our primary communication tool on projects. Since communication is probably the most critical function of the project manager, email is in heavy use throughout every engagement.
Throughout the project, the project manager and the rest of the project team are utilizing these tools to create visual, professional, and hopefully meaningful and useful project documents to give to the customer and show to the organization’s executive management. In fact, if the project manager is overseeing five or six or even more projects at once, the creation of these documents and files with these tools can end up taking most of his available time. Especially if accuracy and perfection is a goal – and it should be.
Don’t forget the personal side
What we need to always be aware of, however, is that our customer needs more than just information about the project. And for communication they need more than daily emails. It isn’t always about what we can produce for them and how professional it looks. The project manager must be able to connect with the customer on a more personal level than with schedules, charts, and reports. In order to maintain the highest level of customer satisfaction, the customer must feel like they are ‘in touch’ with the project and the project team. That isn’t likely to happen if all they see are emails coming their way with information and professional-looking document attachments.
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.
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.
May 2010 Survey Results: Equipping the Project Manager
Posted by Brad Egeland
The results are in for the May PM survey on equipping the project manager. The response rate was very good – many thanks to our readers who responded because without you there would be no survey and no fun follow-up analysis.
In terms of surprises, in my opinion there were four key surprises that I will describe in my run down of the results below…
Formal PM Methodology
Here’s the first surprise: only 53% of the survey responders indicated that their organization followed a specific project life cycle or project management methodology. That means that 47% are basically ‘winging it.’ While that’s ok on occasion, it’s very difficult to realize long term organizational and project success without some sort of consistent, repeatable process in place. Nearly half of our survey responders don’t have that and that’s concerning.
PM Software
No big surprise here … 58% use Microsoft Project as their primary tool for managing projects. What was surprising is that a full 26% are not given any specific tool to use when managing projects. Back to the ‘winging it’ concept… not good. 11% indicated that they utilized a web-based PM tool and 5% indicated that they use some desktop tool other than MS Project to schedule and manage projects.
