Who is this for again?

"If it weren't for the customers, this would be a lot easier"
-- The Engineers

Stakeholder Management

No matter what kind of project you are running, the people involved in it are going to be the biggest challenge you face.  Technical Project Managers (TPMs) have it even worse since in many cases part of the project involves creating something that has never existed before.  This creates more than a little bit of chaos that needs to be dealt with.  Although Stakeholder Management has been part of the PMP process forever, it is finally getting more focus by being defined as its own area of knowledge.  In my experience, how you manage stakeholders is the most important part of any project.  If you don't have a handle on that, it's a given that the rest of your project is probably off track as well.

The reason why this is a bigger factor for TPMs is because Engineers tend to be type A personalities who are also easily distracted by shiny objects.  Software Engineering is even worst because Moore's Law applies to more than just semiconductors.  You now have a group of people whose entire world shifts at least once every 18 months.  New languages are invented, old ones are deprecated.  Compiler versions advance and target platforms can change overnight.  Contracts from other customers may even be asking the Engineers to produce the exact opposite functionality.  It is very easy for Engineers to get into a mindset where they are the focal point of all design and forget that customers request things for a reason.  The challenge for the TPM is to get the Engineers in line with the needs of the rest of the stakeholders without self-induced scope creep and without Engineering becoming "those guys".

These are a few of my painful lessons learned on how to make sure Engineering doesn't derail a technical project:

1. Read the Statement Of Work to them - I'm not kidding!  Don't email it and ask if they have questions.  Don't ask for them to mark it up.  Don't put it on sharepoint and then ask who read it.  Somewhere in the unwritten rules for Engineers is a credo that says you don't read the instructions until things start falling apart.  If no one ever forces them to read the SOW, chances are you will have folks doing all kinds of crazy features that they want while crying "Change Order" when you try to get them to do what's actually in the SOW.  Disclaimer to all my Engineering friends (I am one also):  Take a deep breath and remember the first step is admitting you have a problem....we have all done this.  I still love you guys.
2. Let the Engineers outside - I know what you're thinking and yes, I'm serious about this one too.  There is simply no better substitute for letting an Engineer see and touch the problem they are solving first hand.  Obviously provide supervision where needed if the Engineer has extra "people skills".
3. Let the Engineers challenge the SOW - It's OK to let the engineers tell you requirements are stupid or useless.  Sometimes it's just therapeutic.  Sometimes they are dead right.  The software requirements process is messy.  Depending on tons of factors, the SOW could be broken.  A few examples:
• System baselines changed during contracting
• Technology advanced after the sale was closed
• Stakeholder who cared about dot matrix printer support retired
• Sales misunderstood requirements
• Sales was smoking crack (I was also one of these guys...no comment)
• The SOW was written by humans
4. NEVER let the Engineers tell the customer the SOW is stupid or useless - You sadly have to keep an eye on this one.
5. Don't allow double standards on requirements - This one may or may not require some assistance from leadership depending on your relationship to Engineering.  Engineering will pitch a complete fit if you come to them asking for feature X without thoroughly documenting what they should be building.  This is a good thing and I applaud all Engineers who hold TPMs to task on this.  However, watch out if Engineering decides to add or change to feature Y to meet a requirement.  They should be producing the exact same level of documentation for all stakeholders to review.  Otherwise your tree swing comes out four years later as a rocket ship with a picture of a tree swing on it....if you're lucky.
6. Do everything you possibly can to make them part of the team - I'm not saying bribe them...but definitely put some time into building a relationship with them.  Maybe it's blocking off time in the schedule to take them to an early premier of Star Trek XLV.  Maybe you budget a couple hundred bucks for a nice steak (dress code may be a challenge).  Or maybe you find out what tech gadget they are pining for and make it a competitive prize for hitting the finish line on time.  These guys will happily hunker down behind closed doors without regular meals and showers and works their tails off for you.  Sometimes a little forced fun will pay great dividends when tho going gets tough.

The "Golden Rule" of Scheduling

"I'm free in 30 minutes...so surely everyone else is too...right???"- Nearly every PM I have worked with to date

Slow it down please

I'm really not sure why this is such a pervasive habit.  The field of Technical Program/Project Manager (TPM) is naturally a world populated by geeks.  Geeks tend to be more introverted than most and maybe even get used to the instant gratification of their computer doing most everything they ask without delay.  But they are still people and still get irritated when you suddenly interrupt their day.  I can understand a new guy being told to go schedule something and just building something up without checking with others.  But the seasoned folks should theoretically have already been burned enough by others to remember courtesy.  Sadly, this is not the case.

Before any TPM puts a single date on any schedule they need to ask some basic questions:

1. Do I control everyone who needs to participate?
2. Is my project the only thing they are focused on?
3. Is my project their top priority?
4. Do I have visibility of everyone's calendars?
5. Is it possible that some people don't keep their schedules accurate?
6. Can this event succeed if random participants can't attend?

If you answered "No" to even one of those questions, it's time to slow down.  Not everyone realizes that you are the center of their universe.  Taking just a few minutes to make others feel like they are more important than you are goes a long way.  And in the rare case where you are working with folks who actually are more important than you (boss, customer, spouse, etc), then this is even more useful.  Simply send out a request to find out when the team has time available for what you are trying to do.  This can be as simple as a conference call or something more complex like scheduling staff or equipment time.  You can be extra careful and also ask for alternate times so you don't have to repeat emails every time one person has a conflict.  This may feel like it is slowing you down, but it is way less disruptive than botched meetings.  It is also less painful than getting chewed out by a customer or supervisor who felt like you showed a lack of respect for their time. 

Speed it up please

Sometimes emergencies happen.  We have all been there.  Decisions have to be made right away and next Tuesday is not going to cut it.  It is still OK to slow down and ask for available times.  Simply communicate the urgency in your request and let the team know that the meeting will happen with or without full participation.  In these scenarios, it is usually best to follow up your email with immediate phone calls.  Just because you live and die by email and the schedule doesn't mean the whole team does.  Phone calls will catch everything from the Engineer who is in the zone to the executive who is stuck in a critical meeting (aka golfing).

A little courtesy to others will go a long way to keeping your schedule and your sanity intact.

Getting my Geek on!

Before I do anything I want to thank Jonathan Jones, +Brandon Linton, and +Brandon Jones for collective motivation to get out of my computer programming rut.  The last four years or so I have basically only touched a compiler when I couldn't get anyone else to do the coding for me.  I could give tons of cheesy excuses about changing job roles and raising kids, but the truth is I just got lazy.  Boy do I regret that!  I am behind in every possible way and this blog will just be one of the tools I use to start motivating myself to learn and get back my Geek standing.

Purpose

No one who has ever worked with me (except maybe my wife) is buying the lazy bit.  What I have been working way too hard on lately is shaping and managing projects.  What I would like to do with this blog is to mix in my tech R&D with some lessons learned as someone who has had to depend on other developers to deliver a product.  No one ever sent me to school on this or gave me anything that even smelled like an established process for Technical Project Management.  I have learned in the trenches with nothing but my thick skin and stunning good looks to get me through the hard times (you get which one is sarcasm right?).

Disclaimer

I apologize in advance to any future reader who stumbles on my musings and realizes a particular rant is about their project or even about them.  Of course they likely won't read this disclaimer and will flame away. The bottom line is that a few of the lessons I have learned in life have been the result of some fairly spectacular failures.  I will never apologize for being honest.

Hajime!

For the next several days, I will be standing up a Win64 ASP.NET and C# playground.  Why in the world would I pick that you ask?  Because it is something completely new and new is always good.  There is a second reason that I will share in another post.  Never fear though....I am also setting up an Ubuntu 12.10 dev environment to get back into some hard core C++ and maybe even contribute something useful to the open source community.

TPM Wisdom

You don't need PMI, ITIL, ISO, or any other established process to get through a project.  Sure they help, but everyone gets the basic concept of setting a goal and working towards it.  If you are an absolute n00b at project manager, just start with these two basic tasks:

1. Write everything down - I don't mean every word of every conversation.  But do write down the key steps and tasks along the way you did including roughly how long each step took.  Also write down notes about every lesson learned.
2. After Action Meeting - When all the dust settles, you either bought everyone a beer, or walked out the door with all your stuff in a filing box.  Either way, try to get with as many participants as possible and incorporate your writings from step 1 into a written plan for your next project.

Given enough time and projects, anyone will eventually become a master PM just by following those two steps.  Sadly, I have been amazed at how many projects I have watched where nothing is captured or learned from and then everyone seems shocked when the next project is just as screwed up as the last one was.  Baka!