- App Projects Are Not Small and Easy
- Apps Are Not Easy to Program
- Poor Skill Set Fit
- If You Get a Good Developer, You Still Have to Worry
- The Idea Is Not More Important Than the Execution
- Unwillingness to Delegate: Micromanaging
- Bikeshedding
- Poorly Defined Requirements
- Out-of-Date Requirements Documentation
- Constantly Changing Requirements
- Leaving the Worst for Last
- Cost Overruns
- That Last 10%
- The Whack-a-Mole Problem
- Poor Communication
- Abdication of the Management Process
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
Out-of-Date Requirements Documentation
Yet another way projects go wrong is when the requirements documentation exists but is not kept up to date as things change. This often happens in projects that involve multiple organizations and many simultaneous conversations. Decisions get made, and the two people on the phone know what was discussed, but nothing gets written down, and the rest of the folks on the project are left in the dark. Alternatively, sometimes the requirements document does get updated, but the change doesn’t get announced, and other parties execute the instructions from an old copy of the document.
Requirements documents often start out as multipage documents that are basically tables of contents. Someone (usually a single person) starts the project with every intention of documenting all the requirements and begins by writing a three-page list of stuff that needs to be documented. Then as the project goes on, less and less gets written on the requirements document each day, until finally it ends up a derelict Word file on some shared drive somewhere and serves only to confuse the unwary.
Another common setup is that someone sets up a project wiki server with the expectation that people will use it to document the project, but the wiki never ends up being integrated into the project’s workflow. The content on it grows stale over time, and the wiki ends up being worse than useless because no one knows whether it can be trusted.
The way to solve this problem is to force the documentation to be part of the workflow for the project—either documentation that the quality assurance (QA) team uses to do testing (so the team opens bug reports when the documentation doesn’t match the reality) or in the form of a suite of automated acceptance tests that are run on a frequent (or at least periodic) basis. The automated acceptance test idea works especially well for documenting the requirements between the server development team and the mobile development team.
Without some way to bring to light discrepancies between the documented requirements and reality, documentation usually becomes out of date to some degree during a project, and this can cause headaches for everyone involved.