I recently posed this question on Quora, knowing that there are a thousand potential answers - all of them probably valid when you spin them the right way. However everyone has a favorite which is born out of their own personal experience, probably some tragic PM circumstance that produced a "worst case" result.
So why bother with trying to identify each individual's "PM pet peeve"? Assuming each strong opinion is the result of some tragedy - this gives you a list of really important pitfalls to avoid - each of them THE most important in someone's eyes.
Here are a few responses from others. If you have a moment, please add your experience to the comment string...
LETTING PROBLEMS FESTER
COMMUNICATION AND RECORD-KEEPING
FAILING TO PLAN
LACK OF FORESIGHT
FAILING TO LEAD
Being open and honest is always the best way to go with project-related transaction. However there are many many times when you, your team, or stakeholders might be speaking in code rather than just saying what they mean.
I've listed a few of those coded messages below.
Code: "We don't have the budget for that."
Reality: "I don't think that's worth exploring."
Code: "We tried that already." (maybe 5, 10, 20 years ago)
Reality: "I don't think that will work."
Code: "[Our Competitor] already does that well."
Reality: "We can't ever match or beat [our competitor's offering]."
Code: "This is going to cannabilize [our existing product]."
Reality: "My job or my friend's job might change or go away."
Code: "Sometimes no just means NO."
Reality: "You are not worth explaining this to."
Are there others that you know of?
According to the recently released 2014 PMI Pulse of the Profession report, only 63% of projects have active sponsors. However, Active Project Sponsorship was again listed as the TOP DRIVER for project success.
Just in case you are having some issues (or just want to tune things up), here are a few resources on the site that could help:
Best of luck and may you have better sponsorship than a European soccer player.
I just stepped out of Bill Richardson's session at the PMI GC, called "The Power of Promise:What Every Project Manager Need to Know About Personal Branding". It was a great session because it was less about "why you should do it" and more about "how".
He began by describing what your personal brand looks like and walking you through each component. Here are the five things you need to know about your personal brand. For the sake of brevity I'm just listing the elements out here, but if you take a moment to think about each one - I think you'll get a lot out of it.
1. It all begins with a unique promise of value. What do you bring to the world that no one else does?
2. There are 3 aspects of your brand:
3. These imply questions that you should understand the answers to:
The answers here can be positive or negative, but you should know what they are.
4. These then map to your Conviction, Potential, and Reputation. These are the outer layer that people see most.
5. Your brand is a promise of value and it's an asset [that you must care for and cultivate].
So what do you do with that?
You begin by writing down your Brand Profile, which looks like this:
Then You Grow Your Brand
- Focus narrow and deep (making yourself more "special")
- No failure, just feedback (view your experiences this way)
And Protect Your Brand
- Confront Reality
- know Your KPIs
- Adapt or Die
Finally Promote Your Brand
- Share What You Know
- Pay Attention to What People Value and Need
- Express Yourself
- Deliver Change that Works
He closed the session with a really great statement, "People don't care how much you know until they know how much you care." So once you've established a brand and are passionate about it - let people know how much you care and they will too.
I always say that if I can get one \good point out of a hour long conference session, it was worth going. I'm at the PMI Global Congress in New Orleans this morning. About 15 minutes late, I popped into the Agile UNConference session and was immediately asked to facilitate a breakout on "Tools and Techniques for Communication in an Agile Environment." I held rapid-fire 10-minute sessions with three groups and talked about a lot of things that you might expect.
Part of each discussion was about software and I wanted to share two high-value points with you on which there was universal agreement. The first is about starting well. The second is about delivering status in a high-trust way.
The WAY you train the team on the software makes all of the difference
So if you do this, you’ll know in intimate detail how the software, relates to the work you are actually trying to get done. If you have that level of understanding of what’s going on, then the next point makes a lot of sense…
Use the software to communicate with executives (don’t add another layer)
Have you found these to be true as well? Please share any experiences you might have...