What We Have Here Is Failure to Communicate
10 reasons why Software Development projects fail 2 of 5
--
Communication is vital at every level of a software development project, but you’d be surprised at just how often this fundamental rule is broken. And when there’s no communication, that’s when the final product created can look very different from what was sold, promised, built and ordered.
If you’ve ever seen the cartoon called “Tree Swing,” you’ll know exactly what I’m talking about. The cartoon consists of 10 different images, each one showing a different version of a “tree swing.” As you might have guessed, there’s something very wrong with each and every one of these tree swings. The first image is very innocently captioned, “How the customer explained it.” Instead of showing the sort of iconic tree swing that we enjoyed in our carefree youth, it shows what looks like three different swings combined into one, all hanging from the same tree.
And each image gets progressively more absurd from there. For example, by the time the sales executive has described the project, the tree swing now includes a massive blue armchair suspended from the tree. The final image is the most telling — it shows a humble car tire hanging from the tree instead of a swing, with the simple caption, “What the customer really needed.”
There is perhaps no better visual that can convey why a failure to communicate can be so harmful for a software development project. It doesn’t take a rocket scientist to realize that building a better mousetrap (and a better tree swing) is going to require plenty of communication, at several different levels.
First of all, there needs to be communication at the team level. All developers on the team need to be on the same page. Moreover, each one of these team members needs to commit to regular communication, especially as new issues arise. It’s great to schedule a Monday morning check-in call every week, but if a question pops up on a Thursday, then there needs to be a process in place for team members to meet before Monday.
And, secondly, there needs to be communication between teams. Typically, it is the role of the project manager to convey all issues and problems with external stakeholders. This is easier said than done, however, because it often requires a simultaneous translation between the strange foreign language spoken by software developers and the even stranger foreign language spoken by MBAs and senior executives. That’s why simple tree swings often transform into overstuffed blue armchairs suspended from trees — the sales and marketing team may be so eager to sell a new product that they ignore what’s actually feasible or practical.
If you’re looking to keep your software development project on schedule and on budget, then make sure you’ve opened up all lines of communication with your team members and empowered them to talk about issues in real-time. Otherwise, you could wind up like the Paul Newman character in the classic Hollywood film “Cool Hand Luke,” rolling around in the dust, and your manager standing over you while repeating the famous line, “What we’ve got here is failure to communicate.”
Failing To Plan Is Planning To Fail
4 of 10
It’s always surprising how many software development projects launch without a real plan to complete them. Of course, there may be some hazy estimates thrown out during meetings, like “try to get this done by the end of the quarter,” but what I’m talking about here are real, actual plans with dates, deadlines and milestones. In short, what needs to happen (and in what order) for a project to be completed on time and on budget?
Of course, it almost goes without saying that any plan is bound to encounter its fair share of delays, revision and re-thinks. In the world of software development, that’s par for the course. Clients will inevitably call at the 11th hour, requesting a change or revision that might set back your project days, if not weeks. And emergency “fire drills” happening in one part of the company might siphon away critical resources, including valuable manpower.
But here’s the thing: a plan for your software development project gives valuable structure to your team. It enables team members to provide estimates about when a certain leg of the project is going to be complete, so that when the VP of Operations is giving you a call, demanding to know when the project is going to finally be ready, you’re ready with a response.
This insight into how long a project is going to take and how much it is going to cost is especially important for large software development teams, simply because there are more people to keep in the loop. More moving pieces = more complexity. And, don’t forget, you might be working with developers based offshore or in a different city, and that is going to add in even more variability and uncertainty to the process. So a master plan is one way of keeping everyone in the loop.
When estimates for a plan change, it will have a very significant impact on the overall budget. Simply going a few weeks over schedule might cost the company tens of thousands of dollars. As a result, you have to make sure the estimates being used for the plan from the very beginning are actually reasonable.
It’s not reasonable, for example, to expect that a major app project is going to be complete in just one week. And it’s also not reasonable to expect that a software development team is going to be able to complete a project if it is constantly encountering resistance from upper management or not getting access to the right resources to get a project done. Oh, and it also doesn’t help if a key member of the team suddenly quits, or if corporate HQ calls and tells you that funding for the project has been slashed because of an upcoming merger or acquisition.
Ultimately, there is a very important link between getting a project done on time and getting a project done within established budget parameters. The link, of course, is the plan. At the end of the day, failing to plan is planning to fail.
Hey! I’m Tomer, an entrepreneur and maker. You might know me from Mevee, Crane, and Shots, among other products I’ve launched! This article is a part in a larger series I’m writing mostly based on my experiences, and is largely made of my and my team’s opinions.
I hope this helps you to avoid making the same mistakes I did, and remember to keep shipping!
This article is part of a series 10 reasons why Software Development projects fail :
