5 Hidden Reasons Your IT Team Is Always Late and Over Budget

There’s an epidemic plaguing IT teams across the globe: the chronically tardy delivery of subpar projects with higher-than-anticipated price tags. These issues are hitting especially close to home, as the Health Insurance Marketplace, the IRS, and the U.S. Department of Agriculture have recently implemented embarrassingly ineffective and overly expensive IT projects.

Some blame these issues on poor planning, flawed project management, understaffing, and an overall lack of resources. But this line of thinking makes the false assumption that planning, designing, and building complex software systems requires the same process as, say, building a house. They think an architect can draw out relatively complete plans and virtually build the whole thing before physical construction begins.

Software simply doesn’t work like that; it’s always virtual. Yes, you can certainly plan and scope some of your project, but the complete blueprint would simply be your finished product. The nontangible nature of software systems lead them to have hidden complexities and dependencies — some of which can only be discovered once everything has been taken to completion.

The lack of ability to truly plan ahead is what eliminates these common time- and resource-related excuses from our lineup of culprits. In fact, renowned software engineer Fred Brooks famously wrote that throwing more people at late projects will only make them later.

Let’s identify the true sources of our IT issues and figure out how to solve them.

Common Problems and Their Solutions 

It’s hard to pinpoint why IT teams are performing poorly because the reasons are hidden. Here are five main issues that may reside deep under your IT team’s skin:

1. Communications overhead: IT optimization is a continuous effort in communication coordination. As Brooks said, expanding communication touchpoints will only make coordination more complicated, and because these channels are the project’s mortar — not the bricks — these issues tend to remain invisible until someone deliberately points them out.

Solution: Keep it simple by identifying and utilizing implicit communication channels. Recognize that your product will reflect the structure of the team that creates it, so keep communication contained to a small group of the most relevant folks.

2. Building the wrong thing: Sometimes, companies realize they’re way off base with their IT projects and need to start over. Because users determine the true value of IT endeavors, this realization usually isn’t made until after the project hits the market. Needless to say, it’s a time-consuming and costly setback.

Solution: Stay customer-centric throughout the entirety of your creation process.  It’s easy for teams to get caught up in the fun of designing and building things that reward themselves rather than customers. This is a natural tendency that happens unconsciously, so it’s important to continuously remind your team of the true purpose of the project: to benefit customers.

3. Slow feedback loops: Building a product is an ongoing process of discovery and experimentation, so it’s important to know what adjustments you need to make early and often. Along with neglecting customer centricity, building linearly with slow (or no) feedback inevitably leads to rework.

Solution: This is easier said than done with software development, but you need to identify all possible feedback cycles and shorten them mercilessly. Make batches smaller and more frequent, and if it seems like the wrong thing to do, you should definitely look deeper into it because you might be amplifying a negative feedback loop without even realizing it. Things that are scary, expensive, risky, difficult, and error-prone — and therefore avoided — all need to be confronted directly.

4. Bottlenecks: Every team faces bottlenecks, be it a specific person, piece of equipment, server, or process that repeatedly slows down production. These traffic jams are typically addressed reactively, meaning not enough time is being devoted to preventing them. A firefighting approach — rather than a fire-preventing approach — will continually hamper and slow down every project you embark on.

Solution: Be proactive in tackling your problem areas. Even if the reactionary addressing of an issue takes two minutes, it’s still an unnecessary distraction that will accumulate into larger batches and longer delays. Bottlenecks cause more bottlenecks, so stop reacting and start preventing.

5. Specialization: Assembly lines are great, but they’re only ideal for processes that are perfectly linear and predictable. Every station gets a job from a previous station and delivers it to the next, but any variation in timing or dependencies among processes will cause fluctuations and an accumulation of backlogs. That’s why a specialized, conveyer belt approach to IT isn’t valid.

Solution: Invert your ideas of specialization. Create small teams — ideally five or fewer people — and align them to specific products. Specialize them vertically to give them end-to-end ownership of the product’s entire lifecycle. This strategy removes the need for dependency and gated, linear progress.

All of these hidden problems have fairly simple and straightforward solutions — one of the hardest parts is identifying the problems in the first place. Teams that can uncover these challenges will be a step ahead of the rest. Amazon and Instagram have successfully done it, and so can you.