The Budget is Set. Now What?

Projects are sometimes doomed long before any designers or developers are brought in. Your work will never provide value or even see the light of day if you are working on something where the only possible outcomes are failure and mediocrity. But some can be saved. You can make it work. Your career will be better off if you can learn to avoid these projects and work within given constraints.

The first design decision on your project was made when a budget was allocated.

Mike Monteiro, Ruined by Design

I use Mike’s broad definition of design: making decisions on how a system works is doing design. Stakeholders, project managers, and developers all design. Marketers could also benefit by realizing what they do involves design. Some developers don’t see it that way. They think they just write code. That’s wrong. We’re problem solvers, systems designers, and the people who need to help others navigate this ever-expanding technological jungle we are building. We can deliver better work and more value to those we serve if we understand our role in the design process.

Let’s take another look at the budget.

Various software projects can be attempted, sometimes even completed, for just about any budget. You could build a real estate listing site for $5k, $50k, or millions of dollars. You could spend $32 million building a holistic solution and not ship a damn thing.

Budgeting for software is like buying a house or a car. There is a wide range of options, and it depends on your situation at the time and plans for the future. And like major lifestyle financial choices, typically the budget is the biggest constraint we have to consider when building software.

Then our challenge is this: how can you help projects fit into a predetermined budget?

Make Responsible, Considerate Technology Choices

Different tech stacks come with different costs. If you are implementing the work one of the biggest factors may be your experience with it. Using the shiniest new tool is often not going to be the most efficient. Plenty of successful projects have been shipped with WordPress, PHP, or Ruby on Rails, and were successful.

Let Only The Best Features Survive

If you can’t fit every feature in, you have to decide which features need to go. That’s part of the design. As a developer, it is your responsibility to help stakeholders understand the value of work that may not seem apparent. People will want you to do your job poorly, and call it “cutting features.” Security, accessibility, usability, and testing are not up for debate in this conversation. Those are features, those are taking care of the people that use what you build. Ignoring them makes you a jerk.

Instead, strong candidates for deferment or deletion are features where you say “we may need it one day”, or “what if…”. If you aren’t sure if you need it and you need to make cuts, start there. The more user research that has been done at the point, the more confidently you can argue for these changes.

If a feature doesn’t need to be killed outright, then you can always defer it to the next version. Keeping things for a version 2 or 3 means can be more palpable than saying they won’t be done outright.

Nail Down Requirements With Scope Hammering

If you can’t cut a feature, maybe you can pare down a feature. I love the term Scope Hammering. As Jason Fried puts it:

We take the chisel to the big block of marble and figuring out how to sculpt, nip, and tuck a feature into the best six-week version possible. It’s all about looking carefully at a feature and figuring out the true essence. Not what can it be, but what does it need to be?

Jason Fried, How we Structure our Work and Teams at Basecamp

Make every form field, database column, and page defend its existence. For example, once I worked with a company that wanted users to enter their email, password, username, business name, age, and gender on a signup form. This raises all kinds of concerns, and opportunities to pare down scope:

• Do we need a username? In this case, business name would suffice, so we can cut that field.
• Why do we need to know age and gender? Should the gender field be a radio box (with how many options?), or a text field? Why do we need this data? We didn’t have a plan for how use it beyond “…marketing?”, so we can avoid these design discussions and ethical quandaries by eliminating them all together.

Now we have a simple form with two fields. Its probably more effective with less and time and resources invested. And now that it is something that fits into a common pattern that brings me to my next point:

Don’t Build If You Can Buy

Something built from scratch has no more inherent value than an open source library, paid plugin, or 3rd party API within your application. One of the biggest mistakes I see developers make is to try and build their own solution when perfectly cromulent solutions exist. Often times, A pre-built solution will have been more battle-tested, and therefore reliable than building something from scratch. There are situations where it makes sense to build your own solution, but there has to be a good justification. Either there is nothing that exists, or what does exist meets your required use case (see previous two sections.)

When All Else Fails, It’s Time to Get Real

Sometimes, you can cut features, reduce the remaining features down to their core essence, and find a way to piece together a solution with existing tools and services, and still not have a way to deliver what’s requested within budget. What do you do with stakeholders then?

You tell them.

Let me tell you a quick story. I once have several phone calls with a potential client. They wanted to start a new project that sounded interesting and seemed like it could do some real good in the world. I was excited, and so was she. Then, we get down to talking about price.

Me: “I think a project at this scale would be in the range of $15,000 – $20,000”

Her: “My budget is $500.”

I was crushed. I had put so much work into the project proposal and now I knew it wasn’t going anywhere. There’s another lesson in here about doing budget discovery, but that’s for another article. Instead, it didn’t matter what I designed. It was superseded by the design choice that was already made.

At this point, I could have ended the call and marked the deal as lost in my CRM, but instead, I took the opportunity to try and help this person understand the costs of what goes into software development, and tried to help them have more realistic expectations.

Project planning with stakeholders should be collaborative, not combative. If you can find alternate solutions that work within the budget, do it. If you can’t, have an honest conversation about it.

Take Ownership of Your Responsibility to Help Others

A project’s success lives or dies on every decision that is made along the way. Sometimes those decisions are out of your hands, but other times you have an opportunity to help those decisions end in conclusions that help a project move towards success. That’s the real job of a developer, not just to write code.

P.S. If you want to learn more about delivering software on time and within budget, you can learn more by checking out a sample chapter of Dependable.

The post The Budget is Set. Now What? appeared first on Glenn Stovall - Growth Engineer.