Often “obvious”, “implied”, “assumed” or even “the first work package” in relation to a delivery project, requirements are deserving of closer attention than we might think. “Scope creep” – where requirements are modified after contracts have been signed (or an internal project budget allocated) – is the bane of many a project manager’s or solution architect’s life. Requirements don’t need to specify HOW an objective is to be achieved. A detailed design phase in a waterfall project or inputs to an agile iteration can take care of that, but there needs to be a clear understanding that HOW an objective is achieved (e.g. technology choices, user interface, architecture) is different to, and distinct from, WHAT is to be achieved. Requirements management deserves to be attended to up front, and as a short lead-in to the main project which delivers upon those requirements. Everything else is a dependency
- The definition of “working software” for your Agile development teams
- Specifications for test outcomes
- Demonstrable steps leading to completion, so that progress may be tracked and budgets managed
With deadlines looming the temptation is to dive in to the “how”, “when” and “where” of a delivery project. A wise investment up front in making sure the “what” and “why” are clearly defined will pay dividends in the long run.