MSWord97.doc

REFERENCE MANUAL

A project management method to help project sponsors to better manage their software development

projects

Version1 (September 2000)

Government of Victoria, Australia

CONTENTS

1. INTRODUCTION 3

1.1 Intended readers of this document 3

1.2 Additional information on the method 4

1.3 Purpose of the southernSCOPE method 4

1.4 Overview of the southernSCOPE method 5

2. WHEN TO USE THE SOUTHERNSCOPE METHOD 6

2.1 Benefits 6

2.2 Appropriate projects for the method 6

3. ROLES AND RESPONSIBILITIES 9

3.1 Project sponsor 9

3.2 Project managers 9

3.3 Developer 9

3.4 Scope manager 10

4. THE METHOD 11

4.1 Typical contract compared to southernSCOPE method 12

4.2 Project initiation 13

4.3 Software requirements analysis 14

4.4 Change management 14

4.5 Implementation 16

5. GUIDELINES AND GLOSSARY 17

5.1 Project initiation 17

5.2 Software requirements analysis 17

5.3 Change management 17

5.4 Implementation 18

5.5 Glossary of terms 18

APPENDIX A - SAMPLE PROJECT REQUIREMENTS DOCUMENT 20

APPENDIX B - SAMPLE PRESS ADVERTISEMENT 21

APPENDIX C - SAMPLE CONTRACT 22

VICTORIAN GOVERNMENT, AUSTRALIA 2 OF 22 SEPTEMBER 2000

1. IntroductionThe southernSCOPE method is a project management approach designed to give project sponsors (customers of software projects) the ability to better manage their software acquisition projects. This method reduces the risk of budget blowouts and helps ensure good value for money. It results in the customer paying the software developer an agreed price for each ‘unit’ of functionality in the delivered software. The most common technique for measuring units of functionality is function points, which leads to its more common name of the ‘$ per function point’ method.

1.1 INTENDED READERS OF THIS DOCUMENT

This document is primarily for project managers within the customer organisation of a software development project. Project managers have the day-to-day responsibility for ensuring that the project starts effectively, runs smoothly and completes successfully.

This document is also for the project sponsor within the customer organisation. The project sponsor is the person who has the primary requirement for the software application, and whose business objectives depend upon the successful completion of the software application. The project sponsor is typically the person who identified the need, and will provide project funding. This person is ultimately responsible for ensuring that the software is provided to budget, to schedule and meeting the identified need. The project manager within the customer organisation typically reports to the project sponsor.

The document describes how to apply the southernSCOPE method to a software project, and is intended for ready reference during the course of the project. The document assumes a basic understanding of the southernSCOPE method, of software development processes, and of project management techniques.

A secondary audience is project managers within the software developers. These people need to understand the project management method that a sponsor has elected to follow. This understanding allows the software developer to fit the southernSCOPE method into the software development process that the development company would normally use.


1.2 ADDITIONAL INFORMATION ON THE METHOD

There is a range of information available to help people understand the SCUD method and show them its benefits. This information is for project sponsors, project steering committees, and project managers within customer organisations, as well as project managers within software development organisations. Following is a list of the documents available:

An Information Brochure providing a brief overview of the method and its benefits. It is to introduce people to the method, and by describing its benefits, encourage them to find out more.

Two Case Studies telling of the method’s application to software projects. The case studies present the story of real software projects that applied to method.

A Presentation for Project Sponsors. It shows how the southernSCOPE method eliminates the common causes of budget overrun in software projects.

A Computer Based Training Package for project managers and sponsors on the method’s application. This training material is intended to prepare people to use the southernSCOPE method on their projects and to provide them with the background necessary to use the method effectively.

These are available from the Victorian Government Intranet (Livewire / IT & T / IT & T Policy) or from the web site of Multimedia Victoria (www.mmv.vic.gov.au).

1.3 PURPOSE OF THE SOUTHERNSCOPE METHOD

Multimedia Victoria developed the southernSCOPE method to provide project sponsors an alternative, more effective, approach to acquiring their software applications. Traditionally software developers have invoiced project sponsors for custom-built software based on either the inputs expended (by paying an hourly rate for each member of the development team), or fixed-price agreement made in reference to an existing specification document. The southernSCOPE method allows project sponsors to treat software acquisition the same way as many other services, that is pay for the service based on an agreed price per delivered unit.

The southernSCOPE method covers all aspects of the payment to software developers for their services. It will guide project sponsors in starting up and managing a software acquisition project based on $ per function point payment agreement. It integrates effectively with almost all software project management practices. (Refer below to identify in which circumstances the SCUD method is inappropriate.) This ensures that if the customer organisation has a specific methodology for software projects, they can incorporate easily and effectively the southernSCOPE method into the appropriate parts of their methodology.


1.4 OVERVIEW OF THE SOUTHERNSCOPE METHOD

This overview provides sufficient information to help you understand the major differences between this method and traditional project management approaches. The essential steps are as follows:

1. The project sponsor identifies that a need exists to acquire application software and prepares a Project Requirements document to define the project.

2. The project sponsor engages an independent scope manager to perform a preliminary function point count (PFPC), and from this provide early estimates of cost and duration.

3. The project sponsor invites proposals to satisfy the identified need, with the payment for the software based upon dollars per function point delivered.

4. The project sponsor selects the best proposal and engages the successful developer.

5. The development commences with a phase of analysis that produces a System Requirements Specification.

6. The scope manager conducts a function point count on the System Requirements Specification. With adjustments to balance budget with requirements, this determines the baseline functionality for the software, and thus the remaining project budget.

7. During the project, the project sponsor makes payment to the developer on the basis of software, or other measurable products, actually delivered. During this period, the scope manager helps determine the price impact of changes raised after the Requirements Specification.

The key difference between the southernSCOPE method and the older fixed-price approach is the direct linking of the price to the unit of delivery. Though the emphasis of the method is on the development of new software, it can also apply to projects that involve major additions of functionality (enhancements) to existing software.


2. When to use the southernSCOPE methodThis section briefly explains why and when project sponsors should apply the southernSCOPE method to their software projects, and also what sort of projects the method suits. For more detail of the method’s benefits, refer to the documents listed above.

2.1 BENEFITS

A review of how the southernSCOPE method had been used within the Victorian Government, which was conducted in July 2000, identified that projects using the southernSCOPE method are likely to receive the following substantial benefits.1

They are highly likely to finish within a controlled budget, which is a budget determined at the end of the software requirements analysis phase, plus a 10% contingency for changes. This is a major benefit, as average budget overrun for software projects is 89%2.

They are much more likely than typical software projects to meet the project sponsor’s objectives and achieve all important requirements.

Customers receive ‘cost per delivered unit’ rate which will be within the top 20% of current industry best for comparable organisations.

There will likely be less conflict between customer and developer than occurs on typical software projects.

Use of the southernSCOPE method on software projects does not cause any problems additional to those that software projects can normally encounter.

2.2 APPROPRIATE PROJECTS FOR THE METHOD

Software products used by government agencies normally fits into one of three categories:

Personal productivity (software that improves the productivity of individuals in their work e.g. word processors, spreadsheets, e-mail, drawing).

1 Sage Technology, Report on the SCUD Methodology Review, June 2000 (Contact Terry Wright, 03

9651 9006, [email protected])

2 The CHAOS Report, The Standish Group, www.standishgroup.com/visitor/chaosVICTORIAN GOVERNMENT, AUSTRALIA 6 OF 22 SEPTEMBER 2000

http://www.standishgroup.com/visitor/chaos

Information infrastructure (software that supports information management needs fundamental to all organisations e.g. accounting and financial management, human resources and payroll, document management).

Core agency operation (software that supports the core operations of the agency e.g. court case management, hazardous waste transport certificate management, training organisation funding application and disbursement).

The southernSCOPE method most suits the acquisition of software for information infrastructure and core agency operation. It can work with both package customisation and custom development approaches to the provision of software.

Software projects themselves typically fall into one of five categories:

Development of a new software product for business needs that did not previously exist, or were not previously met with software. eg. the creation of software to support electricity trading when the Victorian government created a wholesale electricity market.

Redevelopment of an existing software product using new technology, and probably also to meet new business needs. eg. the creation of a web-based product ordering system to replace a mainframe-based ordering system.

Purchase of a software package and subsequent development work to customise it to the specific business needs of the customer. eg. purchase of an enterprise resource planning package such as PeopleSoft, SAP or Baan.

Enhancement of an existing system to meet new and additional business needs through additional functionality. eg. enhancement of a payroll system to track superannuation payments.

Adaption of existing functionality to fit it to a changing business environment, without adding significant new functionality. eg. changing a product ordering system to handle the introduction of GST.

The southernSCOPE method works well for the first four of the five categories of software project listed.

Taking an alternative perspective, the southernSCOPE method works well on software projects with the following characteristics:

There exists a well-accepted technique for measuring the functionality of the delivered software. At present IFPUG function points have the highest level of acceptance across the Australian software industry; however, IFPUG function points do not measure with acceptable accuracy the functionality of all types of software.

The project is able to limit the number of changes to functionality occurring between completion of the requirements specification and delivery of fully functional software. Note


that all software project management methodologies have difficulty keeping within fixed budgets when there are high numbers of changes during software construction.

Completing the project within a controlled budget is of primary importance.

The requirements of the project can be documented with sufficient precision for functional size measurement.

All information infrastructure support software has these characteristics, and most software for core agency operations also has them.


3. Roles and responsibilitiesPersonnel fulfilling several roles perform the southernSCOPE method.

3.1 PROJECT SPONSOR

The project sponsor is the software project’s key person within the customer organisation. The project sponsor identifies the need for the software, and drives the initiation of the software project. The sponsor must ensure that appropriate personnel are available to decide, communicate and approve the functionality required. The sponsor also needs to decide other requirements such as project constraints and budget. During the course of the project, the project sponsor must be available for discussion and resolution of any changes raised on the requirements.

3.2 PROJECT MANAGERS

For a government software development project, there are typically two project managers: one within the customer organisation reporting to the project sponsor, and one within the developer organisation. Project managers have the day-to-day responsibility for ensuring that the project starts effectively, runs smoothly and completes successfully. Customer project managers and project sponsors typically use the southernSCOPE method.

Project managers within the development company need to understand the project management method that the project sponsor has elected to follow. This understanding allows the software developer to fit the southernSCOPE method into the software development process that the development company would normally use.

3.3 DEVELOPER

The development organisation is responsible for producing the System Requirements Specification and providing the software solution that meets this specification. They must have agreed to do so based on a price per unit of functionality delivered. The software solution delivered may comprise pre-existing software, software developed specifically for the project, or a mixture.


3.4 SCOPE MANAGER

This is an independent person with expertise in functional size measurement (function point analysis) who also has experience in software project management. The scope manager conducts the preliminary function point count (PFPC) performed during project initiation, and then the baseline function point count (BFPC) of the requirements specification that sets the precise project budget. Throughout the project, the scope manager monitors any significant changes raised, evaluating their impact against the BFPC and advising each party of the implications of the changes.

The success of a southernSCOPE project for both parties depends upon the independence of the scope manager. Though the project sponsor typically pays the scope manager’s fees, it is important that the scope manager act independently to protect the interests of both project sponsor and developer.


4. The methodThis section describes the performance of the southernSCOPE method in the context of a typical process for software development. You may need to translate these terms into those you use more commonly.

Project initiation (objectives, stakeholders, risks, budgets and schedules).

Software requirements analysis (what functionality, what interfaces, what quality).

Architecture design (general, high-level design of the software structure).

Construction (detailed design, programming and unit testing).

QA/System testing (integration, system testing).

Implementation (installation, user documentation and training).

The southernSCOPE method has the most impact in the initiation and requirements analysis phases but also impacts the change management that occurs within the phases that follow. Note though, that the southernSCOPE method is not dependent upon a particular software process. For additional detail on application of the method, refer to the self-paced training course material.


4.1 TYPICAL CONTRACT COMPARED TO SOUTHERNSCOPE METHOD

The following diagram provides an overview of how a typical software project contract compares to the use of the southernSCOPE method.

This diagram shows the typical software contract and the southernSCOPE method applied to a simple ‘waterfall’ software process. It can also apply equally well to other processes, such as incremental releases.


4.2 PROJECT INITIATION

Application of the southernSCOPE method begins with preparation of a Project Requirements3 document. (Refer to Appendix A for an example Project Requirements document.) This document defines project deliverables and constraints. It covers project management, change control4, acceptance criteria and payment arrangements. It must also include specification of requirements that will impact on the $ per function point price. These include:

statement of the primary objectives of the software.

identification and description of the customer stakeholders involved in the software.

technical environment for the software (operating system, development tools if necessary).

a preliminary description of the functional requirements (necessary to measure the approximate functional size).

approximate functional size (normally in function points).

preferred project schedule.

Measuring the approximate functional size requires the project sponsor to select and engage a scope manager for the project.5 Victoria is well served by organisations capable of providing scope managers. In measuring the approximate functional size, the Preliminary Function Point Count (PFPC), the scope manager may elicit and prepare the preliminary description of functional requirements. From the approximate functional size, the scope manager can calculate the first estimates for development cost and duration. This work by the scope manager typically requires less than 1% of final project budget.

The project sponsor then prepares a Request for Proposal (RFP) document, which invites software developers to present a proposal to deliver the required software on the basis of a price per delivered unit of functionality. The customer may then distribute the RFP to selected suppliers, or advertise the project in the press. (Refer to Appendix B for an example press advertisement.)

Upon receipt of the proposals from developers, the project sponsor follows an appropriate procedure to select the most suitable developer. The scope manager should have previously

3 Often also called a Project Brief document.

4 Change control procedures need to include description of how the $ per function point price would be

applied to changes raised. Refer to a later section.

5 Contact Terry Wright of Multimedia Victoria (03 9651 9006; [email protected]) or the

Australian Software Metrics Association (03 9844 0560; [email protected]) for possible

organisations to provide scope managers.VICTORIAN GOVERNMENT, AUSTRALIA 13 OF 22 SEPTEMBER 2000

provided an expected range for the proposed $ per function point prices, as this helps identify foolishly low and unreasonably high prices.

After selection of the developer, the project sponsor engages the developer under an appropriate contract. (Refer to Appendix C for a sample contract tailored for the southernSCOPE approach.)

4.3 SOFTWARE REQUIREMENTS ANALYSIS

During this phase, the developer works with the customer to identify and document the software requirements. They must define the requirements in sufficient detail to allow a precise function point count. From the produced System Requirements Specification, the scope manager makes the first cut at the Baseline Function Point Count (BFPC).

At the completion of the software requirements analysis, the project sponsor and developer agree on the precise functionality in the project scope. The scope manager then refines the BFPC to document the agreed scope of the project. The BFPC becomes the baseline against which changes are identified. The contracted $ per function point price allows the setting of a baseline project budget. This in turn allows estimation of the baseline project schedule using appropriate procedures6 or tools.

The project sponsor will make a payment upon acceptance of the System Requirements Specification. This is normally between 20 and 25%7 of the $ per function point price, per function point in the Baseline Function Point Count.

4.4 CHANGE MANAGEMENT

In the architecture design, construction and testing phases of the software project, the southernSCOPE method only has a role in change management.

Because the developer will have the deepest understanding of the System Requirements Specification, the developer is primarily responsible for effective change management.

6 Refer to The Benchmark, Release 6, International Software Benchmarking Standards Group (ISBSG),

2000, or Rapid Development, Steve McConnell, Microsoft Press, 1996, as two sources of information to

estimate schedule from effort/budget. There are other sources.

7 This percentage depends upon the approach used for requirements analysis, and should be specified in

the contract. VICTORIAN GOVERNMENT, AUSTRALIA 14 OF 22 SEPTEMBER 2000

Here it is necessary to have a procedure to calculate and negotiate the price for a change. The scope manager applies the procedure to any change(s) for which the customer or developer requires pricing. The procedure involves the following steps:

1. The scope manager determines the functional size of the change (normally in function points), and whether the change is adding function points, changing already specified function points or deleting function points.

2. In consultation with the developer and customer, the scope manager considers the impact of the change and defines a possible impact % applied to the $ per function point price for the change. Table 1 below defines possible %8 of the $ per function point price applied to each classification of change.

8 These ranges would be defined for each project in its contract. VICTORIAN GOVERNMENT, AUSTRALIA 15 OF 22 SEPTEMBER 2000

Change FPs Classification % of $ per FP price to apply

Added 80 - 120

Changed 40 - 150

Deleted 20 - 50

Table 1: Price impact percentages for changes

3. The scope manager applies the decided impact % to the $ per function point price, which provides a price for the change from which to start negotiation.

4. The customer and developer agree a price for the change, which the scope manager documents.

The customer and developer may instead decide to negotiate the price of changes independently of the scope manager (and of functional size measurement). The scope manager only then becomes involved when there is a dispute.

It is in the management of changes that the independence of the scope manager becomes particularly important.

4.5 IMPLEMENTATION

At agreed points in the project, normally linked to the delivery of software releases or other measurable deliverables, the project sponsor makes payments to the developer using pre-agreed percentages of the $ per function point price. Included in these payments would be adjustments for any agreed changes.

At the completion of the project, the final price should be the agreed $ per function point price multiplied by the BFPC, plus the prices of any agreed changes.

The developer (in accordance with the Contract) will enter details of the completed project into the ISBSG Repository (www.isbsg.org.au), and on receipt of the Project Benchmark Report from ISBSG, will send a copy to the project sponsor. This will provide an ongoing history of the application of southernSCOPE method. It will also provide the software development community an ongoing and accessible source of project history to make future project management and software development innovations possible.


5. Guidelines and glossaryThis section contains additional guidelines on the use of the southernSCOPE method that may assist its application. It also contains a glossary of terms.

5.1 PROJECT INITIATION

Proposing developers should receive the full detail of the preliminary function point count (PFPC), as it may provide them some indication of possible complexities within the software, and it will help them with their price calculations.

The scope manager may also be able to provide assistance in the evaluation of the technical or project management capabilities of the developers submitting proposals.

5.2 SOFTWARE REQUIREMENTS ANALYSIS

When gathering software requirements, the developer must remain aware of the initial function point size for the project, as it is easy to gather and document requirements significantly in excess of this size. Such growth in functionality may be appropriate, but the developer must consult the customer early to avoid documenting unnecessary requirements.

If there has been a major change in the functional size (> 40%) between agreeing the contract and the BFPC, then the $ per function point price requires review This is because software products typically comprise cheap-to-construct function points and expensive-to-construct function points. A large increase in the functional size may make a significant change to this ratio, resulting in the need for a review of the $ per function point price.

5.3 CHANGE MANAGEMENT

When deciding the % price impact of a change, the scope manager needs to consider:

1. the level of documentation of the change relative to the System Requirements Specification;

2. the actual scope of the change relative to function point measurement of the change;

3. the technical impact of the change on existing functionality and;

4. the point in the project’s lifecycle at which the change is raised.


When evaluating changes, scope managers and developers must remain aware of the constraints of functionality ratio, technology and productivity factors on the application of the $ per function point price to the changes.

5.4 IMPLEMENTATION

On a project of more than about 300 function points, it is advisable for the developer to deliver a series of releases to the customer for acceptance testing, with a release delivered every 1 - 3 months. Each release would be 50 to 150 function points in scope. The regular delivery of incremental software releases is the most accurate method of monitoring project progress, and is accepted software engineering best practice.9

5.5 GLOSSARY OF TERMS

Baseline Function Point Count (BFPC)

Function point count of the functionality in the System Requirements Specification, and that the project sponsor has defined as within the scope of the software project.

Customer

The organisation to which the project sponsor belongs, and whose personnel will use the software. This is the organisation that is commissioning the software development.

Developer

The development organisation is responsible for producing the System Requirements Specification and providing the software solution that meets this specification.

IT Manager

The IT manager, or other IT representative, within the sponsor's organisation typically supports the sponsor.

Preliminary Function Point Count (PFPC)

9 Refer to Principles of Software Engineering Management, Tom Gilb, Addison-Wesley; Software

Project Survival Guide, Steve McConnell, Microsoft Press; Dynamics of Software Development, Jim

McCarthy, Microsoft Press for fuller descriptions of incremental releases.VICTORIAN GOVERNMENT, AUSTRALIA 18 OF 22 SEPTEMBER 2000

Function point count of a preliminary, typically high-level, statement of functionality documented in the project initiation phase of the project. This helps develop early estimates of size, cost and project duration.

Project Requirements Document

This document defines project deliverables and constraints. It covers project management, change control, acceptance criteria and payment arrangements. It also includes specification of requirements that will impact on the $ per function point price.

Scope Manager

An independent person who conducts the preliminary function point count performed during project initiation, and then the baseline function point count of the requirements specification that sets the precise project budget.

System Requirements Specification (SRS)

A document the precisely defines the requirements for the software product that the developer must deliver. It typically covers four main areas: system constraints, functional requirements, non-functional requirements, and project issues.

Sponsor

The project sponsor identifies the need for the software, and drives the performance of the software project.


Appendix A - Sample Project Requirements document


Appendix B - Sample press advertisement


Appendix C - Sample contract


MSWord97.doc

Business

project management method

project managers

project initiation175

project sponsor93

project initiation134

project funding

invoiced project sponsors

project management approach