Interview: Why PM matters to developers

Continuing my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).   Also, Stephen describes a promotion to get 40-percent-off his book at his blog here.  Here we focus on why he spent so much time on PM-relevant topics:

One of the pleasant surprises in the book was the early attention you paid to strategy, value, scope, deliverables and other project management touchstones. Why so much PM?

I find that adopting a new and different practice — in the hope that it’ll be ruthlessly helpful one — is an initiative, kinda like a micro-project. This can happen at so many levels … an individual developer, a technical leader, the project manager, the organization. Continue reading

Interview: Project Mgmt and Software Dev Best Practice

Continuing my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).   Also, Stephen describes a promotion to get 40-percent-off his book at his blog here.  

If you’re a regular reader, you’ll know I’m wary of the term best practices.  Stephen is as well, and here’s his take:

Q: Your book’s title notwithstanding, you’re keen to move people away from the term “best practices.”  What is wrong with “best practices”?

A: My technical reviewer, Paul Apostolescu, asked me the same question. Paul often prompted me to really think things through.

I routinely avoid superlatives, like “best”, when dealing with programmers, engineers, and other left-brain dominant people. Far too often, a word like that becomes a huge diversion with heated discussions centering on the topic of what is the singularly best practice. It’s like that old saying, the enemy of the good is the best. Too much time is wasted searching for the best practice when there is clearly a better practice right in front of you.

A “ruthlessly helpful” practice is my pragmatist’s way of saying, let’s pick a new or different practice today because we know it pays dividends. Continue reading

Estimate rejection can be a good thing

Rui Silva has a short but sweet post on estimate rejection here.   I love his point that estimates must be “honest” because:

 When technical staff low-balls a project estimate, it denies the executives important information they need to make effective decisions, effectively undermining the executive’s decision-making authority. This results in diverting company resources from projects that are cost-justified to projects that aren’t cost-justified.

Own your project’s story (HT @MelanieDuzyj and @mkrigsman)

We all should know how critical project communication is to project success.   A compelling story can build strong sponsorship and sustain stakeholder commitment, even in the most challenging of circumstances (also see Michael Krigsman’s project success checklist) .  However, many project managers assume that their audiences — or even worse, key influencers and “re-communicators” — understand the story as well as they do.

The group blog at BlissPR has a useful post by Julie Johnson on “Getting the Details Right“.  I’ve often suggested that project managers leverage what their PR professionals more.  IMO, the ability to influence is an essential behavior for an initiative leader.  Why not listen and learn from people who know?

In this case, the lessons for driving accurate press coverage apply well to any project that needs to own and drive its story.  Simply substitute “project” for “company” or “industry”, and “stakeholders” for “media”. 

  • It’s more important than ever for a company to take control of its reputation – after all, you either control your reputation or someone else will
  • Educating media about a company or an industry can be even more important than garnering coverage
  • The story you tell must be simple – especially when the truth is complicated

Why can’t we plan for leadership?

Glen Alleman asks “Why is it so hard?” and focuses on one of the most difficult line items for IT projects to fund: project/program management, including contract planning and controls. 

I’ve had varying success in positioning these resources, so I’m still stumped.  Arguments that worked for one initiative failed for what should have been a similar initiative. 

So here are two questions to you all:

  1. What arguments, research, findings, etc. have been EFFECTIVE in ensuring that your projects or programs have the leadership they need? 
  2. Does these “effective” factors work better for one type of project over another?  In other words, do some types of projects lend themselves to “selling” project management better than others?

What is “ready to use”?

Sorry, Derek, it's prêt-à-l'emploi not prêt-à-porter.

I’ve found that the packaged application and custom development fields make at least some nod to standard project management practices.  No doubt there are many suboptimal practitioners, but few ignore or openly bad mouth project management.

Infrastructure — servers, network, and desktop — appears to still be another matter.  I’ve been shocked by how much expediting and Potemkin planning — plans that are only for show — I’ve seen in the last six months.  One of the most frustrating practices is when IT Operations claims victory over useless milestones after having claimed that planning would have done nothing but slow them down.

Perhaps slowing down would prevent rework and wasted effort (by one’s customers!).  For example, our service provider’s infrastructure team tried to get credit for server delivery.  Except that the server was only powered on and connected to a network — it was far from “fit for use.”  No one could access the network remotely — is it based in a data center after all — and even if they could potential users were then stymied by no log-on being set ups.  Never mind that we couldn’t use the server anyway because it hadn’t been qualified (we’re in a FDA validated industry).

If you don’t own “fitness for use” as the underpinning of your deliverables, you aren’t managing your projects, you’re playing “whack-a-mole“.

Which PM “faux pas” make your hair stand on end?

In my last post about the “school solution,” I noted that there’s something unnerving about project and program managers who skip over the basics.  As Glen Alleman noted in his comment, the PM school solution or black letter law almost always has some merit as a start.

Thinking about this post brought to mind the various project management myths, missteps, and mistakes that put me on edge.  These three always make me wonder about the person who says them:

  • Calling a project schedule a project plan.
  • Not knowing the difference between an issue and a risk.
  • Suggesting that planning is useless if we don’t know all of the activities.

What are your pet peeves?  Which PM faux pas makes you nervous, irritable, and discontented with those who make them?

I smell a poll here!

Follow

Get every new post delivered to your Inbox.

Join 12,277 other followers

%d bloggers like this: