1 - SCOPE maintains the Integrity of the Count Repository

SCOPE's unique configuration control capability enables it to manage the individual functional sizing of concurrent Change Request Projects (Enhancement Counts) ensuring other counts are not overwritten when updating the master Application counts (Production Releases).  This feature enables a project manager to 'size' multiple change requests on the work in progress release and track the impact of each individual CR's count on the overall release baseline. The aggregated collection of counts can then be automatically combined to update the Production Baseline Release.  This reflects 'real life' where many different business initiatives make changes to an Application within the same time frame.

SCOPE also allows flexibility with how and when you apply your counts to the baseline E.g.:

•   'Cancelled Projects' - If a change request is already counted on the baseline but the project was not approved then the cancelled Count Session can be deleted in a key stroke.  All impacts from the count session are removed and the integrity of the Release is retained.   All other counts recorded on the same baseline will not be affected, even if they made changes to the same elementary processes or data groups.

•   'Postponed Projects' - If a change request needs to be counted but will not be implemented in the current Release, then it can be counted on the current Release baseline and selectively 'held over' and not incorporated into to the Production baseline when it is updated.  However, it is automatically retained in the baseline count used for counting and kept up to date until a decision is made to re-instate it or get rid of it. This saves having to recount at a later date and the count in the meantime has been maintained such that it will reflect the 'latest' complexity status and the links between processes or data groups in its scope.

•   'Conversion Projects' If a change request is not to be recorded in the Production count. This would occur for changes to the functionality required to be recorded at Project level but not to be implemented into the production version of an application (e.g. conversion functionality). The size of the CR can be retained in the Release project count and automatically 'not applied' to the Production baseline count.  This saves having to selectively 'trim' your count prior to update.

Automatic Synchronization of the Baseline - The 'impacts' from a Change Request can also be imported and exported from a baseline. The need for this would occur when someone had updated the baseline on a copy of the database, but in the meantime the original baseline had been revised.  The counter can then synchronise their 'count' with the latest revised version of the Baseline by selecting to 'import' a count.   SCOPE applies its intelligence to apply the impacts of the count on the revised baseline.  I.e. if a process in the count is deleted it will find the process on the revised baseline count and mark it as deleted.  If the process has been changed then it will be updated and marked as 'changed'.  If a new process is added then SCOPE will find the correct parent in the revised baseline count and insert the process under its correct parent.

If you have multiple counters counting on the same baseline at the same time, they can do their counts on their own version of the database, then export them and import them into a master SCOPEdatabase and SCOPE will manage them so the integrity of the master version is maintained.