Lacking Empathy

As a project manager, I personally believe empathy is one of the most important virtues.  I think it's one of those attributes that makes us most human.  You can't expect to take care of your team, or even customers, if you are unable to be empathetic.  Regardless if you can help someone, ask anyway.  Regardless if you can understand what they are thinking or feeling, try anyway. I recently participated as a juror in a criminal trial.  Though I knew it would be a personal inconvenience, I did it because I thought it was the right thing to do.  It was my obligation as a citizen, to do my part in ensuring justice was served.  Some would argue if it truly was, but I digress.  So, what's the point of this blog post?

About a month ago, I informed the necessary (corporate) parties who pay me that I had been selected to be part of a jury pool.  Upon sending them the necessary information, I was told I would be paid for a full 8 hour day, minus $20. (The amount Frederick County pays a juror for one day of service).  Considering the cost to short my paycheck was probably more than $20, I wasn't going to argue.  If that's what they wanted to do, it was a wash for me, with the exception of the work I had to delay for my customer.

Upon submitting my hours on the second day, I received a (billing) submission error.  Because it was an ambiguous error message, I send an email to accounting.  I said, upon completing my second day of jury duty and billing my time, I received the error.  Within a few minutes, I received a very short email response. It informed me I would only be paid for 1 day of jury duty, that "it's in the handbook" and I would have to bill my time to my Paid Time Off (PTO).  I was surprised I didn't get a "I'm sorry if there was a misunderstanding..." or "I regret to bring this to your attention..." email.  Seconds later I got another email.  It was one line.  "You can also take Leave Without Pay".

Let's take a moment to reflect.

Both of these emails came from the Human Resources department, not from my direct chain of command.  I did get a telephone call from my Director within a few minutes.  He apologized if I had misunderstood the corporate policy to only pay employees for one day of jury duty but added he would work with me if I had already made plans that would result in a PTO deficit.  I want to commend him on having empathy.  He showed true leadership in picking up the telephone and calling me.  He showed true leadership in listening to me vent for several minutes.  It didn't change anything but he certainly scored a few points in my book.

We're all human beings.  We all like to be treated like human beings. When in doubt, pick up the phone or go talk to someone directly. Most importantly, don't ever send a one line email that basically says "RTFM"

Like the image?  Find it at Pictofigo

Reasonable Doubt

This last week, I had the honor and frustration of serving on a jury in a criminal trial.  By working with so many stakeholders in my day-to-day activities, I figured it shouldn't be too difficult to use the same methods with witnesses and with my jury peers.  What was the goal?  Given the evidence, presented by both the prosecution and the defense, decide (as a group) if the defendant had been proven guilty beyond a reasonable doubt.  Unfortunately, being a juror was unlike managing regular stakeholders, where they can all maintain their own perspective throughout a project.  As a member of the jury, we had to offer a unanimous verdict; Guilty or Not Guilty.  The other very challenging thing we dealt with was a subjective term (compared to objective) called reasonable doubt.  Until all of the evidence was presented and we were asked to deliberate on the verdict, we were not allowed to speak to each other.  Only at that time were we able to define what reasonable doubt was.  Only then were we allowed to compare notes from the trial and come to a collective agreement. So that you understand why it was so challenging for use to reach our verdict, I'll condense two days of testimony into a few paragraphs.

The victim was a 73-year-old woman.  The defendant was a 21-year-old man.  After arriving home from taking the bus one dark winter night, the victim said she was assaulted by the defendant on her doorstep and her purse was stolen.  When she appeared on the stand, she said she had never seen him (the defendant) before but she would never forget his face.  When interviewed by the police the night of the attack, her son who lived with her told the police that she described the attacker to him as looking like the boy who had helped her with her groceries in the past.  The son knew who had helped her in the past and gave the police a name.  The victim was sent to the hospital and the police met her there with a series of photographs to make a positive identification.  She pointed to the defendant's picture and then another saying it he looks like him but then pointed back to the defendant and said that it was him, adding that he was on the bus with her that night.  The officer did NOT circle the photo like he normally did, when a victim makes a 100% positive ID of an attacker.

The day after the attack, the defendant was interviewed by the police.  He said he remembers seeing her on the bus but he could never do such a thing to her.  He said that he had helped her with her groceries in the past.  When he was asked where he was at the time of the assault, he said he was at his cousin's house playing video games.  Oddly enough, the cousin never appeared in court to corroborate his story.  When the cousin's wife testified, she said he was not there that night.

There was no other evidence offered.  The contents of the purse were never found.  The cell phone and food stamp card in the purse were never used.  So, what happened when the jury was asked to deliberate?  We compared notes and we debated.  When the foreman asked how many of us thought he was guilty, almost all of us put up our hands.  When the foreman asked who thought the prosecution had proved his guilt beyond a reasonable doubt, everyone put there hands down but one guy.

We needed to have 100% agreement.

My argument to him was, it would be a terrible tragedy that IF this guy would be convicted of a crime for no other reason than he had helped this lady with her groceries in the past and he was on that bus that night.  Nobody was debating, including the defendant, if he was on the bus or if he had helped her with her groceries before.  But nobody could prove that he was at the scene of the crime.  By reading his body language, several of us believed he was not an innocent person but we were uncertain he was guilty of this particular crime.  The final juror lamented and we rendered a verdict of not guilty.

The defendant burst into tears as our foreman stated not guilty to each of the three counts.  The prosecution then asked each of us to stand and respond guilty or not guilty.  One by one, we responded "Not Guilty".  The judge told the defendant he was free to go.  We were then told to return to the jury room.  We all agreed we should have felt more satisfaction in freeing this guy.  Moments later, the judge entered the chamber and informed us that the defendant had been charged in the past with the same thing, assault and theft.  She said the court was not allowed to give us this information and added that she believed, based on the evidence presented, that we would find him not guilty.

As I shook my head, the juror who sat next to me in the jury box said the right thing.

Though knowing this guy has done this before kind of bothers me, but I would rather set a guilty man free than to convict an innocent one.

Image: Pictofigo

Using Stories on my Personal Kanban

A colleague on Twitter asked how do I break down my stories, acceptance criteria etc?  As a reference point, "stories" refer to my use of User Stories on a task board or Kanban.  It's a method of representing requirements or scope.  In upcoming posts, I'll also write about acceptance criteria, size, blocks... Let's say you have some work that needs to be completed or delivered (scope).  Rather than the old fashioned shall statements to define the scope or requirement (system shall do this; system shall not do that), we're going to write a little self-contained story on an index card, post-it note, or something similar.  When we're done, we're going to add the story card to our kanban board.  Our user stories are written from the perspective of the user.  In the case of the personal kanban, that's me.  What you put in your user story may vary. But, for me, the stories have to be self-contained and they have to pass my "why" test.  Though I don't write it in the user story or on the card, I map work I do back to higher level goals.  If the work can't be mapped back to previously defined goals, I'm just wasting time.  Let's try not to do that.

When writing a user story, this is the format I follow

As a <type of user>, I want <goal> so <reason>.

Here it is in action

As a blogger, I want to write a blog post about user stories, so people will understand how I use them.

Now I ask myself "why". What is my predefined goal that it maps back to?

Spend more time writing, speaking, and mentoring and less time directly managing or leading projects.

So, there you have it!  Because I use both an electronic kanban and a physical one, I keep all of the details in the electronic version and use the physical one a visual reference.  It is a constant reminder to myself and others of what I am committed to do, work in progress, work that is blocked, and work recently completed.

Have any question?  Feel free to leave a comment.

Zombie (Stakeholder) Management Strategy

Today we're going to learn a little about zombie stakeholders. Now, I know you're a little apprehensive.  You don't believe in zombies.  You believe your stakeholders are just a little bit different.  Well, I'm sorry to break it to you but that's not a stubborn human wanting to arm-wrestle you for that last danish.  That there's a zombie!  How else do you explain that persistent stubbornness?  Now, stakeholder zombies are a little different from regular zombies.  Rather than brains, these zombies are highly unique and you much adapt to each one independently.

The Undead Stakeholder

Myths and Realities

Here are some specific background data. The first is a fictitious virus called "Solanum" that creates a zombie. The virus is spread (such as through an open wound, when coming in contact with infected blood or saliva), and treatment is limited (usually amputation).  Now, there was a mutation of the Solanum virus around the time PMI was created.  This mutant virus was known as Solanum-3c (Solanum-3-constraints).  Chances are it will only infect your stakeholders but you, as a project manager, may still be a carrier. In reality, stakeholder zombies walk among us.  You just have to be on your toes when you're around them.  They will try to infect you.  Don't let it happen.

Weapons and Combat Techniques

The weapons at the average project manager's disposal aren't quite a dramatic as those used on regular undead. For regular zombies, a common M1 carbine and the machete are highly effective.  For stakeholder zombies, finding out what's important to them will stop them dead in their tracks.  Different stakeholders have different needs. Zombie stakeholders are no different...with the exception of tattered clothing and a greenish skin tone.  If they say Brai...cooooooost, focus on cost.  If they say Brai...delivery date, focus on the delivery date.  All zombies want brains first.  They can't help it.  But, after that, find out what is important to your zombie stakeholder and make a note of it.

On the Run

If you're dealing with regular zombies, you need to know rules and necessities of traveling through zombie-infested territory. If you're going to drive a car, make sure you have keyless entry and the windows are rolled up.  Do NOT touch the zombies!  If you're dealing with zombie stakeholders, don't run.  If anything, get as close to them as possible.  If given the choice of interacting with them over the phone, through email, or in zombie (in person), choose to interact with them directly.  The more attention you give them, the quicker you can react to them and their needs.

On the Attack

Though some believe in avoiding zombies at all costs, which you should, there are strategies and tools to eradicate zombies from an area.  For zombie stakeholders, we don't want to eradicate them.  Rather, we just want to make them happy.  Find out what makes them happy!  Now attack.

Conclusion

Though you don't want to get close to regular zombies, you should try to engage the zombie stakeholder.  Know what's important to them.  Understand their needs.  I've made the mistake of sitting in a status meeting with regular zombies.  I asked what they wanted to see in the next release.  The answer? Brains.  I asked how could I streamline communications?  The answer? Brains.  I drank my coffee and ran.

Don't think the Solanum-3c virus is limited to stakeholders.  Elizabeth Harrin over at A Girl's Guide to Project Management wrote an excellent post on zombie project managers. Be afraid.  Be very afraid.

Graphic: The Daily Pennsylvanian

Assumptions and Constraints

I turned to my wife last week and asked what our plans were for the weekend. She countered by asking me if there was anything specific I wanted to do.  My answer was I wanted to eat somewhere featured on Food Network's Diners, Drive-Ins, and Dives.  One quick search and a YouTube video later, and we had our Sunday planned. We were headed to Baltimore for lunch at Di Pasquales Marketplace. I could taste it all now. Mmmmm, homemade paste, sausage, and mozzarella.  After lunch, we'd head to the Inner Harbor and enjoy the beautiful weather. This is where my personal story ends and my project management story begins.  As I've said before, everything in life points back to project management.

Imagine our weekend adventure was a project.  We planned our little outing for Sunday.  We assumed Di Pasquales was open on Sunday.  We were wrong.  We discovered if we wanted to go to Di Pasquales, our time constraint was Monday thru Friday: 9 a.m. - 6 p.m. or Saturday: 9 a.m. - 6 p.m.  Fortunately, we had a plan B.  Always have a plan B! I added our trip to the backlog and we picked the next highest priority from the list.

Here's my little read world project management advice for today.

1. Don't start a project, until you know your assumptions and constraints.
2. Get buyin from stakeholders to ensure you are all in agreement on priorities.
3. When making a proposal, always have a plan B.

Since we were not able to go, perhaps we'll go next weekend.  Regardless, if we had not identified our assumptions and constraints, we could have found ourselves eating somewhere less desirable and "wasting" the day.

Luck versus Opportunity

Luck is what happens when preparation meets opportunity - Seneca (Roman philosopher). Yesterday, I finally pulled the trigger on transferring the blog from Godaddy to PowerVPS.  I saw an opportunity to transfer my blog over to cloud hosting versus just sitting on a shared drive.  My blog now joins my other properties, PM Prep Flashcards and PDU Library. In the days leading up to the transfer, I made sure I had my recent backups (both files and databases).  Note that my app developers are distributed and using Subversion so source code has always been safe. The only thing at risk was my blog and I have multiple copies in multiple locations.  If you're reading this, it means we're running on new hardware and a new network.  For the most part, the transfer went well.    There never seems to be a good time to transfer a domain and when you have a blog running on Wordpress, you also have to be prepared for a few hiccups.  If you're lucky, you don't run into any issues.

Well, the site is about 95% up.  Because I still need to configure email, related to the domain, I don't have the contact form displayed.  I also have a few back-end issues, each related to server configuration.  None are a big deal and I think the site will be 100% by the end of the day.  Now if only the DNS would propagate the change in IP faster.

I look forward the future, now that this one monkey is off my back.  I'm not 100% rid of Godaddy but I learned some lessons from this domain transfer.

Brain eating Zombie PMs

There are 3 things that spark my attention faster than anything.

1. Coffee

2. Zombies

3.

Damn ADD robbed me of my thought!

But I digress.

This morning, I read a blog post by Elizabeth Harrin titled Zombie Project Management. It reminded me of a series I read by Geoff Crane titled 9 Destructive Project Management Behaviors, which you can get for free by following the link. I really enjoyed her post and I hope you go over to her website and check it out.

Elizabeth wrote

So, what is Zombie PM? Does this sound like someone you know?

They do exactly what they are told without challenging anythingThey don’t come up with original ideasThey don’t suggest ways to improve the project management processesThey don’t follow up on actions – they simply assume they will get doneThey update and issue the plan in a format that most of the team can’t read or understandThey work on projects that deliver no business valueThey go through the motions of being a project manager but without any critical thinking applied

To answer Elizabeth's question, yes, I see these zombies every day. These zombies contribute to what is defined as the Iron Law of Bureaucracy. It states, in any bureaucratic organization there will be two kinds of people: those who work to further the actual goals of the organization, and those who work for the organization itself. One example in project management, would be PMs who work hard and look for ways to deliver value to the customer, versus PMs who work to protect any defined process (including those with no value). The Iron Law states that in ALL cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions.

These zombies don't eat brains, they eat time and resources in the name of project management! So, sooner or later, zombies will take over your project. Be afraid. Be very afraid!

Principles Behind The Twitter Manifesto

We follow these principles: Our highest priority is to satisfy the follower through early and continuous delivery of valuable tweets.

Welcome a changing Twitter stream, even late in the day. Twitter processes harness change for the follower's informative advantage.

Deliver working links frequently, from a couple of hours to a couple of days, with a preference to the shorter timescale.

Tweeters and followers must work together continuously throughout the day.

Write tweets around motivated followers.  Give them the environment and support they need, and trust them to get the retweet done.

The most efficient and effective method of conveying information to and within the Twitter community is continuous conversation.

Reading informative tweets is the primary measure of progress.

Twitter processes promote sustainable tweeting and retweeting. The tweeters, followers, and twibes should be able to maintain a constant pace indefinitely.

Continuous attention to tweet excellence and good spelling enhances retweeting.

Simplicity--the art of maximizing the amount of letters not used--is essential.

The best blog posts, pics, and links emerge from self-organizing twibes.

At regular intervals, the twibe reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Thank you to the authors of the Agile Manifesto.  Without it, my life would have less direction and this post would have even less value.

Graphic: Pictofigo