This article was written by ETHAN JAMES, a freelance software engineer at TOPTAL.

Editors note:  Whilst this has been written from the perspective of a software developer it ably demonstrates, in a light-hearted way, the importance of having an impartial third party as a project manager.  This lesson does not just apply to technology projects and can be applied to almost any complex business project where objectivity is important.

“This article is for you, the plucky entrepreneur with an app idea in your heart and a bit of cash in the bank. The diagrams that you’ve scribbled on cocktail napkins will disrupt the entire world, and dump trucks full of money have already been dispatched to your house. To ensure that they arrive on time, here’s some simple advice for making your production cycle run smoothly.

Why You Need A Project Manager In The First Place

“Computer programs are the most complex things that humans make”, says Douglas Crockford. You may not have heard that name before, but he’s pretty famous for a programmer. He’s currently a senior software architect at Paypal, and he has pioneered all sorts of cool technology that is beyond the purview of this article. He is someone who knows a great deal about working on large projects.

As for myself, I’ve been programming for 13 years, and even now, at some point, every project takes me into uncharted territory. There are so many different technologies out there, and new techniques are being devised at such an alarming rate that I never feel I’m completely on top of what’s going on. While every project has its unique challenges, there are some constants:

• The project has time pressure.
• The budget is smaller than I would like.
• I am a more expensive than the client would like.
• I do not listen as perfectly as the client would like.
• The client does not explain things as perfectly as I would like.

Clearly, we need a babysitter. Someone has to step in to establish the ground rules, keep everyone honest and make sure that we’re not forgetting anything important. Someone has to facilitate communication between all parties.

This someone, this hero, is the project manager.

Why A Programmer Does Not Make A Good Project Manager

Certification by the Project Management Institute aside, the most important thing that a project manager can bring to the table is experience. As a result, many programmers would make pretty decent project managers; we have more experience with technical projects than anyone else and our analytical minds are adept at cataloguing information and setting concrete goals.

Goodness knows, you’re paying us enough, so it seems reasonable to expect that we could manage ourselves rather than force you to pay for someone else’s time as well, right?

Well, for starters, you’re paying us to code.

When we come out of our programming daze to make decisions about what to prioritize, or to argue about how much is actually going to get done this week, code is not being written. It then takes at least 10 minutes to get back into “the zone”, especially if we’re stressed out by the conversation that we just had, which is likely if we’re arguing feature priority. Boo hoo, I know, but this is all about making the most efficient use of costly resources.

Most importantly, we really can’t see the forest for the trees. If you take nothing else away from this article, please understand this: When I spend all day staring at a few specific bugs, my brain loses track of the bigger picture.

My brain rewards me when I fix those bugs, and I assume that I’ve done great things and can go play video games now. When someone reminds me that the home page is still broken, it comes as a complete surprise because I have spent the day filling my brain with very detailed knowledge of a very small piece of the overall project and sort of forgot about the rest of it. That’s just how my brain works, and a lot of other programmers have a similar psychological make up.

Why A Client Does Not Make A Good Project Manager

Well then, if we programmers don’t want to take the responsibility for getting project managerial things done, then it must fall to you, the client. It’s your money. It’s your vision. You’re ultimately responsible for the whole thing, anyway.

You, however, also have a lot on your plate.

Many clients are mere mortals with day jobs like the rest of us, and some have even been known to suffer from procrastination or forgetfulness. Although this certainly does not describe you, please entertain the idea of having a Professional Rememberer around so that you can get back to the important work of keeping the whole project alive.

If you have worked on, or overseen, a technical project of similar scope, you may indeed make a good manager for your project. If you have not, please don’t underestimate the value of someone who can predict the issues that may arise. Time estimates are always just estimates, and bugs tend to pop up at the least opportune times. It’s worth the cost of another (if only part-time) employee to have someone around who knows which parts of the process need, or are likely to need, the most attention.

Take quality assurance (QA) for example. Proper QA is essential for getting what you want out of any project, and it never ever gets the attention that it deserves. A good project manager will make the most of limited QA resources, and also quality-assure your programmers for you. Sometimes, we get out of our depth, and sometimes we make mistakes. You need a technically-proficient person in a supervisory role to determine whether your programmer is just having an off day, or if he or she is, in fact, a bad fit for the project. Heading off personnel problems early could mean the difference between life and death for your project.

Lastly, even you, oh glorious client, sometimes need a little check and/or balance. That’s hard for me to write since we computer programmers are not well known for our outspoken natures. Suffice to say, I have worked on many projects where the client was adamant that everything was top priority and absolutely everything needed to get done. While I have no doubt that this was absolutely true, these clients, sadly, did not have control over the number of hours in a day. They did not end up with the positive result they desired and/or deserved, and I feel that this outcome could have been avoided had the client entrusted a project manager with the authority to assess the workload and tactfully, yet firmly, keep things in check. It’s difficult to make the dispassionate judgment calls that most technical projects require when it’s your idea and your money on the line and the computer doesn’t care if you or I cry and scream at it. (I know this to be true because I’ve tried it many times.)

An Incomplete List Of Techniques For Managing A Technical Project

Whether you’ve decided to ignore the previous 1,000-something words and manage your project yourself, or whether you are going to hire someone but want to be more knowledgeable about the process, this list will help you. I have never (officially) been a project manager, so I can’t say which tools any given project manager would use, but I’ve had good success with all of these techniques:

Milestones

When beginning a new project, most people intuitively know that it’s important to split the project into slightly-more-manageable chunks, with each chunk ranging from a couple of weeks to a couple of months worth of work. At the beginning of the project, it’s good to have a kick-off meeting to establish these milestones. It’s OK to be a little vague on how you’ll reach them, the most important thing is to keep checking in after each milestone so as to benefit from everyone’s enhanced understanding of the project, and to make sure that the project’s milestones are still (roughly) the same size as initially believed.

Time Estimates

We programmers absolutely detest estimates because we know they will be wrong and we know they will be used against us. It’s OK that they’re wrong because, by definition, they’re based on a handful of unknowns. It’s also OK that they’re used against us because our jobs are pretty cushy and it doesn’t hurt to have the whip cracked every now and again.

So feel free to ask for estimates every time work begins on a new milestone. You should expect a line or two for each major feature along with a rough estimate of how long that feature will take. I usually make an optimistic estimate, then double it. More often than not, this extra time accounts for unseen pitfalls.

User Stories

User stories are brief descriptions of a single piece of functionality within the app. They are useful as a record of important features and should be bite-sized, able to fit on an index card and often accompanied by a little drawing. More importantly, they serve as a bridge between what the client wants and what the programmer has to tell the computer. They are simple enough for you, the client, to knock out in a couple of minutes, but detailed enough for us, the programmers, to sink our teeth into.

For some quick info on user stories, I found these tutorials by Mountain Goat Software and Roman Pichler to be high-quality and succinct. For more information on the entire philosophy of “Agile Project Management”, try this Toptal blog post The Ultimate Introduction To Agile Project Management by Paul Barnes.

>>> To read the rest of this article follow this link to the Toptal Engineering Blog

If this post is relevant to your situation and you can see the benefits an external, impartial project manager could bring to your organisation, then please contact us for an informal and confidential discussion on how we could help you to identify the right type of person.