pmStudent

Tweet

One of the videos I've enjoyed recently over at Kanban School is this one with Pawel Brodzinski.

Pawel makes the point that Kanban does not replace software development methodology or project management methodology. I agree.

In the video he said it's more of a change management process (I think that's what he said) and I don't think he meant it quite like that.

To me, Kanban is a method of execution. On my teams, it's about the day-to-day execution and all the benefits that come with the Kanban process for that execution. The visualization really makes continuous improvement possible, almost inevitable. 

So what do you think about all this? If you are new to Kanban, check out Kanban School.

Tweet

One of the things I'm constantly surprised by are project managers and writers who seem to ignore The Mythical Man-Month and Brooks' Law.

"adding manpower to a late software project makes it later" -Fred Brooks

Don't Call People "Resources"

They are people. They make up teams.

I've been guilty of this, but maybe calling people "resources" in your schedules and plans has a negative impact.

People aren't widgits, and teams aren't perfect systems where you can add another widget and get everything done that much more quickly.

I think using the term "resources" instead of "people" may allow tool-savvy project managers to get more and more detached from the reality of their project team and the work to be done.

You Can't Add People Like Widgets

I hear it more often than I would like.

Project managers see a shortfall in the amount of staffing available on a particular part of a project, which is going to cause missing a milestone date.

Then the exclamation "I can just take .2 of an FTE from John Doe down the hall and it all works out on paper!" (FTE = Full Time Equivalent)

Brilliant.

You know, there are some cases where you can do that. Perhaps the person has previous experience with the product your team is developing, or the type of work is generic enough that someone from outside the team can come in and pick it up without training.

But more often this is a big mistake. You are going to leach out .2 FTE from your current team (maybe more with multiple people helping the new guy) in order to get him up to speed.

So unless you are going to have a long-term commitment from a new team member and have considered the time and effort involved with bringing someone up to speed, their lowered productivity level until they are fully immersed, etc. don't even think about adding new staff.

Especially not temporary staff.

Tweet

image by DailyPic via Flickr

When it comes to communicating with your project stakeholders, setting appropriate expectations and following through is king.

I was reminded of this important fact recently. 
 

My Blunder

With four systems, I have a lot of key stakeholders. I had not properly communicated with one of those key stakeholders. At least, I should have done better.

I met with her this week and disovered she had specific worries about the system's useability that had not previously been uncovered. Had I been more dilligent, I could have easily addressed those concerns over a year ago. I came to this program after the design phase was complete, so I wasn't involved with eliciting requirements initially or working on system design.
 

I Was Lucky

I was able to address the concerns on the spot, but I was lucky. For other stakeholders, holding reservations like this for a long period of time could easily span resentment and cynicism toward the project.

The truth is, many people will avoid a conversation if they expect it might be unpleasant. Most of the time it isn't a conscious decision, but a heightened ability to rationalize behavior that avoids the confrontation.

I became aware of the fact I hadn't done enough to communicate with this stakeholder a few months ago. The opinions of my team made me think she would be very difficult to deal with, because everyone thought she'd want some functionality that our design just won't allow. So I rationalized that I really had to have my ducks in a row before I even attempted to speak with her. I had to justify the design all over again, and be sure I had talking points to respond to any objection.

Lesson Learned

In short, I wasted a lot of time and effort due to an imagined fear. It turned out she was very receptive to our design, she just didn't fully understand it and how she would be able to interact with the system.

If I had done a better job of communicating all along, her expectations as a stakeholder would have been clear to me and my team. In response, I could have ensured her expectations were set correctly and met.

I think it's important to acknowledge times like these when we fail to meet our own expectations. It's theraputic and educational. Here's another lessoned learned for the books.

Will you share a communication or setting expectations blunder in the comments? That way I don't feel so stupid. :-)

When I teach people about Kanban for the first time one of several key concepts must be fully understood before I proceed into the details of executing with a Kanban-enabled process.

Every Team Has A Value Stream

Whether you know it or not, your team has a value stream. Some teams have several value streams depending on the varied type of work they do.

It is the process by which your team takes input and turns out the product at the end. That process is a value stream.

It's nothing fancy or complicated.

Each Step Adds Value

Well, every step should add value anyway. If it doesn't, why is it a part of your process?

You will also find after using Kanban for awhile that the more time between steps, the lower value you acheive and the more waste is introduced into your system.

This is why cycle time is so important in any system; the longer product in the system lay dormant, the more waste you introduce.

People start forgetting what happened to the product in the last step, and so they have to spend some time reviewing it again before they can try to add more value to it. This process introduces the potential for human error, and in software it means more bugs.

Start Where You Are At

The benefit comes from visualizing your true value stream and facing it.  Look it square in the eyes.

You have to fully understand and accept where you are starting from before you can move forward.

This is why visualization with something like Kanban is so astoundingly beneficial. It acts as the mirror you can look at to reflect reality.

Only once you know thyself can you truly improve.

Kaizen (Continuous Improvement)

After you start using Kanban for awhile, you will soon start noticing problems with your value stream. Or rather, opportunities for improvement.

There are no steps I can give you to make this happen.  It just will. I never have had to have any retrospectives or set times to consider lessons learned. Every second we use Kanban we are in a retrospective process, evaluating our performance and process in a continuous manner.

You can't help it.

Questions about Kanban?  Leave a comment below or check out http://KanbanSchool.com.

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?