The Art of Project Management: Expert advice from experienced project managers in Silicon Valley, and around the world
TOPICS:

“PM”s

I am repeatedly in conversations with someone who refers to “PMs”. And I have to figure out which kind of PM they’re talking about.

Take this sentence from a recent email:
“…designed for executives, managers, PMs, BAs, developers, testers – essentially anyone in the software development value stream.”

Or the recent email with the subject line,  “The Evolving PM”.

Or:
▪    ”… white-paper about the over-laps between PM and UX.”
▪    ”…tons of PMs let go.”
▪    ”…there are now schools pumping out “certified” PMs.”
▪    ”If you know of any high quality PMs…”

I’m betting:
▪    if you’re a project manager you think those are all about project managers
▪    if you’re a product manager you think those are all about product managers
▪    if you’re a program manager you think those are all about program managers

In fact, they’re a mix. But there’s no way to tell!

While I’ve played several “PM” roles during my career, I’m not, today, a PM of any kind. I’m not a Project Manager, I’m not a Product Manager, and I’m not a Program Manager. Nor am I a Publication Manager (engagement last year: Stanford subsidiary HighWire, which hosts web sites for 1400 of the world’s most prestigious academic and scholarly journals from 150 publishers worldwide, and when I arrived, had 14 “PMs” for me to manage – who were account managers!).

But I have roles and responsibilities that require project managers, product managers, program managers and other “P” managers to communicate with me. I’m an interim VP Engineering. And a consulting CTO. And an Agile trainer and coach of Agile transformations. And co-author of the recent Addison Wesley book:
Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams

You need to know:  “PM” doesn’t communicate. Your own group may know which PMs you refer to. But the rest of us don’t.

The abbreviation terminology I’ve been evangelizing, in my engagements:
PjM == Project Manager
PdM == Product Manager
PgM == Program Manager
Every one of those abbreviations is self-clarifying.

Transforming Chaos to Clarity

credit: Judy Bell

 

I give talks on Transforming Chaos to Clarity.

Project Managers and Product Managers and Program Managers are, to a one, charged with clarifying software development, not adding to the chaos.

“PM” adds to the chaos.

I wish that were…

’nuff said.

Share

About the Author

Ron Lichty has been transforming chaos to clarity and making software development “hum” for most of his 20-plus years managing software development and product organizations. Ron co-authored 2012's highly regarded Addison-Wesley title, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.managingtheunmanageable.net/ ), his co-author Pixar/Broderbund/Gracenote CTO Mickey Mantle. With over 70 years of combined experience, these two software industry veterans crafted a book designed to help any software manager be more successful. Having spent their careers developing software, leading software development projects, and managing programmers and teams, they distilled their experience into a book that every beginning programming manager would get value from, both to read and to pull from their bookshelves for reference. It's a book that is also helping executives who struggle sponsoring projects dependent upon software success – CEOs, COOs, CTOs, and others – to understand the craft of software development and the intricacies of how to manage software people and teams to deliver software projects successfully. Ron has repeatedly been brought in as a “VPE of Fix-It” to coach and mentor programming managers at all levels and to solve problems like painfully slow product development, past-due estimates with no delivery in sight, challenges arising from geographically dispersed teams, scalability stymied by sluggish data integration, productivity bridled by uncertainty, an "order-taking mentality" from teams that should be eagerly proactive, and teams unable to break out of research and move on to development and delivery. Ron untangles organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers. Chaos to clarity.
Creative Commons License
Note: This work and all associated comments are licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

Leave a Reply

*