pmStudent

Dux Raymond Sy shares his 3 lessons learned while we were at the PMI North America Global Congress:

• Keep re-affirming customer expectations and priorities
• The difference between influence and interest - who is writing the check?
• Be a project facilitator and leader, not a control freak!

Lastly, Dux shares his thoughts about the conference.  Then of course I had to open my big mouth and add my opinion to Dux' second point about who is really influential on your projects.  From there we have some good back-and-forth conversation on related points and the acknowledgement of project management at high levels of government and corporations. 

(Notice the awesome Gantthead shirt I snagged while I was at the conference!)

Bas De Baar asks Josh Nankivel about what Kanban is and how he is using it with his teams, and how you can get started using Kanban for yourself (personal Kanban) and your project teams.

I've been asked about this recently, and thinking about it on my own too for my own teams.  Here are some guidelines I suggest for myself and others to evaluate existing cultures and create new  project performance measurement processes that are meaningful and do what you want them to do.

1.  What Adds Value?

Measure only what gives a true picture of performance and adds value.  What impacts the bottom line?  Are you REALLY going to use the data you are gathering?  If not, why are you gathering it?

2. Don't Measure Everything

Project managers can be a controlling bunch.  Many of us want to measure EVERYTHING.  In my experience, there are probably around 3 things you want to measure some aspect of.  Not much more, and not much less.  This has held true for me across multiple industries and some examples from my past include a) cycle time/velocity b) customer/stakeholder satisfaction and c) on-time delivery.

3.  Stay Out of the Weeds

I've seen detailed gathering of performance metrics you wouldn't believe.  Be very aware of the balance between level of detail and the effort/morale of the team to report the detail.  If people start asking for a new charge code to account for the time they are spending accounting for their time, you've gone too far!

4.  Consistency

Be consistent.  "Flavor of the month" means gaming the system, not a focus on performance.  Whatever your objectives are, they had better have a life span of more than a month or a quarter.

5.  Beware of Gaming

Beware of gaming the system.   If possible measurements should be so transparent that gaming is not possible.  Self-report data is prone to this, even unintentionally and subconsciously.  This is why objective measures like physical percent complete and cost/schedule performance data from an external group is so important.

6.  Focus on Methods

Don't use metrics for an incentive program of any kind.  For instance, don't penalize people in any way for their estimates being wrong.  If you want to get better at doing estimates, great.  Focus on methodology, not who was close or not close on their estimates.  Use the results as an indicator for what is working and what needs improvement.

7.  Eliminate Internal Competition

If your performance management system is generating competition between individuals or teams, you're doing it wrong.  In the call center world you see this all the time with "contests" that pit teams or sites against each other.  These result in animosity towards competetors and incent a decrease in quality in favor of whatever the "flavor of the month" stat is you are touting in the contest.  They usually create the appearance of performance.

"Hey, what do you know?  We made call handle time a key metric in this contest, and our average call handle time went down!  Yippie!"  (You're doing it wrong)

Customers, teams, and organizations lose.

Yeah, me too.

So how do we get out of the sand trap in a dynamic environment where it seems like you are being pulled in a thousand directions at once?

It's not easy, but here are some of the things I do and am trying to do to stay on solid ground.

Kanban

Personal Kanban and team Kanban.  It's wonderful, I love it so much!  It helps me manage what's going on right now and in the near future for both of my teams, myself at the day job, and for myself at my pmStudent.com office.  Yep, I have 4 Kanban boards total.

I won't go into what it is and how I use it here since I've posted already about Kanban, but feel free to check these out to learn more.

Meetings

They need to be effective.  That means focus, having the exact people who add or gain value (no more or less), and as short as possible.  Help your team and yourself escape from meeting hell.

Email

Only check it at a few scheduled times during the day.  Turn notifications off.  When you do check it, everything that can be resolved in a few minutes is done immediately, everything else goes into your personal task management system (mine is Kanban).  I have a filter which shows me only unread email, and each time I check it, my email box goes to 0 unread messages.  No folders for me, everything stays in the inbox but is out of my sight because it's unread.  I've tried a lot of things, but for me this email management system has shown itself to be the best.

What do you do to keep your head above the sand?

photo by Pink Sherbet Photography

Sometimes, external dependencies want to make me shake my fist in rage.

But that's not how it should be.

A critical factor when planning a project should be a risk analysis, not only for the project as a whole but also for individual autonomous groups within the project when there is collaboration going on between the following:

• multiple self-funded groups within an organization (not just one 'project' pot of money)
• multiple companies/agencies
• multiple contracts/vendors

Emotional Responses

However, here's what will happen when you propose a risk related to a depedency external to your immediate group:

• "Hey, we're all one big team here.  Aren't you a team player?"
• "Ummm...  Politically, I don't know if we want to carry our collaborators as risks."
• "XYZ does a great job.  They'll never be late!  How dare you insinuate something could go wrong?"

Let's get past the emotional responses now.  We want to openly acknowledge areas outside our control, that is the important thing.

Transparent Structure

Perhaps you don't carry these external dependencies as risks (although I would) but use them to build a structure into your plan which makes these dependencies obvious.  Making these external dependencies transparent would be a part of my mitigation plan in the risk management process.

Why make them transparent?  A primary reason is so that if an external group's deliverables slip on the schedule and you are dependent on those deliverables, a red flag is triggerred and an appropriate response can be acted on.  One reason why I advocate carrying these touch points as risks is precisely so that a risk response plan can be formulated ahead of time, and if the risk becomes an issue you can act on a solid plan that wasn't just thrown together in the heat of the moment.

Example

If a vendor is developing something new that is an input to your development process, try to structure the work so that the pieces dependent on the vendor are separated from other work.  You might plan a separate release just to incorporate the vendor's new technology. 

If you don't do this, late or incomplete deliveries from the vendor will get pieced into your development life cycle and reworked, reworked, reworked as new updates arrive. 

If you call the external dependent deliverable separately in your schedule, there is something you can point to if and when things go bad.  This is not to place blame; in my book blame has very little use. 

No, it's to make it crystal clear which group needs to have their feet held to the fire so we can deliver this project on time.