Owning The Inputs

My role is in IT development as opposed to product development but software nonetheless!

This has definitely worked for me. To me there are two really key things that make it work. Let's say I have a PM on my team come to me and say yeah, you know all that stuff that was supposed to go in the October build? We have to push it to November. (Which, in fact, happened to me today!)

Two key elements - number one: you, the PM, are on the hook. You are the project manager. You define who does what by when. Whether it is your peer, a vendor, whatever the case may be, you are responsible for delivery of said "what's" at the agreed upon "when". And second, there is always something you could have done differently - followed up sooner, allowed more slack in the schedule, escalated faster/higher. At minimum, did they communicate early enough or clearly enough that there was even a risk of missing a deadline? In my example this morning, "what could you do differently" was met with well, yeah I guess I should have followed up on this last week. I can think of very, very few projects in my experience where a delay was truly unavoidable, and we are talking international incident/national emergency type stuff.

I also love the shot across the bow part of this - if they argue just say OK and walk away. They heard it. Either they will correct it, and next time the delay may be for a different reason, or the same thing will happen again and you will have another chance to give more feedback. (In my experience a lot of times this is something like "well the server was down so Bob couldn't check his changes in." - so one time, fine, a couple times and I start wondering if you need to make sure there is an admin on call on those days, etc.)

One thing I like to keep in mind, it's not about picking who should be the recipient of feedback - and it's highly likely, dependent on the situation and how frequently this has occurred, either I will give the other party feedback or encourage the PM to do so. But for now, the mindset is "how I can turn this experience into an opportunity for improvement, for the person I am talking to right now?". Later, someone else may hear " hey, when you don't check in your code on time, the boss gets on my case cause I am on the hook for this. Just thought you should know."

  (In my experience a lot of times this is something like "well the server was down so Bob couldn't check his changes in." - so one time, fine, a couple times and I start wondering if you need to make sure there is an admin on call on those days, etc.)

To which the response is (in my experience): "Yeah, well you know that SLA your bosses boss signed when IT support got outsourced 3 years ago?  Under that our source code repository is a 'Development' server so it's a 10 day fix and lately they've been holding us to the SLA limits cos they're trying to lay off staff and want to see how few they can get away with.  The contract has another 12 years to run so they know they can get away with messing us about now."

Stephen

--

Skype: stephenbooth_uk (Please note I'm on UK time)

DiSC: 6137

Experience is how you avoid failure, failure is what gives you experience.