pmStudent

In projects and in life, difficult choices come up all the time.

I had a schedule conflict with the PMI North America Global Congress this year. This year I was going to do a joint presentation again with the PMI New Media council, where I would have been speaking specifically about implementing Kanban with virtual teams.

The conflict was a local conference regarding education and advocacy for disabled children and adults. I'm very active in this area and was recently appointed to the South Dakota Council on Developmental Disabilities. Attending the RehabACTion & Transition Conference would be educational for me and help me do a better job in my role on the council.

What To Do?

As project managers, we are also faced with difficult decisions all the time. Here are some helpful techniques I use on a daily basis to make decisions.

Engage Team Members and Encourage Dissenting Views

One of the most important things you can do is listen to the opinions of others who have a stake in the decision and know something about the options involved.

Even if the final decision is yours, listening to diverse perspectives on the topic helps clarify your own thinking. The Vatican used to have a 'devils advocate' policy where someone was assigned to get as much 'dirt' on a candidate for the Papacy. This encouraged dissenting views.

On my teams, I've found in some cases I need not actively pursue dissenting opinions. One of my teams just has the culture of personalities that everyone makes their own views known and are not afraid to pronounce them aggressively. This is awesome, but not all teams gel like this naturally where everyone is friends and pokes fun at each other, etc.

On another team I do have to actively seek out dissenting views. My favorite technique for this is to read the tone and body language of team members when discussing a decision that needs to be made. I select a few who I think may not like my preference by asking them directly but with a gentle smile, "[name], I would like you to tell me why this is not the right decision. I want to know why this is a bad idea, because it might be."

It can take new teams awhile to adjust to this, because almost no project manager actively seeks out dissenting views. They will likely be hesitant at first, and may even feel like you are picking on them. With a new team, I will sometimes tell everyone ahead of time that I want them to come up with at least 1 reason why each option is a bad idea. I do the same. Then we share our negative opinions of each option. This makes the team comfortable with voicing their opinions by demonstrating that I value their input, regardless of whether they agree with me or not.

The most dangerous thing a project manager can have is a team of 'yes' people.

Write It Down

I also love the process of writing down pros and cons of each option in a decision.

The act of writing it down helps me ensure I've thought thoroughly about each option. In many cases I discover questions I hadn't thought of previously when I go to write the context, pros and cons of each option down.

Specifically, I like to think in terms of value. What value is added or taken away with each option? If you don't use something like value-added as a criteria, you can still end up deciding on what 'feels' better, which is a bad idea. Human intuition can be great, but it goes wrong with complex decisions more often than it goes right.

In The End

I decided that I'll add more value to the world by attending the disabilities conference than I would by presenting and attending the PMI Global Congress. It was a difficult decision still, but I'm confident I made the right one.

My team members in this case were my wife and some close family members. When I wrote the options down, it became clear the primary benefits for attending the PMI conference were networking with people there and the prestige of speaking again at a large project management conference. However, the majority of the people I interact with at the PMI Congress are not engaged with my target audience for pmStudent, which is new and aspiring project managers. The majority of the companies and people in this space focus on things like delivering PDUs, consulting for companies, etc.

When it was written down, it became evident that I can add more value at the disabilities conference - especially in terms of value to others. So while I'm sorry to miss this year's PMI event, I'm also confident I've made the right decision.

Will you leave a comment and tell me how you make difficult decisions?

Tweet

Trust and When You've Moved Their Cheese

The teams must trust the project manager if they are to work together effectively. If new practices have been introduced recently, it's probably more of an organizational change issue than an issue specific to project management itself. You moved their cheese!

You must establish trust with your teams and stakeholders before pushing them through change. If they are not bought in to you and the change beforehand, you will fail. As I wrote about in "New Project Manager: How to screw up in the first 60 days", flying in, cape waving to 'rescue' your team is not the right approach. It's a good way to screw things up by sending the message that you think the way they have been doing things in the past is stupid.

Tracking At The Right Level

I've also seen this happen when the project manager tries to get too fine-grained in terms of schedule and status updates. My personal opinion is that using details when planning and estimating is good, but trying to have that same low level of detail (especially in a waterfall environment) is going to drive teams nuts.

And frankly, that drives me nuts too.

When you have an agile process like Scrum or Kanban in place, it makes it much easier to go down to these lower levels of detail. This is because you are only worried about being able to visualize the work and make sure everything is getting done....if you try to ask team members to split hours worked across individual tasks, it can become very taxing quickly. Every minute your teams have to spend each day trying to track their time is a minute lost - but more importantly it's frustrating to do!

That level of tracking implies a lack of trust from management, and people start cracking jokes about which charge code to use from the time they leave their desk to the time they get to the meeting.

For example, in our last release one of my teams probably worked a total of 100 or so individual tasks. Most team members had no more than 4 'buckets' to split their time up with.

There is a level of tracking that adds value, and once you go down too deep the value drops off, and the overhead cost increases. Furthermore, the more confusing it is for your teams, the less accurate your time tracking will be.

Tweet

Like this? Share it!

How to use Gantthead.com to find useful information quickly that is pertinent to your needs!

I'm going to ask you a question.

It's a simple question.

What is testing for?

Some people seem to think that testing is for display purposes only. These people would expect your testing phase to consist of showcasing your product instead of actually testing it.

I don't think so I think the best definition of true testing is this: Try to break the product.

That's right, the only value in testing your product is to try to poke as many holes in it as you can.

If you're testing phase consists of trying to look good in front of your customer, your stakeholders, your sponsors, then you are doing it wrong.

Get this. Earlier this week I was actually asked this question. "Next time, could we do integration testing before the official integration testing?"

That's right folks. We are talking about testing before we do testing. How sad is that?

Now let me make sure I'm clear.

We did dry run testing before the official testing. So it's not that we didn't test fully, or have ample preparation before the official testing. No, this is about looking good politically in a testing cycle.

This type of showmanship has absolutely no place in effective project management.

Period.

My teams and I do Kanban within a waterfall program.

This means that we have release cycles that start out with some investigation and detailed planning, move into true development, and then we have an Integration & Test process at the end of each release to go through.

A struggle we've had is that our value stream changes each time we transition from one phase of the waterfall cycle to another.

Furthermore, when in the Integration & Test phase, there is a specific tool we a required to use to work off what we call Test Descrepancy Reports (TDRs) which are basically bugs we find in testing.

At first, we would use a separate kanban board for the I&T phase, which maps the value stream of that process. However, due to the requirement of using a specific tool, it became a wasteful process to try and use both.  We had to keep both updated.

So in those cases, we dropped the kanban board - everything else was the same, but the visualization and mapping of a value stream went away for that portion of our work.

Has anyone else ran into a similar experience, with Kanban or something else, where a tool made a difference in terms of how you could work as a team?