(This post originally appeared as part of the 2009 PHP Advent Calendar)
The interaction between technical people and the project sponsor has common patterns regardless of your employment model. Project sponsors — whether consulting or freelance clients, key stake holders within your organization, or potential users from some vaguely-defined demographic — all have similar needs and issues. I’m going to collectively call these peeople Bob from now on, because “clients, key stake holders, and end users” is very wordy, and pixels are expensive. Also, it helps to put a human face on a role. (Three quarters of the way through a project, it might help to put a human face, specifically Bob’s, on your dart board.)
Technical people tend to think first and foremost of the technical parts of a project. That seems like an obvious truism, right? If they thought first and foremost of the color of the packaging, or the training users will need, or how best to market the end result, they probably would have gravitated toward a different career.
Effectively managing Bob is a key task that directly leads to project success. Sometimes the relationship has obviously adversarial aspects, such as in a fixed-price contract where both sides are likely to disagree over what is within the project scope, but even the friendliest relationship has the same basic conflict between the technical staff and Bob. The sponsor wants more, and wants it on time. The technical staff needs to restrain their enthusiasm, so that a cross between those wants and the constraints of reality is produced.
Regardless of whether Bob is your employer or client, you need the same basic elements to control the process: an upfront plan (recorded in some way), a way of recording all changes, an agreement on who has the authority to make changes, and the power to update the original plan’s time estimates in the event of change.
Overall project success or failure is only sometimes closely tied to technical factors. Right off the bat, you need to think about who decides if the project was a success, and regardless of whether that determination is made based on measurable, objective factors or more commonly just the person paying the bill’s gut reaction, it probably is not made on the basis of a technical evaluation.
The determination is made by Bob. Bob rarely has the knowledge to judge a project on its technical merits, and even more rarely cares. He has his own internal set of criteria, only some of which you have the knowledge to understand, and even fewer of which you care about, and many of them will go unstated until it is too late, unless you are very good at extracting information from uncooperative subjects without the use of pliers or waterboarding.
I’m not saying you should deliver poor quality code. Non-technical people certainly notice the side effects of good code. Even if Bob would not recognize it if a bus — plastered with beautifully-tested code implementing a cool new design pattern that was only invented tomorrow — ran him down in the street, he notices the results. Bob notices uptime, how long seemingly minor change requests take to implement, consistency in the UI, crashes, revenue, and conversion rates. He will notice the symptoms of bad code, even if he does not have the knowledge to diagnose the root cause, or the vocabulary to request the cure.
My point is that technical aspects are only a small part of overall project success. Extracting real, actionable requirements from Bob, setting realistic expectations, and either meeting those original expectations or keeping the project on track as things change is a big part of success. Manage new information, new feature requests, and change requests while either coming in on time or resetting Bob’s expectations in advance. This keeps him informed about what impact his requests, dreams, maternal attachment issues, and crazy ideas he read in this week’s issue of IT Trends For Steam Engine Manufacturers are having on the project.
If your project is to be a success, you need to effectively and proactively manage Bob. You need to keep him happy, which probably means making good overall progress, but specifically making some visible progress in parts of the project he does understand. You need to deny some of his change requests so that the project reaches completion. You need to accept some of his change requests so that he feels that the power dynamic is correct, but you need to either have allowed the right amount of padding in anticipation of change, or make sure that Bob is aware what effect the request has on the timeline.
One of the best and worst things about software is that it is infinitely malleable. If you don’t like change, perhaps steam engine manufacturing would be a better career for you. Change will happen, both in the industry around you, and within your own projects. Trying to deny all change is counter-productive, but an inability to say “no” to any change requests is a recipe for insanity.
So first up, presenting a best-case time estimate to Bob is worthless. Unless a task is really small and well-defined, new information will come to hand, or Bob will have time to read that all his competitors are going towards mauve for databases and your best case will not happen. Tend more towards Scotty from Star Trek’s approach to estimation. He claims everything is probably impossible, definitely impossible in the time available, and then delivers it on time anyway. In other words, add some padding, so that rather than satisfactory delivery being an unlikely event that only happens in rare instances when planets align and Kirk stops chasing green women earlier than expected, it becomes the norm.
If you have some padding in the initial estimate, you can afford to react to new information and good ideas in ways that will make the end product. Most importantly, you’ll be able to deal with the reality that in anything with more than ten lines of code, or more than zero people involved, something is bound to go wrong.
The usual gag about quitting your day job to do freelance or consulting work is “I fired my meddling, egomaniacal, narcissistic boss and now have fifty meddling, egomaniacal, narcissistic bosses.” But, counter-intuitively, internal stakeholders are often harder to manage than external clients. External clients are much more likely to be tied to some form of written contracts, written design documents, and a formal agreement on who has the right to make decisions. Internal projects are rarely as formal. It may be hard for a lowly programmer to say “no” to conflicting requests from vice presidents of many different areas within the company.
Assuming you take on external projects in a mostly sane way, it should be fairly easy to say “Why yes Bob, your perfectly reasonable request to add a previously unmentioned Parseltongue translation layer two weeks before launch can be done, but it will add 3 weeks and $10,000,” and get real commitment on whether the change is really wanted and — perhaps more importantly — written sign-off on the effects. It may be very hard to say “no,” and it may be fairly hard to convincingly say “you should listen to me when I say you don’t want that,” but it can be easy to put a dollar value on a request and let the person who has to pay for it make the decision that you favor.
While an external Bob may well turn out to metaphorically (or medically) have multiple personalities, if your internal Bob is an amalgam of your engineering boss, his boss, the head of marketing, some guy from sales — who may or may not actually be important but needs two lines on a business card for his title — you can guarantee multiple personalities.
You need to know who has the authority to make decisions on conflicting requirements. On an external project, this is usually fairly straightforward. When you determined who had the authority to sign the contract, you probably found out who has final say. On an internal project, if you have difficulty pushing back against more senior people in other departments, you need to make sure that your boss is on your side and will do the pushing back on your behalf. Immediately flag conflicting requests or anything that will affect completion time.
You are going to be held to a plan and a schedule, even if they are just in Bob’s head. It is in your best interests to have them recorded, so that you can hold Bob to the plan, which will help you stay on schedule.
Regardless of the model, your goal is not to give people what they asked for; it is to deliver what they want.