Scopes are frequently written by the vendor to limit the time, deliverables, scenarios, and settings to be configured and covered for a given cost. Because of this, they frequently do NOT cover the common reasons that scopes expand, nor incentivize alignment on project goals.Â
The deliverables within the scope of work should absolutely include any processes necessary for your team to complete prior to project close. For example, if your team needs to know how to create back-ups, then the successful restoring and accessing of said backups should be a planned deliverable within your scope. If your software provider suggests that end-users being able to login to restored databases is not a "deliverable", then request process documentation for the entire restore process, from saving a copy of the database, all the way through an end user logging into the database after the restore is loaded.
If there is information you want to be sure is written down in a single, concise format, be sure that that documentation is considered a deliverable within the scope. If you want there to be a screenshot for every step within the documentation, specify THAT in the SOW deliverables.
If you'd like an additional set of eyes to review a scope of work and/or attend calls regarding the scope of work, Request a Call below and we'll see if we're a good fit for each other.