Why Your Software Project is Late (Part 1)

There are a lot of myths in software project management—the most famous being Fred Brooks' Mythical Man-Month. Staffing up a dozen new developers to help get a project back on schedule is like asking nine women to make a baby in one month. It just doesn't work like that.

Over the next few weeks, I will cover a few common problems most software buyers or business team leads don't see because they don't have my unique perspective. I was an Electrical Engineer, then an Air Force Officer, then a Data Scientist, then a Business Analyst, then a UX Designer, then a Project Manager, then a Product Manager, then a large-team Program Manager, then a VP of Operations for a 2,000-employee non-tech company, then a Back-End Developer, then a Database Developer, then a Front End Developer, then a Startup Founder/CTO... all the while being an active Options Trader and part-time Financial Engineer for hire. It's a bizarre path—believe me, I know—but all of these roles look at software with a truly unique perspective, and that is something most people who spend even their entire lives in the industry rarely have the opportunity to experience.

Part 1: Shadow Requirements

Find the tasks they're doing that you don't want them to do and get them to stop.

Every single person who touches your software project will add requirements. Whether hiring an outside firm or managing an internal team, your main point of contact will ask you many questions and you will tell them what you want. They will make lists of features and requirements, and will probably discuss with you how long each will take and the trade-offs of the choices you're making. Since you are a business person, making decisions about tradeoffs is your life's work and you're probably pretty good at it. You accept the consequences of these decisions and move on. The team gets to work.

But the tradeoff decisions have only just begun. Every single person on a software team has a unique perspective and sees things the others can't. So they imagine it as their responsibility to layer on requirements that no one asked for. UX designers obsess over making the emotional relationship a user will have with the product more pleasurable. UI designers wrestle with finding just the right font and color palette. Database developers try to get your data model to fully conform to the Third Normal Form. Back-end developers envision general-case solutions and try to architect a universal system rather than a single product.

Some of these shadow requirements are good. You pay these specialists to know things that you don't know and spend time thinking about things you don't have time to think about.

But here's the problem: most members of a software team are really bad at making trade-off decisions. Lots of engineers will literally laugh at business people behind their backs for being dumb (because they don't know how to sort a binary array in linear time and constant space). Yet, they will totally miss that business people often have a very good sense for what matters, what doesn't, when things should be done obsessively well, when things should be slapped together as quickly as possible, and when things should just be left alone. Business people are generally good at consciously deciding what they can afford to be bad at—and accepting the consequences of their decisions. Meanwhile, many technical people will spend weeks trying to make something work that never even needed to be done in the first place. It doesn't help that when you ask technical people what they're doing they throw back a wall of jargon at you that makes your head spin. You probably just nod, smile, and go away.

Don't go away. Don't let yourself be intimidated. Sit down next to them and ask them to explain what exactly it is they're working on. Have them repeat it again and again, in simple terms that you can understand. Have them draw you a picture. They will get frustrated with you and will be annoyed that you're interrupting them and micro-managing them. This is why it is critically is important to have previously built trust with your people. (Insert shameless plug for my article about 1-on-1 meetings.) If you haven't built trust with your people, they will be exceedingly suspicious of your new-found interest in their work. But stay with it.

Believe me—when you start to put two and two together and realize what they're spending their time doing you will be stunned. They probably aren't wasting time in the most blatant sense (Facebook, Reddit, etc), but they are almost certainly exerting tremendous amounts of time and effort (and your money) building all manner of features and requirements that you don't even want. And please remember, they aren't doing this on purpose, so don't be mad—just fix it and move on.