The risk of Scope Creep: Let’s focus on requirements

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.

Show More

Leave a Reply


We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.