Most organizations will experience failed software projects. They wont necessarily crash and burn, but they will fail to deliver the value the customer wants. In other words, the software projects will not deliver an appropriate level of quality for the time and resources invested. The extent of failed software projects is calculated every year in the Standish Chaos report– reporting software failure as 61% in 2013. There are many reasons for that kind of project failure rate. They range from poor requirements processes, to badly managed deployment, and a collection of other issues.
Many authors have written about this, from the industry changing first work by Fred Brooks, The Mythical Man Month, to more recent works by the Agile and lean communities, but I dont wish to re-hash these ideas here. I do, however, want to point out something that causes much trouble, pain and confusion in software projects– Email when used as a primary collaboration and process tool.
Imagine the following situation
A tester discovers a bug, he documents this bug in his tool of choice (for this example, HP Quality Center), but because it is an important and interesting bug, he also sends an email to three developers who have worked with him on previous bugs. One of those developers replies directly to our tester with notes. The tester replies, adding a business analyst who is no longer involved in this app. Said analyst forwards the email to another business analyst who replies to the tester and yet another developer. The tester, business analyst and developers all agree on a solution, but the tester does not document this in Quality Center. That night, a CSV comes out of Quality Center and is converted into a spreadsheet by the project manager who allocates the bugs to the team. The special bug that the tester and colleagues were working on is allocated to a different developer, someone not involved in the email discussion. This developer talks to a whole different set of people to build a resolution. Sounds far-fetched? Its not. I have seen much more complex communication networks created on projects. They resulted in confusion and a general disconnect between teams. And this issue is exacerbated across the departmental boundaries of QA, Dev, the PMO and operations because email is a poor way to collaborate. Why? because the TO and CC lists vary depending on whom the sender knows. And the original bug is just a memory by the 2nd or 3rd reply.
Email isolates teams rather than uniting them. In fact, I would go one step further. If email has become one of the primary ways your project team collaborates/works, I would say email has become Evil, from a project success point of view. To quote Wikipedia, Evil, in its most general context, is taken as the absence of that which ascribed as being good. This description accurately describes email when its used to drive development, resolve issues or communicate progress. Most email begins with good intentions–adding additional people, replying out of your goodness of heart–but after the first few replies, it descends into layers of confusion, miscommunication and errors.
Email is evil because it:
- Does not automatically go to the right people
- Does not always include all the right information
- Is easy to drop and add new people, adding to confusion
- Is not stored, indexed or reference-able after the fact (unless you are the NSA, but that is a whole different blog post ;))
- Holds no status or meta-data that allows for quick search or filtering
Maybe labeling email evil is a bit dramatic, but you get the idea. Email can easily, if not effectively managed, cause problems in your software projects. For that reason, we should reduce our reliance on using email to drive real work.
If you doubt your reliance on email, answer the following question: Can you stop using email for project related activities for one week and instead use your systems, processes and tools to get the work done?
If your answer is no, what can you do instead? Ideally, use the tools you are meant to be using to manage the artifacts they are meant to manage. For example, a tester shouldnt need to email anyone. The defects he identifies should be automatically visible to the right group of developers, project managers and fellow testers. Everyone should be able to collaborate on that defect in real time–with no need to send an email, or update a spreadsheet. In fact, testers and their developer colleagues should not have to leave the comfort of their tools of choice to manage their work.
Comments, descriptions and status should be available to everyone in the tool theyre using. Admittedly, the company I work for develops integration software. So I come from that world, but even if you build integrations yourself or use tools that are tightly integrated, the value of working in your tool of choice while the lifecycle is automatically managed through notification the correct people and capturing all collaboration in the context of one set of data, is massive. Miscommunication, misunderstanding and general disconnects among teams and disciplines have a huge and negative impact on projects. How many times have you thought a problem was resolved when it wasnt because you were out of the loop? We would find it unacceptable if our e-retailer or bank didnt share information across processes, but we accept that our software delivery lifecycle is disconnected and relies on manual processes like email and spreadsheets. This problem is only made more acute with the adoption of Agile methods, lean thinking and dev-ops–movements that encourage smaller batch sizes, faster feedback and more team collaboration.
I encourage you to do two things:
- Measure the amount of time/work you are spending/doing in email
- Replace that with integration or use of common tools
It is time to use email for what it is intended, sending out happy hour notifications and deciding what pizza to buy at lunch.
