Once, the leaders of the company I worked for committed the development team to a project with ambiguous requirements and a timeline that was impossible to meet. The underlying technology to be used was barely out of beta testing and the documentation for the technology was sparse. In the end, the technology was not capable of doing what was expected, but our teams were told we “would do whatever it takes” to make it happen. “Or else” was implied.
I will never forget walking past the office of two of my team members after myself having just finished a 12 hour shift. As I started to say good night to them, I saw them standing in front of the office window staring at the parking lot. Fast forward two months later and they were working for other companies. My company had made similar poor contractual commitments on other projects. The issue wasn’t the team’s inability to perform. It was management’s inability to properly bid on projects and then provide enforcement of the scope of work.
Defining a comprehensive set of requirements for a project is not a simple task, of course. In my experience, projects often fail to the extremes. The gravity of requirements gathering is so seriously attended that the activity becomes a project itself. Several months, even a year later, the opportunity of the project is at risk, and it is very likely that at least one key stakeholder with a head full of organization knowledge has moved on.
On the flip side, we still receive requirements such as “to include all client data with demographics and etc..” In Project Orienteering, I talked about the importance of well written requirements. Too many times, expectations are unmet because no one stopped to define quality adjectives such as modern, or fast, or comprehensive.
I believe that unmet expectations are the source of conflicts, and words that might have different meanings for you and me can lead to a customer saying “that’s not a product configurator!” with the software engineers responding “of course it is!”
I believe that good leaders, whether project managers or sponsors will accept the responsibility for late or unaccepted deliverables that were handed to the implementers with unclear requirements. Software engineers have too many opportunities to work in an environment where they aren’t the scapegoat for someone else’s mistake.