This blog post assumes you have a contract or agreement to get software built. Or, maybe you are in a company and you are tasked with getting software built. Either way, I’m going to share what I think is the most crucial element in your success.
If you don’t have a project in front of you or you are trying to pick a vendor, then this still applies, though a little less.
So what is the #key?
The key to successful software projects is and will always be COMMUNICATION.
Nothing derails a project like poor or little communication. That’s why before I will agree to terms, I need to get on the phone with the person on the other side of the project. If they aren’t willing to talk, then I will decline the project.
I haven’t had too many projects go sideways, but one of them was a lady who initially wasn’t willing to jump on a call with me. I should have run the other way but I didn’t, and it led to us having a bad working relationship, and again, she wouldn’t get on a phone call to resolve anything, so I had to end the contract.
So what exactly do we mean by communication in software projects?
Communication leads to an understanding of the work that needs to be done, who needs to do what, and what is most important.
Understanding the work to be done
Understanding of the work to be done entails explaining and being willing to explain again. Some people, after they explain something, aren’t willing to say it again in a different way. As if everyone is or should be just like them. But people are different. People see things differently. And people learn differently. So be willing to explain again, and again, if needed. Also, and this is very crucial, just because you understand something doesn’t mean everyone else does too. So after discussing something, recognize that the other party may have walked away without knowing what they need, so they will be back for more explanation later. This is fine and hey, we’re all just human right? 🙂
Understanding also entails give and take. Software projects are always morphing, as they typically should. If you come up with a design and sit on it for 2 years, the business and competitive landscape is going to change, among other things. That means the original design needs to change. By the same token, projects might change over 6 months, or even a month. This flexibility requires give and take, an understanding that things are defined today but can easily change tomorrow. Both parties need to recognize and allow for this.
Who needs to do what
In software projects it’s important that everyone knows what part of the work falls to them.
In a client / freelancer situation, typically the freelancer owns all the development work, but some clients are also developers and they will be performing some of the work.
What is most important
I cringe when I hear that everything is the same priority, because it’s never true.
Either from the client’s perspective there are ‘must haves’ and ‘nice to haves’, or from a developer perspective, some things are foundational and must be done before other things.
Two ways to evaluate priorities are MVP and SLC.
- MVP: Minimum Viable Product – this is figuring out what are essential elements to your first release. Typically this accompanies a lean software development approach. In this philosophy, the most important things are the essentials, and the rest of the work is not essential. And from there you can further prioritize what you want done first.
- SLC: Simple, Lovable and Complete – from Taylor Otwell of Laravel, this encompasses the elements that are needed for V1 of your product, but requires the first version to be simple (in line with the lean approach above), lovable (this includes styling, user experience, and actual usefulness), and complete (which means it accomplishes something useful from end to end.
Getting to the priorities is essential to a fast moving and successful project.
Without communication, any software project is going to fail.