The Scope manager can be involved in the project as early as the business case stage where they assess the high-level business requirements to provide an estimated functional size of the proposed project. The functional size combined with a productivity rate for the planned development environment can be used to establish a ballpark range of predicted project effort, cost and likely duration.
If the organisation has its own internal productivity data then this can be used for the estimates. Alternatively, industry data for productivity rates are available from the International Software Benchmarking Standards Group (ISBSG) [1]. The ISBSG’s data provides industry productivity data for a wide range of development platforms, languages and environments.
The project estimates can be used as a ‘reality check’ against the planned budget and required delivery dates. If delivery time is constrained, then the Scope Manager can use ISBSG’s regression equations to demonstrate the trade-offs between compressing the schedule and the cost of adding more people on the project. For example, doubling the speed of project delivery requires up to four times the number of people [5]. Large teams have a significant negative impact on an individual’s productivity rate and consequently an overall increased cost of the project to deliver the same product.
If the estimated cost and duration exceeds the planned budget or schedule then the functionality may need to be reduced. Other governance processes need to be in place to ensure that the reduced functionality still delivers the planned business benefits.
Project risk of failure increases exponentially with project size. Early quantification of the size of the proposed software product enables evaluation of potential risk. The Scope Manager provides quantitative input for the business to make objective decisions as to the development strategy to minimise risk, whether to proceed to the next step of building a requirements specification or to cancel the project.
As part of the functional sizing process, the User’s Requirements need to be decomposed into individual functions within a functional model. Each function (process and data group) is identified, catalogued and sized. The cataloguing and modelling process often highlights gaps in the Requirements Specification i.e., where functions have failed to be specified, or have been specified inadequately, inconsistently or ambiguously. The Scope Manager is in a unique independent position to view the project how the external developers may see it. The Scope Manager’s experience with sizing functional specifications enables them to identify areas that may have been overlooked by the project team and provide objective feedback on the quality of the specification. For example, they can mark up the functional model for functionality that has been explicitly specified or only implicitly specified and quantify the percentage of each. The functional size is still only an estimated ‘range’ as the complexity of many functions can often not be evaluated at this stage; it is usually anticipated that the project will grow further. The Users may also prioritise their Requirements as those that they consider to be Core functionality and mandatory to be delivered versus those that they consider to be extended or for future consideration. The Scope Manager can determine the size and estimate of each alternative.
High-level project resource estimates are revised based on the selected platform and the predicted size range. Once the project team have updated the specification to fix ambiguities, inconsistencies and missing functionality, the refined Requirements Specification is ready to be used as the basis for input into the Functional Specification. In an outsourcing situation the Requirements Specification would be provided as part of the Request for Tender (RFT). The functional sizing model along with its list of individual identified quantified functions and their associated priority for delivery is distributed as part of the RFT. This becomes the base Requirements document with which the business can evaluate whether the completed project has delivered their required functionality.
If the method of quotation by the suppliers is to be via a ‘fixed $ price per function point’ as identified within the SouthernSCOPE [5] methodology, then the tendering suppliers need a clear indication of which of the Users Requirements would be considered to be included or excluded from the fixed price.
The Scope Manager identifies which of the User’s Requirements will consume effort (and therefore costs) that are proportional to the overall functional size and which will not, and thus be excluded from the fixed price. For example, documentation of Project Deliverables is proportional to functional size and would be included within the fixed price per function point. In comparison, research and acquisition of hardware is not, and should be quoted separately.
The early ballpark estimates of projected effort, duration and cost based on functional size enable the client to objectively evaluate the ‘reasonableness’ of the supplier’s proposed quotation and solution. This mitigates the risk of selecting the supplier based on the lowest price and promised fastest delivery who would potentially have the greatest risk of failing to deliver the project
The Scope Manager uses the functional size model to quantify the ‘fit’ of each supplier’s proposed solution to the original requirements enabling full objective evaluation of the supplier’s solution by the quantification of the proportion of extra functionality, functionality omitted, functionality delivered by a package or functionality that needs to be customised or built.
The Scope Manager revises the functional size based on the Functional Specification and quantitatively maps the functional requirements to the original RFT Requirement’s Specification to provide a percentage match of the RFT to the proposed solution. Any omissions, ambiguities or inconsistencies in the Functional Specification are highlighted for revision before proceeding with the build. If at this stage the functional size indicates that the project will cost more, or be delivered later than planned, then non-core functionality is selectively removed from the project until the project size indicates that it can be delivered within the allocated budget and delivery dates.\
If the project-charging model is based on dollars per function point delivered, the Scope Manager will work with the client and supplier to finalise the price variation model for changes that are approved during the remaining development. Ie, typically penalties are paid for any function points added, modified or deleted from this stage forwards. The dollar amount charged is usually scaled to increase as the project progresses. The outcome from the functional sizing and mapping exercise is a traceable, auditable, quantified list of agreed functional requirements to act as a base for ongoing scope management.
The Scope Manager is tasked with the quantification of Client Change Requests based on functional size of impact. This is used as a basis for pricing negotiations, enabling the client to assess the price of Change Requests prior to submission to the supplier and know they are being fairly charged for their required changes.
The Scope Manager uses the size of the change to establish the revised project scope as a means of evaluating the supplier’s revised project delivery date.
The Functional Size Model provides input into the quantitative monitoring of project status using an ‘earned’ value type of reporting [2], [3]. I.e., the Scope Manager provides independent project status reports based on the amount of functionality delivered, versus functionality planned to be delivered, within each reporting period. This is an ‘output based’ metric for project reporting that is more meaningful to the business client rather than an input based metrics of budget or effort consumed. I.e., status reporting is based on the amount of product delivered (function points) to each stage of completeness. This contrasts with traditional approaches of monitoring status based on resources and schedule consumed.
The status report provides the client with detailed objective independent assessment about which functions of their software have been developed to what stage. The increased visibility of project status gives early warning of project slippage.
On project completion the Scope Manager quantifies and maps the functionality implemented versus functionality contracted to be delivered, for input into final payment negotiations. This enables the client to verify, against the traceable list of requirements, which functions have been satisfactorily delivered. The quantification of the delivered functionality enables objective discussions on payments due.
The Scope Manager provides advice on the project metrics to collect, analyse and report, and ensures that they are consistent with the organisations internal standards or those of ISBSGs. The Scope Manager can assist with the submission of the project data to the ISBSG repository and provide an independent assessment of the developer's productivity and product quality.
The Scope Manager focuses on the effective management and control of the project and uses their metrics skills to provide objective evidence of their observations, shifting the focus from measurement to project governance.