You’re not going to get very far in our industry if all you do is build stuff for your clients.
When building software, you need to view the relationship with the client as a partnership in which you’re both lending your expertise to the task or project at hand.
As we’ve said here previously, the key to a successful partnership is trust and trust doesn’t come easy in this day and age.
Again, to combat that, we often discount our first contract with a new client to establish that trust.
The first contract’s goal is always going be to build the relationship.
Once that trust is built into the relationship, the possibilities for a successful project expand exponentially.
With trust – the relationship goes from “You do this and I’ll do that.”
In those relationships, the client must tell the software team exactly what to build and the software team must build it exactly that way – whether it’s a good idea or not.
Trust builds cross-functional teams; where the client can say “Let’s use PayPal to accept recurring payments.” and the software team can go back and say “PayPal has a horrible API and terrible dev tools compared to Recurly.”
The client will have no idea what any of that means, but can defer to the software team as experts without worrying about an ulterior motive – “Does Recurly cost more? Is that whey they’re saying that?”
Now you have a working relationship where both parties are free to express their views and expertise.
Obviously, the client is the ultimate decision maker, but that client can now make informed decisions based on feedback from the software development team.
That is probably the biggest key to success – creating a cross-functional team that can speak openly at all times.
However, in cross-functional teams, there are a lot of common themes we see that can hinder or promote the project’s success.
This one is critical for a number of reasons, but first, let’s expand on what we mean here.
As we’ve said perfection kills and if you wait on perfection, you’ll never launch the project and if you never launch the project, the project, by definition, will be a failure.
Typically, we work in Agile-style sprints because we’re usually developing new technology that doesn’t have a firm definition.
It’s more like “we have this loose idea but we’re going to firm it up as we go along.”
And we love that, but it has to be done with boundaries.
So the point here is to set a boundary – time, budget, something – at which point you launch the project.
The great thing about software is that it’s easy to change and nothing is final.
Building software is not like building a house. Decisions aren’t final.
This is both a blessing and a curse.
Because it means that you don’t have to get things perfect the first time, but it also means you can get stuck making change after change.
This is where the boundary comes in.
“Sure. We can make that change, but that’s going to take an iteration, which costs you about $x and we have $y left in the budget”
“Absolutely. We can make that change, but that’s going to take an iteration, which is a week long, and we only have x weeks in the deadline.”
This makes the client prioritize the change requests.
Especially in revenue-generating projects, it’s so important to launch early.
The money and time saved on launching early goes to marketing and user feedback, respectively.
More importantly, the earlier you launch, the sooner your project will start generating revenue or saving costs, which means more budget for the client to make all those changes they wanted in the first go around.
Or just as importantly, realize that those changes weren’t necessary in the first place.
It’s so important to have a process for everything.
We meet every Wednesday at 1:00 pm.
Change requests are done via the project management tool.
Email is the first line of communication.
We deploy changes every Tuesday at 4 pm.
Your process doesn’t need to be perfect, but it needs to be a process.
This will allow the participants in the project to focus on what each does best rather than scrambling to figure things out every single time something comes up.
It’s important to have and follow a process, but you have to know when to step outside that process.
Our rule of thumb is that there is no such thing as over-communicating.
When in doubt, send an email.
When you think there may be doubt, send an email.
For example, if a client emails you every day and asks for an update, but then doesn’t send you an email for three days, assume they may not be happy about something.
Send the update email proactively.
Is a feature due this Friday, but something happened on Tuesday that makes you think there might be even a slight chance it’s not delivered by then?
Send an email. Tell the client what happened and what your new plan is.
We’ve never had a client complain about communicating too much.
So those are three keys to success we see on every project.
Obviously each project is unique and will have different success factors, but those three are pretty standard across nearly every project we tackles.