Requirements Best Practices – Content Migration Series

Requirements Best Practices – Content Migration Series

Requirements Best Practices – Content Migration Series

Any large content migration can drag you into almost endless complexity – keeping up with conflicting and rapidly-changing requests and trying to make progress efficiently according to schedule. Here are four best practices to guide your approach to collecting requirements for a large content migration.

  • When are requirements not a moving target?
  • You need a Requirements Repository.
  • Publish requirements sparingly.
  • Overlap the requirements and design, if…

How many projects are not chasing a moving target?

Prepare for a moving target. Of course it’s ideal to have all the business requirements before you start this technical “Content Migration” project. However, it’s enormously common that requirements will emerge throughout the project, either due to unavoidable schedule compression or simply as clients build an understanding of this problem domain.

Expect that requirements will evolve, and approach this project accordingly. Identify subsets of the content, establish the requirements, and move forward on the design of the import process for a subset. Then, your business analyst can return to the stakeholders to set requirements on the next subset, while work proceeds on design, development and testing

You need a Requirements Repository

Digitally track all decisions that affect the requirements/design, in a central place accessible to all project members who need up-to-date access. Capture even the 3 minute hallway chats that result in a verbal agreement on one point or another. Metadata specification for a file import is an extremely detail-intensive process, and you will forget something if you try to keep it only in your head.

Choose your repository from your existing toolset.  There’s no need to buy and configure something new; however, the more suited it is to the task, the easier it can be to track the requirements. Crucial features are the ability to search the full text, and to sort by either the request date and/or people associated with the request. Change notifications and request life-cycles can be extremely valuable.

  • The digital repository can be dedicated software, such as the Clarify Knowledge Base and Case Tracking we use at Cersys.
  • An existing Document Management system could provide a project workspace.
  • SharePoint forms can be set up to record requirement requests and updates.
  • An Exchange public folder will suit for collaboration though it’s lacking in status fields and unique IDs.
  • An email folder has the benefit of zero-transcription required to move emails into the repository.

Publish requirements sparingly

If your requirements are a moving target while you are trying to develop, it is counter-productive to revise every work product frequently.  Collect the changes in the requirements decision repository, and make the changes in batches to the project documents.

Start by updating the requirements document, and ripple the changes from there: through design, test plan, implementation, etc. Synchronize the timing with a meaningful development iteration. Be sure to communicate this contract to the developer, so she does not get needlessly diverted by transient discussions in email/conversation.

Overlapping requirements and design, if …

Along with evolving requirements, there is often time pressure: requests to compress the schedule. This can lead to disaster, but there are some situations where you can judiciously work on requirements and design of the content import in parallel.

If there is a sub-set of content which has clearer requirements, it can be a reasonable risk to start that particular part of import procedure design before the requirements are 100% final… Get the structure established before you hand over those requirements. The critical point is: try to determine when the subsequent changes would be “just data” rather than “structural or logical”. In other words, strive to limit changes to the sort represented in supporting spreadsheets rather than the central logical description of how things are laid out and mapped.

Reading more

This article is part of a series discussing many aspects of content migration from an unstructured storage system to a document management system. The overview page is here: Content Migration to a DMS – Articles.

Related articles elsewhere at Cersys:

2 thoughts on “Requirements Best Practices – Content Migration Series”

Leave a Reply

Your email address will not be published.