Small vs large projects

I want to share some thoughts about setting software projects up for success. Success can mean many different things, so I’ll discuss a couple meanings in this post. Mostly solid quality and team happiness, rather than budgets and timelines.

I’ve been writing software for over two decades now. I’ve been a part of both successful and failed projects across a variety of topics. Everything from writing software for a smart TV remote, marketing sites for Kodak and P&G, search functionality, and most recently streaming data platforms with nearly a billion events per day at Nike. Regardless of the domain, there are some common traits that stick out in my mind that impact the ultimate outcome of the project on the success or fail scale. I add a note below about team turnover as an outlier for measuring success. I won’t cover obvious things like costs and budgets. Most projects are simply measured by money in order to be determined successful . But is money the only factor? For this post, I am focused on things that can be done in order for the team to consider the project a success, not the CFO.

The first consideration is the size of the project. Not number of lines of code, or even daily users. Size in this context means scope. Is the body of work trying to do too much from the beginning and setting the team up for failure? A report from the Standish Group in 2016 listed the size of a project as the top reason for succeeding or failing. From my experience, I completely agree.

Ideally, I like to see teams take the first couple of days of starting a new project to just write out user stories. I’ve been an individual contributor in these “planning” sessions, as well as lead them. The goal is to brainstorm all the little pieces that make up the project and catalog them via consistently formatted user stories. At the end of the exercise you start your story mapping of the functionality and scope. You identify the various iterations and priorities. To me, the takeaway in all of this is the identification of functionality that is required for the first iteration. This breaks the entirety of the project down into a small deliverable chunks of work. By narrowing the focus, even with knowing what comes next, you set the team up for success. They can hold the entire scope in their head and concentrate on delivering it. Not to mention the shared understanding. I’ll write a followup post on how much I value shared understanding. If each iteration is a success, it’s more than likely the entire project will be a success.

But what do we mean by success in this context? Is it simply shipping the first iteration? That seems like a success. Not shipping seems like a failure, assuming we are really shipping the correct thing, but let’s assume we are. Shipping makes the team happy. That’s success! Establishing the foundation and setting the project up for future iteration seems like success. There are a lot of success definitions that can and should be celebrated. Breaking projects down into small deliverable pieces is key to making a project successful.

Let’s back up a bit though. Is simply taking the time to define the project first before you jump into it a beneficial step for success? I would say so. There have been too many times I’ve recognized where a sense of urgency meant skipping the essentially planning phase. It happens all the time. We receive a bug report, or there is some new functionality that needs to extend something as simple as the login form. A 15 minute meeting happens to describe the problem to at least one engineer and they go off to implement a solution. Without taking the proper time, maybe say an hour or two, to properly plan the “project”, meaning the scope, the end result can be failure. Maybe in the form of technical debt, maybe in the form of implementing the wrong thing.

Right after size of the scope of the project, I would list proper planning as a quick second factor to setting projects up for success. As a manager, I am constantly reminding myself to identify when we as a team are being impulsive and jumping into some work without properly planning it and treating it as a project.

Now that we’ve covered proper planning and size of projects, let’s discuss having the right team to be successful. Teams take on many shapes and sizes. I’ve written about team roles in the past. I won’t discuss the various roles that can make teams successful, I’ll just mention the continuity of the team as being a different way to measure success. Simply shipping a project can’t be thought of as successful if the whole team quits in the months afterward. Hiring takes time and is costly and will impact the project. I’ve experienced this more than a few times. The start and stop and turnover always impacts the quality and therefore impacts the success of the project in my mind.

It’s easy for all of us to focus on the technical bits and the functionality requirements when starting a project, but how often do we ask ourselves what would make the project successful in the end, before we get started? Given the scenario, we define a project scope that is pretty straight forward and small but the engineer has no domain knowledge and takes 2 weeks versus 2 days to complete the project, is it still a success? Impulsively, we might say it was a failure because it took too long. But, maybe one of the “success” factors going into the project is to provide a learning opportunity in addition to the completion of the functionality. Without defining that ahead of time, it would be easy to say the project took too long and was a failure.

There are many ways beyond money and shipping that can play into the definition of success for a software project. Something I will be spending my efforts on in the near term is defining what success looks like before we even start a project. If you have a practice of defining what success looks like, I would be very interested in seeing it. As an industry, I think our definition of “success” or “failure” needs to be examined. Once we define success, we might get a little better at setting ourselves up for it.