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.