What is the one thing that can make or break a software development project?
We'll give you a hint - it's not the skill of the programmer, or the project methodology, or the way the app is programmed. It's an often overlooked skill - communication.
The effectiveness of communication is the barometer of success or failure on any and all software development projects.
While that may seem like common sense, the impact of a communication failure (or multiple points of failure) can have cascading and lasting effects - for clients, developers, and end users. It's an evergreen theme that always presents with more opportunities to learn and do better.
Communication is not a milestone or an end point, but a journey that must be continually navigated.
Software development is like following a blueprint - as long as you know what you want, it's straightforward and predictable.
All software development is both a science and an art. With all the different types of programming platforms and coding languages available, the possibilities are almost endless. And there is often more than one way to accomplish the same thing. In other words, if you asked two different programmers to develop the same scope, you will likely come up with two very different applications - both front end (user interface) and back end (coding and database).
When developing new software or committing to major code upgrades, how communication functions among stakeholders, project managers, developers, and testers directly affects the outcome.
In this case, stakeholders and project managers must play an active role in articulating clear use cases and narrating the intended consumer journey. Often, this means using data to objectively define success instead of speculating on what users want with no means to measure or track.
But that doesn't mean that developers are off the hook! Skilled programmers should be able to articulate what's possible and best practice - from a functionality and end user standpoint. Developers are your first line of defense against creating a piece of software that is too convoluted or complex for users to navigate. They are also critical to understanding realistic timelines.
Unless you have a NASA-sized budget, your software is going to have some bugs in it. With proactive testing, many of these initial bugs can be quashed before a full version is released. While some software testing can be automated, having beta users or official software testers can help you work out any unforeseen issues. However, this group needs to be highly effective at communicating what issues they are experiencing and what steps can be taken to replicate any issues.
Do you feel like you are going in circles on a particular issue? Are you spending hours trying to interpret the latest cryptic email?
These five warning signs indicate a potential communication issue and how they might be addressed.
1: Multiple emails back and forth on a particular issue.
If you find yourself in the "email spiral" describing and resolving a specific issue, it may be time to get on the phone to resolve. Often talking through a complex issue can actually save time emailing back and forth. If that doesn't work, escalating to another team or third party may help bring some clarity to the issue.
2: Recurring meetings with the same or no agenda.
While regular project meetings can be effective, if there is nothing new to communicate or the communication is a simple progress update that can be done via email, it's time to remove these meetings and replace with time spent on the project. Consider where you are in the project lifecycle - if you have moved out of initiation and planning, and are on execution - it may be time to let the team execute and enable more agile forms of communication through the execution process.
3: Constantly changing requirements.
Is the project manager constantly coming back with new or updated requirements? This is a major warning sign that the scope is not clearly defined or articulated. The best solution here is to pause on any execution and pull in a multi-disciplinary team to get clarification and understand priorities. While it's true that requirements can change throughout the project, if there is too much back-and-forth it will create confusion and distort the end result.
4: Too many or too few voices.
Software development is often iterative and requires meaningful input from a variety of stakeholders and project members. Make sure everyone understands their role and is an active part of the conversations - if you have too few voices, it may mean one perspective is dominating others, and conversely, if there are too many voices, it may mean people are not on the same page. There should be a balance of agreement and constructive feedback.
5: Lack of project documentation and reliance on a single communication channel.
Do you have the project scope written down? Are major decisions and action items being properly documented? How are team members able to communicate? Communication should use the variety of channels available - from email, to text/chat, to phone calls to meetings to shared online spaces. Project contributors should be able to share and document in the most effective manner based on the scope of the project and the needs of the team.
... and when you think you've communicated enough, communicate one more time.
The single biggest problem in communication is the illusion that it has taken place.
-George Bernard Shaw