I have been doing some research on agile software development methodologies, specifically Scrum, and found the following videos.

• Pretty straight-forward concepts: Scrum Basics
• Another quick overview of Scrum: SCRUM in Under 10 Minutes
• Google Tech Talk with Jeff Sutherland: Scrum Tuning: Lessons learned from Scrum implementation… (This runs about an hour.)
• Goofy: Agile Development with Scrum: What they don’t tell you.
• Kinda long: Agile vs. Waterfall: A Tale of Two Teams

This is a useful technique to remember. Often project management tools such as Primavera or Microsoft Project are too heavy for communicating at a high level. Most of you stakeholder community needs an easy to understand picture of the project. Excel fits the bill for this.

Thanks to Ralph Phillips for sharing this tutorial.

I read an interesting post by Scott Berkun.  It is titled Are you a leader or a tracker?.  In it, Scott lists a group of questions to ask a project manager in order to understand what that person really does.  I summarize the questions into a couple key ideas.

• “Professionalizing” project managers has left many of them without relevant, hands-on roles.  I am finding that information technology executives (CIO, CTO) are wanting more hands-on project managers.  In other words, PMs who have a deeper understanding of the projects they are tasked with completing.
• Leading the team to the goal is more important than pushing them from behind.  If the focus is on tracking, what leadership value are you bringing?  It is easier to track.  (Hindsight is 20/20.)  Most teams need a leader who can put the next steps and the ultimate goal into better focus.

At the very least, if you are in a project management role, do a self-assessment using Scott’s questions.  Your answers may point you in a better direction that will increase your effectiveness and value.

1. Project managers learn how to fool the system and beat the metrics.
2. Often times, estimates are experienced guesses at best.  The practice that project schedules are typically built in a top down or bottom up approach, results in the accumulation of errors from the estimates.
3. It’s not typical that projects have the luxury of right to left planning.  Usually there is a business need driving the project schedule to a date.  Determining what can be accomplished in that timeframe is the realistic approach.

Although I have not had the opportunity to try this, I believe there is a better way to evaluate the effectiveness of project managers.  Each project should have a satisfaction score sheet to quantify the success of each project. (This can be done on a 1 to 5 scale of satisfaction with a space for specific comments.)

1. Rate the sponsor’s satisfaction with the project outcome.
2. List specific business goals that the project was trying to impact and score each one.
3. Poll project team members on the project manager’s effectiveness.
4. Ask the project stakeholders about the effectiveness of communication on the project.

The size of a project also matters when looking at metrics.  Small initiatives are easier to control and complete “on time.”  Large, multi-year efforts with sub-projects are more difficult to manage and measure.

If your organization is disciplined in terms of establishing timelines and budgets, you may be able to measure schedule and budget performance.  I am most interested in customer satisfaction.

I know someone who used to be a cashier for Kmart. They had a metric for average scan time.  Her time was the best in the store; because she figured out how to make her numbers look good.  She would arrange all the customer’s items with the bar codes ready.  Then, she would quickly scan each item and hit the subtotal button.  At first, the other cashiers were angry with her, saying that she made them look bad.  However, management caught on to what she was doing to get great numbers.  Guess what?  They trained all the other cashiers to do the same thing and the store’s numbers became the best in the district!

Yesterday, I was at Sears buying a dehumidifier. After making my purchase, I went to merchandise pickup.  I scanned my receipt and my name was added to the queue.  I looked at the screen and to my delight; the average wait time was 2.20 minutes.  Great!  I will be out of here in no time!  WRONG. I watched the worker and saw quickly that he was “Gaming the System.”  Once orders were added to the queue, he would take his hand-held device and mark all the orders complete.  Then, everyone would wait.  The metric looked great, but didn’t reflect reality.

Sears probably spent some serious money to develop this system, including lovely computerized voice prompts.  They probably use this average service time metric to determine staffing levels.  I can tell from personal experience that this store is probably under-staffed.  I didn’t have my watch on, so I don’t have the exact time of my wait, but it was much longer than the 1.40 minutes that was recorded. (I would guess that I waited 20 to 25 minutes.)

Sears could have the customer indicate that they received their item as the event that clocks the actual service time.  (Perhaps by scanning their receipt again.)  That would eliminate the “game.”  In this scenario, the customer starts and stops the clock.  (Also, the worker didn’t check my receipt. They probably have a shrink problem too.)

“Gaming the system” is easy to avoid.  You just have to observe the system in action and make adjustments.  Don’t set your metrics program to reward speed, unless you have an independent way to ensure accuracy.  Set it up to reward accuracy.  I can tell you one thing.  The workers at this particular Sears Merchandise Pickup area were not motivated to hustle.

The Professional Development Day will be held on October 7, 2005 in Des Moines, Iowa. A copy of the registration flyer can be downloaded here.