ITMPI FLAT 001
Main Menu
Home / Uncategorized / The risk of Scope Creep: Let’s focus on requirements

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.

About Gavin Martin

Information systems architect / technical design authority with over 20 years experience delivering small-scale through enterprise systems to commercial, finance and government customers.

Check Also

The Seven Activities of Project Closeout

People go crazy when a TV show like Firefly or Agent Carter gets canceled, because …

Leave a Reply

Your email address will not be published. Required fields are marked *