This post explains the importance of proper communications in Software Development, how to master it and how to avoid its disasters.
The software development life cycle goes through several distinct stages; requirements analysis, software design, coding integration, testing, delivery, and maintenance. The most common approach that many companies unconsciously follow is the old waterfall approach. The development phases are conducted sequentially, consuming a lot of time and effort before the software is in a complete runnable state. To cater to the frequent requirement changes, and to get early feedback, software teams started to adopt agile methodologies.
Regardless of the approach used, each company develops its internal and external processes around standard software development methodologies. Whether the company is product or project focused. A product company works on improving its products internally in recurrent iterations, taking into consideration client and sales feedback and market, and technology trends as well as competition. Whereas, a project company doesn’t own a product; instead, it sells skills and technical software development experience that help client automate and customize their businesses.
The software requirements analysis is the first step in SDLC, conducted with the product manager or the client to understand the current issues, problems, new required features. When meeting a customer, the purpose is to get the client’s perspectives and feedback, allow him/her to describe his/her current problem. Maybe, a task is done manually, and he/she is looking for an automation solution. Alternatively, the problem could be due to existing software that might have some minor usability issues or major functional bugs. It is the task of the analyst to set the scoop of the client, set his expectations, and convince him/her with a viable solution.
In large or small teams, knowledge sharing, and communication are essential among members. The lack of proper requirements documentation can cause catastrophic issues and significant losses. According to a report by the Standish Group, an independent IT research firm, 52.7% of projects cost more than 180% of the original budget. In comparison, 42% of the original features were implemented. The study also indicates that 16.1% of all US software projects are developed on schedule, on budget, and with all planned initially features.
The lack of proper documentation
We might think this is impossible in 2020. However, unfortunately, many software teams still do not document their requirements in a clear document that is accessible to other members. Requirements are either shared verbally or via a brief email. Some companies have invested in implementing internal software development processes or even using international standards like the CMMI. Such measures are very strict and require many documentation before the implementation phase started. When poorly implemented, this could add an extra headache that pushes software teams away.
I have encountered many teams that get excited about starting implementing a new requirement immediately after a client meeting. In a team, this is never a good practice, as no one else can understand the customer requirement. What if the client claimed that he never asked for a specific feature? The solution could be simply documenting all the requirements (functional and non-functional), preferably using software use cases or user stories, sharing the document with all participating shareholders for their feedback, then getting the client acceptance. It is crucial that requirements set the scope and expectations for the internal stockholders and the client as well in a very early stage of the project.
Unclear or ambiguous requirements
People express and understand requirements differently when documenting requirements; it should be clear, mutually understood between the client and team in a way that removes any ambiguity. Whether the customer or the analyst is not sure about a particular functionality, this means that some missing information is required.
For example, if the customer confirmed that he already has a database license that can be used for software deployment. Without further details, that promise could cause a problem during deployment if the software is using the Microsoft SQL Server database, and the available license is for the Oracle database.
When finding out such an issue after a few months of software development, the client has either to purchase a new license and probably a dedicated server, or the software should be rewritten to work on the Oracle database.
The same can affect the implementation efforts dramatically if the requirements are not clear to the other team members. Another example will be if the graphic design team is preparing the user-interface for a web application. In contrast, the app itself is designed to work only on desktop or mobile. This is an extra wasted effort that is in numbers translates to losses.
The solution is to use a common tool for team management and adopt the storyboarding technique; I recommend the Microsoft Team Foundation Server for Microsoft technologies. With storyboarding, the analyst or the product manager can describe the required feature in detail. He/she can share actual scratches or mockups using PowerPoint slides of how the application will look like and how this feature will be utilized.
Each requirement can be translated to a task or a set of tasks that can be distributed to the appropriate teams while all have access to the same storyboard details.
To be on the safe side, software teams tend to round up when estimating the effort required to implement a certain requirement or functionality, adding more cost to the project. Based on the experience, they know that some features take more effort than expected due to many factors, including unclear requirements. Underestimation, which on the contrary, when committed cause significant losses to the company, and finally, unrealistic estimations can come from a technology barrier.
I have worked with software teams that have spent all their career developing desktop applications with zero experience in mobile or web applications. When they had to create a simple mobile app, their effort estimations were doubled or tripled, claiming that this requires a big learning curve, and the team may take time to get used to the new tools and development environment. We can accept adding marginal efforts due to the new technology used. At the same time, including the learning period in the estimation is unethical; the project budget is increased due to the lake of skills in the software team. There are several solutions to provide accurate estimates. One option is to hire the right competencies, use actual efforts from previous projects, another is to use expert judgment. The most common is to use team voting estimates primarily when agile is implemented.
As discussed, communication is essential in life and between your team members. The lack of proper communication in a software development environment has harmful consequences, including project delays, financial and intellectual loss.
I recommend reading this excellent book, “Engineering and managing software requirements” by Aurum and Wohlin. They discuss the basics of how to manage software requirements and fix any communication issues that your team might have.
This post explained the importance of proper communications in Software Development, and its best practices. Do you have any recommendations on how to implement clear communication practices? Would you like to share an article or a book about this topic?