Something’s Always Wrong

256-256-4c515d45f6a8c4fe16e448a692a9370dYou may think I’m a bitter guy when visiting my blog, ironically, this is not true. Even when this site is called “Happy Project Management”; most of the blog titles carry a negative connotation. On the contrary, I am not bitter guy, I am simply utterly realistic. Today’s blog is about the perfect project, which of course does not exist, maybe in your imagination or in your dreams. And, sadly, and against your happier wishes won’t ever exist. Why?

The answer is simple, perfection does not exist in project management. I think it does not exist anywhere. If anyone says their projects are perfect, please challenge them immediately. Something’s Always Wrong. Projects, as you may know, have to be successful, not perfect. Project Success has many dimensions, and of course not just time, cost and scope. Let me grab a few samples. How many dimensions do you want to measure besides the usual ones?

I’ll start with the biggest offender, documentation. I’m sure you are shivering right now praying that nobody goes back and asks you for a specific document, minute, agreement, issue or plan adjustment. Good luck with that. Heck!,  there’s the infamous Grade vs. Quality issue, most customers confuse them and demand you one when they are expecting the other or vice versa. How about “exceeding customer expectations” ? Let’s say you invested additional time making your project more visually appealing, that’s good, but you spent more money and of course; more time. What happens with those customers that will never call you back even after successful projects, sometimes because of budget constraints, corporate mandate, technology migration, or worst; administrative reasons. Or, because they simply DIDN’T like working with you. Bummer.

Are you pursuing a target of 0 complaints from the customer? Forget it, be pretty sure you will receive complaints just a justification to establish a negotiation point. Are you part of a project that MUST be executed? such as a migration, upgrade, end of life, moving to a new building/office? Those projects will bring tons of unhappy users, no matter if your did it on time and saved money. Did you receive a prize, recognition, award or something similar? Yeah, I’m sure nobody remembers it anymore, but you. (Remember my last blog?) Your team spent extra hours? Good luck trying to charge anybody for them. Do you think your outsourcing is going smoothly, because well, it’s an outsourcing and you don’t manage it directly? Hell no, be prepared to be blamed for poor project management.

Well, as you can see, the list goes on and on and on. Something’s Always Wrong, it will be very hard to achieve success, and it will be impossible to achieve perfection. What can we do?

Be sure to know how are you going to measure your project success and always use goals that can be measured. Motivate yourself to evolve towards different success dimensions, one step at a time. Once you have in-time in-scope in-cost projects, take a look at your rebuy rate, or go back and audit yourself and be sure you have all documentation, go back with your QA team and review your project, show the lessons learned to other PMs, measure how much support time your project has required after its closure, and so on.

Something’s Always Wrong, just be sure that those little things that are wrong, are the things you can’t control.

Nobody will read your meeting minutes

shred-icon2Hello. Today, I’m resuming my stranded blogger activity. I will address the debated “meeting minutes” subject today and how they can help us in Happy Project Management. I have worked for many managers, customers, sponsors, project teams and using many flavors of methodologies, but hang on, we’ll talk about PM methodologies in a future blog.

Meeting minutes. PMI says this is push communication. There’s not a consensus about meeting minutes (layout, frequency,etc ) as long as you write them and of course, publish them. Some time ago, I used to generate extensive and detailed minutes until one day my boss called me and asked me “man, are you sure somebody is actually reading your minutes? how much feedback are you getting?” Then I realized that on weekly status meetings, even on large projects with large audiences (18 people) only 5 people replied to my emails making comments on a monthly basis, roughly 7% of total possible feedback. Why? At that particular time I was working for a large organization in an even larger company, most of the technical leaders and key members where handling an average of 8 concurrent projects besides their regular operation. That means that they were already spending at least 16 hours in project meetings. Do yo think they wanted to spend more time reading an extensive and exhausting document? Is not that they didn’t want to, it was a burden on their already over allocated agendas. I reckon I skipped reading them sometimes. Then I went through a couple of old minutes and I opened the can of worms. The most common issue was misspellings, tons of them; then I found no list of attendees, dates, agreements, action items, issues. That means that nobody was reading them, nobody was paying attention.

So, should you send scarcer, briefer, shorter minutes or with less frequency? Is that going to save 30 minutes of your time and make you a happy Project Manager? Should you say “well, nothing happened in the meeting, so, I won’t send a minute, I’ll save some time”.

No way, never. I can assure you that not writing and sending  a minute will come back and haunt you at some point. You must not stop sending them, always send them after every single meeting, call or small agreement you make. If nothing happened in the meeting, be sure to make a minute that says who attended, who did not and that really “nothing” happened on that meeting. I guarantee this will save your ass and make you a Happy Project Manager. When somebody comes back, yell at you and complain, you will be able to tell them: “Did you read the minute? You should have…” 

Nobody will read your meeting minutes, but be sure to send them.

TTYL