The Hard-Nosed Project Manager

Over deliver

I was reflecting this morning on the “under promise but over deliver” maxim which I believe is attributed to Jack Welch.  What prompted this reflection is a podcast that was discussing the expectations of a pharmacist’s clients; really not project management related.

In my line of work, like many lines of work, we can’t “under deliver” as testing will catch up to us.  If you “under promise”, you simply won’t get the job.  Economics mean that line managers don’t want us to over deliver and again, testing would not allow that either.

I wonder, and I’d like for you to chime in, if it would not be good to over deliver not on scope but on project management and especially on communications.   It may cost a little bit more and not be reimbursable but I believe it would create significant goodwill and give an incentive for repeat business.  Works for me…

What do you think? As always questions and comments are welcome.

Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

 

Updated: Human Resource Project Management CoP webinar; 2/28 at 11h00 Eastern - Effectively Managing Project Resources

There will be a Human Resource Project Management CoP webinar titled "Effectively Managing Project Resources" on 2/28 at 11h00 Eastern.  Those who can’t attend should look for my comments after the webinar.

Update:  I won't be able to attend due to professional commitments.  I will listen and comment on the recording when it comes out.

Updated: Innovation and New Product Development CoP webinar; 4/17 at 13h00 Eastern - Four Skills You Need to Survive an Agile Project

Just to let all know that this webinar has been pushed again to 4/17.  I will not make an easy joke about agile scheduling...

Tearing Down Project Barriers Between the Business and IT webinar

Today I listened to the recorded PMI IS CoP webinar called Tearing Down Project Barriers Between the Business and IT.

The webinar speaks to IT as a tool to achieve business goals of an organization as opposed as IT as its own beast with it own goals.  I believe the same focus, on business goals, should be applied to other business entities like marketing, accounting, and production (includes engineering, construction, software development, etc.).  Business entities serve the business, not the other way around.  Just look up business score card approaches for more on the subject.

The webinar identifies problems with project inception or concept as a major culprit.  Imprecise scope, inflated expectations, immature technologies, and hype.  Business user many not speak the language of your domain; you have to align and adapt. Business users may want something that is hard to do but you have to help them understand that and that difficulties may have to be surmounted for them to get what they need.  Hype usually “forgets” that there are implementation difficulties. 

Alignment between stakeholders or business entities is essential but very tough to reach.  By the time the project is recognized as such, expectations (realistic or not) have already been brewing for a while.  Often time the inception process has been going on in a vacuum.  Various stakeholders may add requirements that satisfy their business entity but take the “project” away from actual business goals.  Think of a product designed to sell at a given price point; it may not be enticing to the consumer because it lacks certain features.  Think of a product designed to yield a given profit margin, it may be very inexpensive to produce but no one wants it because it is perceived as cheap.  Think of a product that I seen as easy to bring to production; maybe it is already obsolete compared to what the competition has.  Also, if the expectations are not aligned with the capabilities of the organization, there will be pushback from the project team.

Gaining alignment requires active guidance.  This process documents requirements, assumptions, risks, organization capacities, etc.  At this point you have a project manager, maybe a system architect, maybe a business analyst, maybe a quality assurance person, but no project team.  At this point you are just not ready to roll.  If you did you may run into one or many walls around technology, schedule, or economics.

Maintaining alignment also requires guidance.  The same team of people guides the project team in staying the course, preventing scope creep and likely unmet expectations on features, schedule, or cost.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

Years ago in Nottingham

Eons ago I was working on a project in Nottingham, UK.  One of the guys from the plant stole, from one of their managers, and gave me a book called "Malice in Blunderland".  This is not the book you'd find these days on Amazon but rather a collection of business "laws" like Peter's Law.  Entertaining in a kind of scary way.

I listened to Episode 230 of The PMO Podcast entitled "George Costanza's Top 10 Tips for appearing to be a good Project Manager" which reminded me of those days in Nottingham.  Give it a listen, it 12:17 long and worth your while.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Focus on the Management of Uncertainty and Risk webinar

Today I listened to the PMI Risk CoP webinar on Focus on the Management of Uncertainty and Risk.

The presenter covered the worst offenders in risk management, in particular not looking far enough (being too conservative), not looking at opportunities (having only dark glasses), and making risk management a once a project activity.

As a corollary, some takeaways are that:

• You also need to look at the bright side of risk management and at opportunities.
• You need to look deep for risks.  The tsunami in Japan proved this as three mitigation strategies (at least) failed in Fukushima.  If you use a checklist for risk management, it should be only a starting point, not the end of the effort.  If a risk cannot be mitigated, transferred, etc. it still need to be on the register or you will be blindsided.
• Be disciplined; review risk management at each team meeting without fault.

On other topic that was discussed is the confusion that often happens between risks and decision that have already been taken.  Nothing that has already been decided in a project is a risk, it may not happen; it HAS happened.  Many manager keep on monitoring their projects for things that have already happened.  That is a waste of time and the item should be moved off the risk registry.

Another way of getting in trouble is devoting the same effort to a risk with a low impact as to a risk with a high impact.  A bet the company risk should get much more of your attention.

Of course the webinar did not limit itself to these so I encourage you to listen to the recording.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

Leadership Skills for Managing Projects 2 of 2 webinar

Today I listened to the PMILearning Education and Development (LEAD) CoP webinar on Leadership Skills for Managing Projects, part 2.

The presenter discussed the culture of leadership as a success factor.  I would second that and add that a culture and attitude of success is also necessary.  Believing that you will succeed does not guarantee success but it makes it easier than always living under a cloud.

Also discussed was the good of the team instead of the good of the leader.  I guess you can call that servant leadership. The project is the goal, the good of the team is the enabler and the good of the leader flows from the first two.  The leader must foster the good of the team to achieve the goal and must show backbone if and when the going gets rough.

One item that I don’t hear too often is the special status of the leader in the team.  The leader must care for other team members while not expecting anything for him, listen to all information and opinions, and also keep some distance so as not to show preference for particular team members.  The army teaches leadership like that while the corporate wrongly sees the leader as just one of the guy.

The honor (respectability) and fairness are highlighted as providing the basis for the power of the leader.  Fear is also mention but of course that should be used sparingly, if at all.  Again, when I was in the army, some leader where fond of the saying “I don’t care if they love me as long as they respect me”.  Very true; team members may not love you but if you are respectable and fair they will respect you.  If they fear you they won’t.

One thing I don’t agree with is the Forming, Storming, Norming, and Performing of team.  I do believe that once you have gone through the first three steps at that you have a performing team you should apply the same team to the future projects instead of forming a new one.  It is much less costly both in money and ego in my opinion.  See my previous posts on the subject (1, 2).

The webinar ran long and a very good pace; there might have been enough for a three part webinar.

Sound quality was good with very little warbling and just a few cuts.  That’s a first with Adobe Connect.  And the bad lag from the presenter was also gone.  Kudos.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

Communication is everything

It is said that project management is mostly a people/communication thing.  Yet most communications are handled badly, especially communications about exceptional events or situations.  When things go wrong or off the beaten path you have to make sure that you message is understood.

Let me tell you about an hypothetical (not really) situation.  You are coming back from a business trip and your flight from Raleigh, NC to Montreal, Canada makes you transit through Newark, NJ.  You notice when you check-in that the flight number is the same for both legs of the trip, let’s say CO 5153, and you are given only one boarding pass.  You’ve seen this before a few times, it means the same plane will go to Montreal after Newark passengers deplane.

You get to Newark were the friendly flight crew thanks you for flying with them and announce that this is the end of the flight.  You’re puzzled and ask an attendant.  She looks a bit confused but tells you have to deplane too.  More puzzlement on you part because, in the past, you stayed on the plane in those situations.  Must be a security thing you think.  You deplane.

As you walk out you turn around and see that the gate announces a Montreal flight 2 hours from now.   Great, a delay!  You do not check the flight number, it says Montreal, right?  You walk around a bit and see another gate, with your flight number, departing in 5 minutes.  Rats!  You board and get to destination on time.

How many occasions where missed to properly communicate about an atypical situation?  Could this have been handled better?  Do you ever assume that your project stakeholders will , by themselves, understand there is a problem, that it is being handled, that they agree with the way it is being handled, and that they will have a common understanding?  Food for thoughts I think.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Communicating Change with Seven Questions webinar

I just finished listening to the “Communicating Change with Seven Questions” with Peter de Jager presented by the PMI IS CoP.  I should have let you know in advance but…

I must say it was both entertaining and informative.  It spoke about change but mostly about communications, minimizing push back, and getting people on board with change.  I highly recommend you listen to the recording.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Should You Let Your Employees Work From Home?

I found this on LinkedIn yesterday (8/18/2011) but since I did not comment fast enough the source had to be fond again.  So, thanks to the power of the Internet…

Some parts of the chart are “cute” (a polite way of saying stupid…) and some arguments weak (employee playing World of Warcraft) but it is still interesting and useful.  I’m partial to working in the office because it gets me out of the house and because people have less on a tendency to lie to you face to face.  But that is me.

Most people tell you the truth most of the time and if someone is playing World of Warcraft at home on a business day he should be fired anyway.  I say let people work at home as long as they you give them tools to facilitate communications and to securely exchange data.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.