Docstoc

Interviewing a Software Project Manager

Document Sample
Interviewing a Software Project Manager Powered By Docstoc
					Interviewing a Software Project Manager

Last summer, a colleague of mine asked if I had any good questions I used when
interviewing someone to lead a development team.

I came up with this list of questions and "things to listen for" in the responses.

Question #1:

A lot of software projects fail. Building software is really complex. If we determine
success as: coming in on time, on budget, with a rock-solid product, what would you say
your success rate has looked like over the years?

Things to listen for:

Anyone that says they’ve succeeded all the time either:

   1.   Is lying to you
   2.   Has never been in a challenging enough environment
   3.   Isn’t confident enough to admit to past failures
   4.   Is kidding themselves
   5.   Doesn't recognize failure when they see it

It’s ok to fail. The ideal evidence you’re looking for, even better than someone that says
they’ve almost never failed, is someone that started off average in the beginning (70% of
software projects fail), but who turned it around and ended up with a consistently
successful track record after that. That tells you several things: the person is honest,
confident in his/her abilities, willing to admit mistakes, learned over time and adapted.

Question #2:

What are the top factors that keep slamming software projects in particular?

Things to listen for:

Look for domain knowledge of the software space. General purpose project
management experience may not be enough for complex software environments. Look
for tangible factors that can be measured and managed – that’s what good managers
look for. Saying that “communication is important” is useless. You can’t manage what
you can’t measure.

Some examples of software killer factors that can be measured, and therefore managed:

   1.   Requirements management (creep, churn, lack of documentation, etc.)
   2.   Estimating time
   3.   Estimating distractions
   4.   Knowing when the schedule is solid enough to start making commitments based
        on it, and when to hold back and not promise anything yet




                                                                                         1
Question #3:

How do you manage these risks in a software project?

Things to listen for:

Most people will telling you they manage them “internally” (with their gut, or in their
head). Um, sure.

Ask for tangible examples or evidence that they do this. Otherwise, they’re probably just
telling you what you want to hear and don’t actually behave that way.

Managing all of those things starts with keeping a lot of notes and records. Really good
ones will even model them in a spreadsheet. There are so many fiddly-bits that go into
software projects that if you can’t go back and look at the record for what happened,
then it didn’t actually happen (people will forget and there is no proof of any problem).

Question #4:

Software managers usually come in two flavors: those that come up through the ranks
from a technical background, or those that are professional managers (never been a
developer). Which would you say you are?

Things to listen for:

Beware of “manager-only” managers. Coming back to the domain experience thing,
“professional” (read: jack-of-all-trades-master-of-none) managers struggle with software
projects.

There is far more complexity and risk in these types of projects than in others. It’s easier
to teach a super programmer how to manage than it is to take an otherwise very
organized person (the professional manager) and teach them what they need to know
about the software life cycle, the unique challenges and risks, and what to do about
them.

Above all, look for people who are really passionate about great software. Someone
who's solely going to tick items off a to-do list until they can say they're "done" isn't going
to produce great software. And, producing mediocre software on-time isn't as good as
producing great software a little later.

Craig Fitzpatrick is the founder and CEO of Devshop. Craig has a street smart sense
for successfully wrestling software projects from the jaws of disaster, which he writes
about in his blog: Uncommon Sense (for Software)
http://www.uncommonsenseforsoftware.com/.
Devshop is the 5th software company that has called Craig one of its fearless leaders.




                                                                                              2

				
DOCUMENT INFO
Shared By:
Categories:
Tags: white, paper
Stats:
views:163
posted:4/4/2008
language:English
pages:2