Requirements Gathering and Miscommunication
I was recently stumbling around the net and came across a great image on Linux.Kung.Fu that provides a perfect description of how project requirements get communicated.
From the start of many projects it appears as if they are doomed to fail, or at least not deliver the customers expections since requirements gathering and communication is an art wraught with challenges. First we need to assume that the customer has the skills to describe their requirements in appropriate manner. Than the business analyst/project manager needs to properly documents the need in a way that is easily understood subsequent team members and stakeholders. Finally, the communication my be clear enough to sustain future support teams to sustain it to the designed intent.
Given the challenges of communication it is critical that all parties involved with the process understand the needs and how they will be met. As a result all team members have a responsibility to communicate needs in a manner that will be easily understood and translated to community well beyond the execution phases of the project and should attempt to document requirments in a media that is less susceptiable to interpertation. A couple examples that have worked well for me in the past are:
- Customers can provide process flow documents if they exist to allow the team to visualize the process and decision points as early in the process as possible. While this wouldn’t have been a reasonable request a number of years ago I have seen that most “business folks” know have learned how to process map as companies move towards lean practices and value stream mapping has become so common place.
- Project leaders ought to provide calendar oriented timelines with project milestones. It is irrelevant which tool is used to accomplish this (Gantt charts, calendards, Excel, or something else) but the stakeholders have a right to know expected task and milestones to set the expectations of the project.
- User interface designers ought to model user interfaces with a graphical tool, like Visio or even the GUI RAD tools built into the development environment. A simple model place in front of a customer or other stakeholder will inevitably trigger conversation and refinement before development begins and ensure the requirements and expections remain aligned though the process.
- Analysts/Architects ought to use tools like UML and Entity-Relationship Diagrams to ensure programmers understand the interactions of all of the moving parts.
Since the success of a project is tied to the outcomes and clear communication can have a substantial impact on the results all team members must take responsibility for assuring their deliverables are clearly understood by the subsequent users of the documents and the customer.
No related posts.
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
No comments yet.
Leave a comment