Start Small

If I could only give a single piece of advice to maximize the chances of a software project being successful, this would be it: start small, no matter how big the project. Instead of trying to come up with a detailed plan, start with a smaller, simpler plan with a predefined goal. It’s a bad move to go all in on a big project, use the budgets all at once and hope for the best. Time and time again, it has been shown that this is a recipe for failure.

It all comes down to Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

— John Gall, Systemantics (1975)

John Gall was a pediatrician who studied how systems work, evolve, and fail. He came up with this line, which has become a kind of systems law. He realized that creating a simple system and evolving it is much better than creating a more complex system from scratch. In fact, sometimes it’s the only viable solution. Using John Gall’s systems thinking, we can suggest a better way to build products. First, create a minimal version of the product, which does something useful, a “system that works”. Then add functionality on top, without breaking the old features. The product is always “a system that works”. Sure, breaking down a big project into “working system” (milestones, phases, or versions) can be a bit of an art. Sometimes big parts of a product take a lot of time to implement to be useful, but still, this approach yields better results than trying to build everything at once.

Note this iterative approach does not mean to build large systems in parallel. When you are about to do a big project, you might be tempted to split the work, work in parallel, and then merge the work near the end. In practice, though, integrating the work is a messy process. For example, it’s possible that one of the designated teams finishes before the estimated date and has to wait for others for integration. Then, when other teams are done, they may discover a feature doesn’t work as expected, leading to big changes and missed deadlines. To avoid some of these issues, you might want that teams communicate more often, but this can also set the project back, since coordination efforts start eating a good chunk of the available time.

Minimum Viable Process

This approach, consisting of an initial smaller project that is then iterated upon, is similar to the MVP (minimum viable product) described in Eric Ries’ book The Lean Startup. What I’m suggesting, though, is extending the idea not just to launching new external software products, but to internal software, hiring development teams, and project management. These factors directly impact the chances of success or failure of the project, but many times companies don’t realize that risk can be mitigated by focusing on decreasing the resources initially allocated to the task.

Here are a few examples:

• Internal software: companies should launch earlier and validate more, since it’s easier to ask your employees if their software is working for them, or if they find friction. Also, design polish (looks) might not be that important, while ease of use certainly is.
• Recruiting: when possible, hire contractors and then move them into a full-time role. If your company has the process to do this, it saves a lot of headache due to bad hiring decisions.
• Hiring agencies: start with smaller projects, then move to bigger projects.
• Project Management: minimize the scope of the project. Learn from it. Then plan a bigger project.

Every step of the way, starting small saves time and money.

Caveats

It’s key not to confuse mitigating risk and allocating resources smartly with being cheap. Software Development is one area where tackiness can cost way more than it saves. It’s true that good software developers can be more than 10 times more productive than average ones. Bad software developers can even subtract productivity from a team. Talented technical managers who deeply understand the system, the goals, and the people, act as a force multiplier and are worth their weight in gold.

Another important factor is that, for established companies, the standards are different. What is “minimum” for a startup is not the same as what’s expected of a Fortune 500 company. The design, performance, and features have to be up to par. But this doesn’t mean that they should overspend.

Finally, some stages of the software development process are more or less a fixed cost, so it’s worth it to spend a bit extra to get a better job, especially if those are early in the project and can help steer it into a better direction. Project planning and product design are particularly good candidates for a nice upfront investment, if done properly. Just make sure project planning is high-level (resources, time, expectations) and not too specific (architecture diagrams, technologies, and vendors). It’s a common a mistake to be too specific too early in the project.

The pit of success

Working in iterative steps makes success more likely because it makes it easier to automatically take the right steps while avoiding many of the risks. For example, it is a common problem for many projects to start with unrealistic expectations of what is achievable, and unrealistic cost and time estimations. Iterative development makes it easier to get a glimpse of what the solution will do and what it will take. It’s also easier to get early feedback from users, since showing them a working product is better than asking things in the abstract.

Early versions of the product, even lacking important features, also simplify the process of getting sponsorship from executive management, since the value of the project becomes evident. “Show, don’t tell” certainly applies here.

Many other factors are also simplified, like ironing out communication issues and checking the right technical talent is in place. Smaller project, smaller problems.

Software projects are not special. Big projects are hard.

Some people think that software projects are specially hard but, based on my research, I don’t agree with the assessment. In civil engineering, the failure of big projects is an every-day occurrence, not at a different rate that software projects of equivalent size. It’s not that mega-projects like a 20km bridge fall down every other day, but they are often over budget, over schedule, and at times even abandoned completely.

Where software is a bit different is in these aspects:

• Software appears easier, since it’s harder to visualize. There are no huge building blocks to move or tons of concrete to pour. This creates the appearance of something light, when complex software projects mean heavy work.
• The solutions are infinite. There are multiple ways of achieving the desired outcomes, so there’s more room to make wrong decisions. It’s easy for stakeholders (project managers, developers, management) to add unnecessary complexity without realizing it.

Case Study: CNN+

CNBC - What doomed CNN+?

CNN+ was a streaming application created by CNN that was canceled just one month after its launch. The reasons were many: inflated expectations, unclear strategy, and unstable leadership, but CNN could have saved a huge amount of resources by creating a phased launch and leveraging existing technology, that is, by starting small.

Here’s a list of mistakes they made, and how starting small could have helped:

Inflated expectations

“The CNN leadership envisioned CNN+ as something akin to The New York Times – a subscription news product that would eventually house video, podcasts, and all of CNN’s interview and entertainment programming.”

It would have been better to launch and test the waters first. Launch a smaller app with some mix of exclusive and already-existing content, and then start expanding the catalog based on its reception.

For CNN, it wouldn’t have been too hard. They could have asked their viewers and even offer special deals for early subscriptions.

Lack of management buy-in

“Both Zucker and Kilar were caught off guard by AT&T’s decision to spin off WarnerMedia and merge it with Discovery Communications”

When upper management is not committed to a big project, it’s better to pause and re-assess. A big change of plans means the priorities have changed, and one should act accordingly.

Wrong buy-vs-build decision

“Zucker wanted to launch the service in January but ran into technical trouble. CNN was making a product from scratch with a brand new tech stack, rather than simply building on top of HBO Max. That took time, and CNN didn’t want to launch a buggy product. Zucker and Morse recalibrated to launch at the end of March.”

Here, it would probably have been better to leverage the existing software, instead of building new software with a new tech stack. Good software takes time, and it’s hard to estimate with any amount of precision.

Lack of resources

“At 8 a.m. ET on April 11 — the first day Warner Bros. Discovery began trading as a combined company — Licht and Perrette told Morse and his team that CNN+’s marketing budget was immediately going to zero. It was Licht’s first meeting at CNN.”

The marketing budget is a key component for externally-facing software. Before a project starts, it’s key to confirm (preferably in writing) that enough resources are available for the project.

Lack of alignment

“From now on, CNN’s strategy will have to align with its parent company.”

Conclusion

CNN was feeling the pressure to catch the streaming wave and failed to foresee that both management and viewers did not support the project as much as they hoped for. By starting small, they could have at least saved money and resources, and even launch successfully at a later stage with the information they gained.