Building Better Software, Part 1: The Need for Project Management
Over the next several weeks, I'm going to discuss the ins-and-outs of successful project management, and all of the ways it can improve your software project and, dare I say ... life?
But before I do, I'm going to spend this post illustrating the need for professional project management in the first place. The ins-and-the-outs will come later.
The opinions I'm about to express are based as much on frustration as they are on years of observing, assisting, and sometimes preventing successful project management. Since my last three posts were basically screeds about client misconceptions that frustrate me, I'm going to take a different tack, put the snark (partially) away, and get real aspirational and hopeful for a better future between software developers and their oft-unhappy clientele.
So let's get started: today's topic is the need for project management.
Before You Have Proper Management
There's a reason Aaron James Draplin, in his iconic talk, "A Fifty Point Plan to Ruin Your Career," listed people like us at the top of his "Society's Worst" list. And that's because we are the worst.
Or at least, in the rosy dawn of our freelancing careers, we were. Those are the heady early days when, smart, young, and hungry, we learn on someone else's dime and take vacations without warning and imagine astronomical wealth if we could just bill a few more hours a month.
In those days, we represent everything everyone hates about software engineers: we break everything but we're exactly smart enough and in exactly enough control to avoid taking responsibility. Some bellwethers of looming irresponsible-freelancer-sponsored project disasters include:
- Features that worked break when new features are added
- Time (and budget) estimates are wildly inaccurate
- Feature requests are being tackled in no particular order (which just means the engineer is implementing the easiest or most interesting features first, and not necessarily the most important)
- Features are being started and abandoned before they're finished
- Features are being promised and never delivered
- Angry emails are being ignored
- Eventually, angry phone calls are being ignored
- Eventually, you are being ignored
- Generally, the freelancer is behaving like Mark Zuckerberg building ConnectU
If any of these sound familiar to you, they're all symptoms of the problem project management is designed to solve.
I've noticed that some serial entrepreneurs tend to take these issues as a given for building software: "That's just how developers are" is one common refrain. Ignoring the unfairly low expectations that attitude sets, what can we say for the entrepreneurs who aren't so forgiving?
For them, behavior like this poisons the well from which consultants draw. We're left to pick up and dust off the bedraggled veterans of the Freelancer Wars to help them back into building software. Sometimes we never get to meet them, because one go-round in the Whirligig of Disastrous Software Projects was enough. But one thing is for sure: whenever we meet any new client, they've already been burned, and probably more than once.
Is it any wonder we're compared to snake oil salesmen?
Bringing On Professional Management
I love that phrase, because that's what growing companies do in a broader setting: they realize the need for someone who can manage a company in a new growth phase. If the founder is careful, they stick their hand out and flag down a passing management-expert-cum-interim-CEO to learn from; if not, they usually wind up getting canned.
Like the struggling startup founder trying to steer a runaway train, your average would-be tycoon knows next to nothing about how to manage technology. And so, much as hiring an experienced CEO to learn the black magic of high-growth management becomes imperative for a founder's success, all software entrepreneurs must observe someone building technology to learn the art of project management.
If they do not, and instead play the roles of CEO, CTO, and whichever others they need to, they'll frequently find themselves either failing to maximize the utility of a software firm, or paying a freelancer to ignore their emails.
But. The CEO comparison can only take us so far, because unlike a young startup that harnesses the passion of an inexperienced-but-driven founder, no software project benefits from a passionate-but-inexperienced CTO.
A large project without proper management isn't so much likely to fail as it is guaranteed to fail. Sometimes I meet clients who are lucky enough to be able to start a project over. More often, though, the endeavor that so sorely needed close management from the beginning will die and the entrepreneur will try again with a new opportunity - or just get a job.
The Part Where You're Smarter Than Me
If you're anything like me, you've gotten this far and thought, "well I can manage a software project; no problem. Add it to my list of things to do."
This is not a wise opinion. I'd estimate that about 80% of the failed software projects I've observed failed from a lack of proper oversight. It happens because the entrepreneur gets too busy, or doesn't know how to manage a project, or just puts their faith in the wrong person.
Still, I applaud anyone's moxy to learn it, and that's where I intend to help out, especially since it's a lot more work than you'd think. Someone has to have a singular focus on organizing the production of technology. If it's not the founder, the remaining options are: add a cofounder that can do it, pay someone to do it, or face a high probability of failure.
I'm not saying that to convince you of the importance of my job or company, or to scare you into hiring someone you think is overpriced. I'm saying this to help you think about these problems. My goal is for clients and consultants to come away saying, "if I follow x pattern which leads to failure, I'll fail, and that would be less pleasant than succeeding."
Hopefully that's a compelling enough reason for you to come back for my next post, "The Basics of Project Management." In it, I'll cover some simple project management concepts, and also discuss how they change in the context of software. Because while it's not fair that developers not be held to the same standards of conduct everyone else is, it's also true that they currently aren't. And if nothing else, project management stands to fix that.