Networking after moving into a new role

This Harvard Business Online article on networking after a promotion caught my eye (link here).  While it’s pitched to the recently-promoted, it has great advice for anyone moving into a new role.  The piece starts fast:

Most people aren’t naturally networkers. But if you’ve just been promoted or are about to move into a new job, it’s imperative that you start talking to lots of people and make connections right away, so you can acquire crucial information about your new job and succeed early. If you don’t, you might lack the facts you need for a proposal, for example, or you might bring up an idea you think is neat but has failed in the past.

The three tips noted in the piece are just fine.  However, I particularly liked the two insights in the open about fact-gathering and avoiding already-failed ideas.  I’ve made these mistakes before, so I appreciated the reminder of the pain that a little stakeholder identification and planning can prevent.

Networking is definitely an unnatural act for me.  While that isn’t usually a deterrent for me, in this case it means that networking always goes to the end of my to-do list.  My best approach is to target and reach out per the article, then get short chats on my calendar with those folks immediately.  If I procrastinate, all is lost.  Per the article:

[T]he first 30 to 60 days are when networking matters most, because that’s when people are deciding if they can depend on you or if you’re a loser who should never have been hired.

Perceptions and Stakeholder Management

I very much like the sentiments expressed by Claude Emond on the Reforming Project Management blog. (post here, blog here).   Too many project managers assume that delivering high-quality work product ensures a high-quality project.  Claude explains how stakeholder management affects perceptions of quality:

[P]roject quality, a strong indicator of project success, does not only depend on the physical characteristics of project deliverables, it also depends on HOW they were delivered. It means that a project is not only a destination, it is also a journey. It means that in matters of quality, BOTH the journey and the destination are important.

Doesn’t that make sense?  The final destination may be your ultimate goal; but how many on-time, on-destination trips have you made where a terrible travel experience ruined the entire trip?  In that light, shared positive perceptions among stakeholders of the project, its goals, its deliverables, and how you got there are the real criteria for project success.

Don’t forget the “corner cutting” poll

I’m getting some good response to the “corner cutting poll” on the right sidebar of the blog itself, but I’ll leave it open for a while longer. 

For my newsreader subscribers, the poll’s direct URL is here:

Business Value Game — Prioritizing Requirements

While I haven’t gone through a live simulation of the game, I like a number of the concepts behind The Business Value Game (post here, game here).  Of course, I love learning through simulation (entire Complexity Set here). 

The game also has players assume the role of salespeople who have to prioritize the backlog that developers will have to implement.  This approach is great for both roles:

  • If you have salespeople play the game, they start to get a better feel for the real consequences of having made unfulfillable promises at deal time. 
  • As developers play the game, they should develop more empathy for the pressure that sales teams feel as they try to satisfy the customer and close deals.

Very promising stuff…  Now, when can I get the time to check it out?!

Pressure, Error, and Leading Project Escalations

While we’re on escalated projects it’s a good time to hearken back to Dietrich Dorner’s book on The Logic of Failure: Recognizing and Avoiding Error in Complex Situations.   Such projects are a high-pressure leadership environment, for sure.  It is critical to have no illusions about what lies ahead, especially in the Discovery (here and here) and Decision (here and here) parts of the leadership pyramid.

Ken Thompson’s The Bumble Bee blog at highlights two “tangents” identified by Dorner.  These are common leadership failure modes, largely because they are very tempting to pursue during a crisis.

We may resort to “horizontal flight,” pulling back into a small, cozy corner of reality where we feel at home … Or we may resort to “vertical flight,” kicking ourselves free of recalcitrant reality altogether and constructing a more cooperative image of that reality. Operating solely within out own minds, we no longer have to deal with reality but only with what we happen to think about it.”

Read all of Ken’s post here.  Note his great tips on how to deal with a “flying” leader.

Manage your own job description

I’ve been reading The Intelligent Leader blog on  It channels a lot of content from the Harvard Business School, but don’t hold that against it.  The editor Scott Berinato strikes a good balance between of syndicated content and fresh comment.  The Management Tip of the Day is a nice feature as well.  Today’s entry hits on a common issue for project, program, and portfolio managers:

Most managers sabotage their productivity by grappling with an endless list of demands from others. They assume — wrongly — that those demands are requirements and that they have no personal discretion or control over their jobs.

In the tech industry, this trap is an almost universal rite of passage.  When you hear someone described as “not strategic,” it is because they’ve made themselves “order takers”.  They include one set of tips, but I though it was worth modifying them below:

  • Slow down — that is, don’t immediately react.  You’ll be surprised how many demands simply disappear.
  • Set priorities — and insist that requesters do the same.
  • Stick to those priorities — and point out mutually-exclusive or competing priorities to others.

The executive I report to is excellent at handling such requests.  He clearly indicates that our organization wants to do whatever is best for the firm — but “best” means we’ll have to ask questions and insist on transparency w/r/t the request’s impacts.  Does our requester understand the impact on other priorities (sometimes the requester’s own)?  Who is the sponsor for this?  What will the executive team say when we go for approval?

Diagnosing “Pakled Customer Syndrome”

Please give my brother a hearty welcome to the blogosphere, where he is now shamelessly flaunting his Spargel obsession. 

Stephen’s just getting rolling, but I can’t resist linking to his re-telling of one of my favorite development war stories: Pakled Customer Syndrome.  Star Trek TNG hasn’t aged very well at all — my episode yield is about ten percent — I last an average of six minutes then I can’t stand it any more.

However, anyone who has had stakeholders with alternative agendas will get a few chuckes from Samaritan Snare.  Not that I’ve built a Crimson Force Field

New Poll — Corner Cutting in Project Management

Inspired by a post on Sharp End Training’s blog (here), my post (here), and a comment by PM Hut

FYI, moved to right sidebar

Corner-cutting in Project Management

Elizabeth included this post from Sharp End Training’s blog (here).  I agree with her assessment of the post.  It is a good question but I would have like to seen a take on which corners are typically cut, not why corners were cut.  FWIW, here are my top ten corners typically cut:

  1. Stakeholder management planning
  2. Executing planned communications with senior management
  3. Executing planned communications with non-project stakeholders
  4. On-going risk monitoring and control
  5. Communications planning
  6. Risk response planning
  7. Integrated change control, especially for changes in resources
  8. Performance appraisals for project team members
  9. Quality planning
  10. Contract administration

I’d appreciate any comments on where “corners are cut”…  Perhaps this will make a good poll question?

The relationship among scope, time, resources, quality, etc.

Thought-provoking post by mysticMundane on the Triple Constraint (here) — hat-tip to Michael at IT Project Failures (here).  IMO, both yielded good insights, with some caveats.  The good:

  • I always like to see quality included as essential to the triple constraint — Michael has the picture here — the scope isn’t delivered unless the work product conforms to requirements.
  • Scope change control is impossible without a baseline.  Good luck trying to get changes when the only baseline is a vague statement that the project is supposed to “boil the ocean.”
  • I like the second graph (here) with reservations…moving the scope frontier out nicely shows how hard it is for each time/resource combination to satisfy the new scope.

The caveats:

  • While I understand their intent, the graphs make it appear that scope is a function of time and resources.  Perhaps building each product feature can be represented by that, but is simply summing “features delivered” the scope? 
  • Do we fully understand scope deeply enough; in particular, isn’t the project ultimately supposed to create deliverables that generate benefits over time?  My experience is that too many project managers focus solely on features, which are derived from the business benefits, the deliverables, and their requirements.  Continue reading
%d bloggers like this: