Experiencing Project Defeat in the Final Stretch

Have you ever wondered why many startup software engineering and tech projects go sideways at the 80-90% completion mark? Just as it seems like all the pieces are coming together . . . there are unexpected delays, errors and team frustration.

Most software projects broadly traverse 3 phases:
First is the Concept/Design phase (highly interactive).
Second is implementation (less interactive).
Third is Debugging/Testing/Deployment (highly interactive).

The breakdown happens between phases 2 & 3, at a juncture in the project that we refer to as Feature-Complete.  For a simple project like those in many startup companies, feature-complete occurs prior to BETA and is where all the elements have been built but no data is present and no formal testing has occurred of the integrated product – only individual parts have been tested by the respective teams developing them.

What happens at this stage?

This is the stage where the “rubber meets the road” and everything has to work together. If there are components that weren’t built to spec or data that doesn’t match, or (unfortunately) stuff that was deliberately delayed till BETA, it’s all going to hit the fan right here. And right when investors, potential customers and others expect to see a “working product”. So what goes wrong?

A. Bad timeline assumptions: Business people want to believe that when they’re done “building” the software, that they’re at the 80-90% completion mark. In our experience, they’re closer to 60-70%. The emotion, stress and band-aid fixes that occur when trying to hit an unrealistic deadline lead to even more reactivity and delays.

B. Lack of communication: The software project has to jump back into a highly-interactive mode as each team nears completion of its portion of the system. The premise that if everything is designed to spec, it’ll just fit together is simply not true; specs are not perfect and they are like laws: subject to interpretation. Communication makes up this gap – if it’s not there, guess what? Exactly – lots of guessing.

C. Scope Creep: This most often occurs for two reasons. 1) As the biz dev/sales teams start to get their hands on the final product, they begin to “drive-by” and request features in traditional A.D.D. leadership fashion. 2) Under pressure from leadership to speed up implementation, the engineering team(s) begin pushing feature development from the main implementation phase into the BETA – a violation of every rule, but one that happens very commonly.

D. Bad Data: Go talk to ERP implementation teams about data import and migration. Ask them how it works in real life. The real-life data rarely matches the test data to which the system was designed. Whether you are batching data in, manually, or connecting to a third-party API, the results are always the same: weeks of tweaking to make things “fit”.

So, here are solutions we recommend.

1. Switch Accountability

During Phase 2, implementation, engineering and UX teams among others, are primarily responsible for meeting specs, timelines and performing internal testing. At the feature-complete mark in the project, we switch accountability from implementers to the business decision makers. This means that customer acct managers, business owners and others jump back into the active fray. Why?

Because the questions being asked become ones like these: “Can we launch a product with this known flaw in exchange for accelerating the timeline by 3 weeks?” “Will the investors expect this type of performance at launch?” “Can we get the marketing team to take a different tack that doesn’t highlight a weakness?”

It’s not fair or realistic to ask engineering, design or QA to make those decisions. These belong to business decision-makers. The business team is the one responsible for keeping expectations in check.

2. Plan for the Unplanned

This is the most important. Leave open containers and loops/cycles in the timeline. You’re only lying to yourself if you think you know how the integration, testing and data imports are going to go. Plan loops for testing and for data massaging, etc. Here’s what you can control: The speed of the loops (“we’re going to test a new fix/produce a new build each day”) and you can control your definition of success: (“We will consider it fixed when we see this data on the screen”), but you can’t control how many loops/cycles it will take you to arrive at that success point.

When Boeing built the 787 Dreamliner, they lost a couple years to this process. They had a wing, a fuselage and engines, but they weren’t all together. Pieces from different suppliers simply didn’t fit and had to be rebuilt.

Scope creep is part of the unplanned. SOME creep is necessary because the product won’t survive the marketplace unless critical changes are made. The business owns this phase and engineering shouldn’t pay the price for their changes or prior oversights.

3. JUMP IN! Get it out there.

We say: REAL environment, REAL testers, REAL data, REAL devices. Use them all and use them quickly.

Would you rather fail when you’re controlling the environment or when you’re live?

Don’t be the scared kid at camp on the high-ropes course who can’t step off the platform and holds up the whole line behind them. What’ll happen when you step off is that you’ll slip and gasp, but the harness will catch you and it won’t be fatal, but you’ll learn how to do it a lot faster than the person still standing on the platform. Likewise, your teams will fix bugs faster the sooner they identify them. This is a culture that you can instill even in the most risk-averse team members if you assure them that you’ll be the fall-person for the internal failures, and not them. And then as a business leader, you need to own those failures and protect your team.

Whatever you do, make sure that you set expectations and don’t over plan this phase following feature complete.

‍