Home - AP LogicAP Logic

We Experienced Project Defeat In The Final Stretch Until We Changed Three Things

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.

Mozart, Einstein, George Patton: All were people who lived far from the average, “middle-of the bell-curve” and accomplished incredible things. These outlier team members help make so many start-ups exceptional. But these same outliers run into challenges that extend from their out of the box thinking. Founders often fall into this category as well. So, ourselves and our clients, how do we manage exceptionally talented weirdos (I include myself, here)?

First – Define the deal-breakers and stick to them. If you’re not clear on what you’ll allow in terms of eccentricities and tradeoffs in your company, how will you get anyone else to feel like you’re being fair to them? Don’t tolerate certain behavior around your team or clients and be ready to fire those who step over that line. Besides the obvious/legal deal-breakers, there are cultural cancers: talking behind people’s backs, passive-aggressive behaviors, always being late or forcing others to step in. We tend to focus more on technical skills and “chemistry”, but these cancers kill morale for the responsible team members who feel like they have to carry the burden of the others. Once you clarify the deal-breakers, let the other, smaller stuff go and don’t beat people up about it.

Second – Give unique people a bigger voice in the projects they are involved with on a day-to-day basis. When people know that they’re perceived as different – especially introverts – they will tend to not speak up because they’ve heard about their uniqueness once too many times. I include team members in project meetings and take lunches with them from time to time. Some of the most valuable insights into our company have come during those lunches or small project meetings because someone had permission to speak and they would warm up to the idea. A bigger voice also means asking them for project input outside of their job-description. I’ll admit that this can backfire if someone lacks social perception in a situation where restraint is required. But mostly, you’ll benefit from their input. We’ve solved many problems by letting people who are uniquely gifted bring their opinions to the table.

Third – Lead from the big picture. I’ve often pulled a couple team members into our conference room, given them a quick “No one may have told you this very directly, but this is what makes or breaks this project.” My employees have later told me, “That was the ah-hah moment where I switched strategies and the project came together.” You have to continually go back to this vision – the large objective. Even clients forget their own objectives. In the heat of battle, we all are prone to tunnel vision. Some of our most talented, focused people are also the most prone to tunnel vision. Even if an individual is not, the further out on the bell-curve that individual is, the more likely their viewpoint far exceeds our own.

Try explaining the big picture from different views (for example, from that of a competitor or a vendor, or a government regulator) rather than just a prototypical end user.

Fourth – Get a “readback” – a tip from the flying world. Again, very unique individuals hear things very uniquely. These team members should read back the objectives and explain what they think they hear in their own words. I’ve paid a much steeper price than the cost of the readback by neglecting my own advice here. To one person, the “frontend” often means something very different than to another.

Good luck and please feel free to share your ideas and experiences!

Great Startup Ideas…

Deserve Great Execution

Software Development and Team Coaching for Startups

Our Process

Our Work

Digital Content Distribution for Prison Systems

Personality Profiling and Leadership App

In-home tutoring services for over 30 cities

Ideas We all have them. Here are ours.

We Experienced Project Defeat In The Final Stretch Until We Changed Three Things

Dream Team: Make that crazy one your biggest asset

Building A Business That Is Bigger Than You (Guest Blog)