Don’t Let Your Project Fail Because of Poor Communication
According to a survey by Richard Discenza, and James B Forman, the top three reasons for project failure were communication, process, and people. Most software problems are people problems, you know.
What is the number one reason for failure apart from poor product-market fit? Wrong expectations. E.g., the team was supposed to build an airplane but ended up making only the body of it with no wings or engines.
Why did this happen? Because requirements changed, but the changes weren’t communicated well, so developers never knew it has to be a submarine now. Or because it took too much time to build the body of the plane and no time left to build wings and engines. There are probably other possible reasons too, but these two are most common.
When the business is out of money and the product isn’t what it was supposed to be, it’s a failure. The project closes. And the seed if this failure is the wrong expectation. The expectation that software development is linear, like construction. The reality is it’s not. The dynamic nature of software development requires the team to adjust everything on the go. It also requires the business to adapt on the go too. And if things change, you need to communicate the change.
Why soft skills
The essential skills you need to have to work with people are communication, empathy, and collaboration often referred to as soft skills. Being able to understand what other people want and feel and clearly articulating your point is crucial for everyone. It’s the last set of skills you will typically learn.
If you are a developer, then you are likely to up your coding skills first. Project managers tend to value various management frameworks and certifications. Entrepreneurs learn marketing, sales, and fundraising. All of them matter, and you can’t be a professional without mastering them. But creating something in isolation is extremely hard. You will most likely need to work within a team of professionals, and you need soft skills for that.
What makes our team efficient
One of the benefits of being a CEO is the number of times I get to think about why our team is doing what we are doing and why we are different. I had a call today, and I had to pitch ourselves. And I realized that it’s soft skills that make us stand out.
I want to emphasize the importance of soft skills for teamwork. It’s not just us who are so unique. You can make your team efficient way too. Lots of organizations think that they are good at communication and empathy, but that’s not true most of the times. It results in frustrated clients, stressed-out team members, and inefficient process. All this eventually leads to failure.
See, every development team builds products. It is implied that if you call yourself a professional, you can deliver. There’s nothing special about it. But we can do that while saving as much of our client’s time as possible. Our process is efficient.
After the initial onboarding and project setup that takes a few weeks, we need only one call per week to sync up with the client. We take responsibility, test a lot, and fix issues ourselves. We know what the client wants so we can make a lot of decisions on his or her behalf.
Empathy and communication
But why is it efficient? Because of soft skills. As I said, we know what the client wants. We ask that during onboarding, we document goals and vision, and we regularly check what we are doing against them. This approach requires empathy.
But we’re empathetic within the team too. Every team member is respected and work without constant interruption. We communicate most of the times asynchronously, meetings are scheduled and have clear agenda and outcomes. We don’t micromanage. Every team member logs hours and tasks, and managers know who’s doing what and when without bothering anyone.
We pay a lot of attention to communication. It’s especially crucial for us because we have a lot of remote employees. You can’t just hope that people will find a way to collaborate when everyone is working without pants at home. You have to design communication, organize it. All decisions should be traceable to its source, and all notes have to be saved for future reference.
The communication with clients is clear and transparent too. Every hour spent is logged and attributed to a task. All tasks belong to features, and we know how much effort each feature required. It allows us to forecast future work more accurately and enable the client to learn the process and make better decisions in the future.
Why Scrum sucks most of the times
There are many attempts to make communication within the team more efficient. Agile manifesto tried to do that. It made a lot of impact, but a lot of organizations still do it wrong.
Scrum is an excellent example of a great idea implemented poorly. Managers love it because it makes developers responsible and offloads the risk to them. But it applies much more pressure at developers and designers, makes them work faster, not better, while simultaneously leaving less time to do actual work. An approach like that is bad for the business because it results in poor results and slower progress overall.
Just the fact that you now have daily standups doesn’t make your process more agile. Moving from Gantt charts to Kanban boards alone don’t add more visibility into the project. Removing documentation or skipping unit tests isn’t going to make you deliver results faster.
Most of the applications of agile practices are cargo cult. Have you heard about that phenomenon? The name derives from the belief which began among a tribe in New Guinea. The tribe was building an airplane runway, hoping that goods will appear on it (i.e., “cargo”), because those goods were delivered to them via airplanes. They even built mock airplanes to increase the odds. It didn’t work for them. And blindly applying Scrum, SAFe or any other cool management framework won’t work too.
Is it possible to build software products on time and within budget? Absolutely. But we must accept that they are dynamic and communicate well to adjust as we learn more about what we are building during the project. Only then the plane will fly.