Project Management 2.0

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

BEING INDECISIVE

FAILING TO PLAN

LACK OF FORESIGHT

NOT MANAGING

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:

• Peter Taylor's blog post "The Campaign for Real Sponsors", gives you a list of job responsibilities for Project Sponsors. You can easily use this list to do a quick gap analysis, then politely suggest changes to your Sponsor.
• If you want to dive a little deeper, our Sponsor & Change Agent Toolkit gives you a number of awesome resources to help transform your Sponsor into a Change Agent. That helps you AND could help further their career. Bringing them this toolkit might score you some serious brownie points!
• There's also quite a bit of practical insight in the Enroll Sponsor section of Project Headway (our PM Process), including questions you would ask yourself when identifying your sponsor in the first place.

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:

• Capability (Mindset, skill set and tool set)
• Character (beleifs, traits and values)
• Commitment (learning, mastery, and growth)

3. These imply questions that you should understand the answers to:

• What are you known for?
• What do you stand for?
• What are you capable of?

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:

1. Vision
2. Mission
3. Needs
4. Values
5. Interests and passion
6. Strengths
7. Personality attributes
8. Goals
9. Unique Promise of value
10. Brand Statement

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
There is only one effective way to train people on tools. It’s using the tool, methods, and actual project data all at the same time (in a training environment where you can check understanding – not just on the job).  The folks who were anti-tool in these groups admitted they hadn’t done it that way. Those who did seemed to be universally successful.

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)
Use the actual Agile Software or Project Room Board (if there’s no software) to present to senior management. It’s what is really going on, versus yet another interpretation of what’s going on. This not only creates a window into the actual work that inspires trust from management, but also eliminates additional documentation (status reporting) to a large degree.

Have you found these to be true as well? Please share any experiences you might have...