pmStudent

Tweet

 What level do you track earned value for your projects? Too high is a problem, and trying to decompose work packages prematurely is problematic too. So how do you get the best of both worlds?  Here's how.

I suggest you view this in 720 HD, full screen so you can see everything in the tutorial clearly.  Note: Around 5:30 you'll notice in Step 3 I mis-labeled the last column.  It should be PV (Planned Value) and not EV (Earned Value).

Tweet

Tweet

Tweet

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. :-)