Running a Project is Sort of Like Raising a Baby – Sort of
Posted by Brad Egeland
I have a large family – and thankfully that family became a little larger three weeks ago today so this article topic seems appropriate. It came to me earlier this week that running a project from start to finish is kind of like raising a baby from infant to adulthood. Ok, it’s a stretch, but there are similarities.
It could be that this all came about in my mind as a result of several straight relatively sleepless nights. Or maybe I am on to something. Who knows? But the more I thought about it the more I realized that there are some relative similarities.
Pregnancy = pre-engagement/sales
Think of all the work that goes into the pre-engagement portion of the project … basically the sales portion. This is what happens before handoff of the project to the project manager. So, Sales = 9 months of pregnancy. Are you staying with me so far? When handoff is ready to happen, you kind of know what you’re getting – or at least you think you do. In reality, it may be close but there are lots of details that you really have no clue about and you have to dig deeper so you know what you’ve just gotten yourself into.
Delivery = kickoff
The actual delivery is somewhat like project kickoff. It’s when you finally see some early details of the project up close … live and in person. Just like you get some new and very key information from the customer you also get some initial information from the doctors and learn if there are any conditions of your baby that need immediate attention.
Infanthood/toddler = design
The infant and toddler stages = design, in my opinion. Just as you’re designing the system to the requirements of the customer, you’re also training your infant/toddler what’s right and what’s wrong and hopefully molding them to meet yours and God’s requirements for a well-rounded individual. And, just like designing to the customer’s requirements, it’s not very easy and it does often involve some re-work and change orders!
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.
Who’s More Important to Please – The Customer or Your Management?
Posted by Brad Egeland
I ask this question from the perspective of the W2 employee. If you consider this from the independent consultant angle, it gets too messy. In the consulting scenario, often your management in the PM role is YOUR customer and their customer is also YOUR customer. So, for the purpose of this article, I’m really just considering direct hire employees.
So who’s more important to please – your management or your customer? As a project manager, I always consider my customer to be the number one reason I’m carrying out a project. It’s their money and I’m trying to help get them to the solution that they are looking for – or at least the one that they really need (even if they need educated somewhat along the way). I’ve often been frustrated at the roadblocks that management has put up in front of me – rather than knock down – along the way to project success. And on at least two occasions the path that management has directed me to take on a project has led to utter disaster. I’m not saying my path would have yielded success, but the likelihood of success was definitely higher.
So for me personally, I err on the side of the customer. That is probably what makes me a better consultant than employee. In a perfect world you have management, a PMO Director, and an executive staff that is involved and helps build paths to project successes. But in more than half of the PMOs and project situations I’ve been involved in as a W2 employee that has not been the case. How can I tell beyond my own frustrations? Well, in all of those organizations either the PMO was eventually eliminated, the PMO Director removed, or the company shut down altogether. So in those instances, I’m banking on my opinion over theirs.
