Increase ICT project success with concrete scope management

With the Standish group's CHAOS report (Standish, 1995) proclaiming ICT project success on a mere one-third of projects, project managers have an obligation worldwide to gain control of the situation. Through concrete scope management processes, ICT project managers can learn and embrace proven approaches that measure the size of software projects, streamline the requirements articulation and management, and impose solid change management controls, to keep projects on time and on budget. Scope management is not rocket science, however, with 2/3 of the world’s ICT projects deemed as failures, it is apparent that managing scope is not a natural byproduct of project management. Learn approaches and tips used in Europe, Australia, and North America that have dramatically increased the success on ICT projects by trained scope managers.

Introduction to project management issues unique to ICT projects

Every month newspapers announce in every country where Information and Communications Technology (ICT) projects are developed, failures of astronomical proportions. Failures, late deliveries and cost overruns plague our industry and project managers worldwide struggle to stay afloat and manage their projects using the latest tools and techniques intended to create project success. Questions of how to improve the state of affairs in an industry of advanced technology, bright project managers, leading edge maturity models led two particular countries, Australia and Finland, to investigate further – with results worth paying attention to.

Quoting the first president of the not-for-profit International Software Benchmarking Standards Group (ISBSG) Terry Wright in 2000: “In an industry worth an estimated $200bn (US) per year (with Australian share at $4.6bn), why should this be the case? There are probably two primary reasons. Firstly, the software industry is relatively young and is still in the evolutionary stage. Unlike most other engineering disciplines we have not had access to ancient and excellent tools which allow us to predict, plan and measure progress and productivity.” Wright goes on to say “Secondly, until relatively recently we have had no reliable and broadly accepted technique for measuring the output of a software engineering project. In the building industry they talk squares of floor space and in road construction kilometers of highway – but we have had nothing.” (Wright, 2000, p. 1 ) This led Wright and the Victorian Government to establish Southern SCOPE, an initiative whereby ICT projects are initialized, scoped, split into manageable sub-projects (as necessary), quantified, costed (on the basis of currency per unit size), managed, and delivered using a new concept that directly addresses “Scope Management”. The results of the Australian Southern SCOPE and the subsequent Northern SCOPE initiative by the Finnish Software Measurement Association (FiSMA) are profound: their success rates on ICT projects have skyrocketed, and their cost overruns plummeted to levels unprecedented in the ICT industry. This paper outlines the core concepts of both the Southern and Northern SCOPE initiatives and presents solid recommendations for Project Managers of ICT projects to dramatically increase both the customer satisfaction and the success of their project delivery.

Exhibit 1 – Cost overruns for projects in SouthernSCOPE (ISBSG, 2005)

What is an ICT project?

An information and communications technology (ICT) project typically results in the development and installation of a new software product, but not every project is a pure development project. Many projects are “hybrids”; that is, they are composed of multiple, independent sub-projects that must be managed separately. In building construction, it is easy to identify the different types of projects by their differing types of work, but this is not the case with ICT projects. For example, in building construction, one would not consider a project where there is construction of a new home, renovation to a second home, and subsequent replacement of its landscaping, all to be a single project because the construction tasks for each of the three sub-projects are completely different. So too is the difference between new development, enhancement, conversion and other sub-project types in ICT. It follows then that each type also requires different project management.

In traditional project management of ICT projects, the project manager is tasked to plan, scope, estimate, schedule, resource, and control projects that include such hybrid requirements, and do so typically as a single set of work tasks. It is no wonder then that the scope is difficult to manage and estimates and schedules quickly start to slip, unnoticed until it is too late. In fact, in a study of over 500 completed contracts it was observed that when a project is 15-20% complete (Christensen, 1993):

• The absolute overrun at completion will not be less than the overrun to date.
• The % overrun at completion will be greater than the % overrun to date.

Scope management as outlined throughout this article is critical to successful ICT project completion. In the often quoted words of Tom DeMarco: You can’t manage what you can’t measure (DeMarco, 1995), and attempting to manage projects in the traditional way as a single, monolithic piece of work is one of the reasons for project overruns and overall mismanagement. ICT projects are almost always hybrids of differing types of work and it is imperative to identify and divide an ICT project into its component parts if one is to properly manage the necessary work. This paper uses the Southern and Northern SCOPE concepts to identify, divide, and conquer an ICT project through solid scope management. As such, a new role, that of a Project Scope Manager is introduced to assist the project team and the customers to scope, quantify, manage and control distinct subprojects within an ICT. In subsequent sections, the role of the Scope Manager, together with concrete rules for the tasks and proven management techniques is presented.

What makes ICT projects unique?

While ICT projects are often compared to building or construction projects, there are some marked departures between these and ICT projects. These include but are not limited to:

• In construction, it is typical to cost out projects based on a currency (US $ for example) per unit of building size (squares, square meters or square feet, for example). In ICT development projects, there is virtually no history of unit costing models.
• In construction it is standard to divide up the work done on separate buildings into separate projects, this is not so for ICT projects.
• It is easy to see why home renovation (altering the floor plan), replacement of insulation, and building a fence around the yard are separate and distinct pieces of work requiring separate costing models, however, it is not so simple for ICT projects.
• Construction, typically, does not involve unproven materials or proof-of-concept tasks as part of a project. ICT projects often introduce new hardware, software and/or new product development as part of the project. These introduce a level of project risk not usually encountered on routine building projects.
• The ICT and software development industry has become process focused through the use of maturity models such as CMMI® (Capability Maturity Model Integration registered to the Software Engineering Institute of Carnegie Mellon University, SPICE (Software Process Improvement Capability dEtermination by ISO/IEC), and others. These process models allow organizations and project teams to identify and improve their processes and products through continuous process improvement. The building industry has no such standardized models.
• The building industry uses standard metrics for both homeowners and construction crews including cost per unit size, contingency percentages, unit area (square feet or meters), elevation (feet or meters), etc. For ICT projects, there is a requirement for different metrics for developers and customers based on their differing viewpoints. As such there are differing success criteria for Quality, Size & Cost for each viewpoint.
• Compared to construction, there is a distinct absence of enforceable controls on ICT projects. While a construction project cannot proceed without sealed engineering blueprints and a building permit, ICT projects routinely commence with little more than requirements scribbled on a napkin.
• The frequency of updates to and non-functional enhancement of ICT software exceeds anything required in construction. For example, it is common knowledge that the original cost of software development is only a fraction of the overall life cycle costs including maintenance, enhancement, and technical upgrades (e.g., MS windows, Unix, migration, conversion, etc). In construction, the original building cost is often the most expensive part of the overall cost of the building throughout its lifetime.

Project managers can work as diligently as possible and utilize all of the Project Management Institute’s tools and techniques to optimize their project success, but often it is not enough for ICT projects that invariably are “hybrids” involving multiple types of work within them. The following section outlines how to subdivide projects into their component and independent parts or subprojects and how the introduction of a new project role – that of an independent scope manager – can maximize ICT project success.

Why is Scope Management important?

Introduced in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) as a knowledge area, scope management can be more important to project success than any of the other individual knowledge areas. As a case in point, as much as 60 - 99% of all defects latent in production software can be attributed to the requirements phase. (Insight, 2002) While project scope management will not guarantee perfect requirements, the simple act of identifying scope delineates what is within the requirements and what is not.

The ICT industry is younger than many other established industries such as construction, and everywhere it is a fast-growing industry. As with any other industry experiencing explosive growth, this leads to a higher than normal incidence of inexperienced project managers. Combined with the lack of enforceable regulations or standards before which one can commence a project, the lack of control in ICT projects complicates their project management.

The Northern SCOPE initiative by the Finnish Software Measurement Association (FiSMA) places scope management dead center in the overall PMBOK^® Guide knowledge areas because it involves and interfaces with all of the other eight areas as depicted in Exhibit 2.

Exhibit 2 - Coverage of FiSMA Scope Management Concept (Forselius, 2003)

Exhibit 2 shows that scope management is one of the nine project management knowledge areas. The definition of project scope management is: It describes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. (PMI, 2004) “Scope management is put in the middle of Exhibit 2, though the PMBOK^® Guide introduces knowledge areas in different order originally. The order is not important in PMBOK^® Guide, but here we want to emphasize the central role of scope management in software development. The FiSMA Scope Management Concept, as scope management in general, has strong relations to several other knowledge areas. Scope management must be integrated especially with time, cost, quality and risk management. There are no scope changes without possible consequences to schedule, budget and quality or risk level of the project. This is true vice versa as well. If the schedule or budget must be tightened, it may require changing the scope or quality requirements, or increase the project risks.” (Forselius, 2003, p 3)

Similar to the PMBOK^® Guide, FiSMA defines five different project scope management processes. The core process of a software development project is “Developing the software”. It is not a management process, but an essential object process to be managed. The five different scope management processes of FiSMA concept are “Initiating project and software”, “Estimating effort and duration”, “Managing changes”, “Controlling progress” and finally “Closing development”. Exhibit 3 shows the processes from left to right in performance order (Forselius, 2003) and Exhibit 4 shows the mapping to PMBOK^® Guide process groups.

Exhibit 3 - FiSMA scope management processes at project level. (Forselius, 2003)

Exhibit 4 - Mapping of FiSMA Scope Management Processes (squares) against PMBOK^® Guide Process Groups (ovals)

Scope management has been proven to effectively address five out of six of the most common reasons cited for cost overruns and uncontrolled project growth: (Wright, 2000)

• lack of user input,
• incomplete requirements,
• changing requirements,
• technology incompetence, and
• unrealistic expectations.

Scope management is best carried out by an independent scope manager who is trained in project management, customer relations (communication), software estimating, requirements articulation and documentation, functional size measurement, software measurement, change management and how to divide projects (as necessary) into independent sub-projects. A scope manager is both a customer advocate as well as an able assistant to the project manager whose role is similar to a construction surveyor before and during a construction project.

Scope manager role and responsibilities

The Southern SCOPE initiative reported that some of the most effective scope managers are software measurement practitioners whose expertise includes software development and subject matter expertise. “Metrics experts observe and measure without any vested interest and as such provide unbiased and independent assessment of the project risk, quality and status. The measurement results support these observations.” (Morris, 2004, p.589) Additionally from Australia, “The Scope Manager provides metrics based project governance. We have found this approach to be very successful in objectively quantifying key project attributes to enable informed decision making with respect to project estimates and project risk…The Scope Manager is typically a metrics specialist who has excellent skills in business analysis, project estimation and functional size measurement. They need to be independent of the project team and not be connected to either the IT developers or the business client. They have to be able to report the status of the project objectively without bias, to a management level that has the authority to proceed, change direction or cancel the project.” (Morris, 2004, p.589)

As a pre-requisite before beginning the project (even before starting the project initiation phase), it is important that the scope manager, together with the project team, examine the project requirements and divide the ICT project into one or more independent, component sub-projects.

Types of ICT projects
Forselius and FiSMA identified seven distinct ICT project types as listed in Exhibit 5. The definitions of each project type follow the table. Exhibit 5 also identifies a four character technical abbreviation which is only used to facilitate statistics collection and tool data entry. Due to the proliferation of abbreviations in ICT industry, we recommend the use of the full ICT Project Type classification for identification and project management (FIPA, 2005).

Exhibit 5 - ICT Project Types and Abbreviations

• Customer specific new development project
  Is a project to create completely new customer specific software.
• Software product new development project
  Is a project to create a new software product. A software product is always developed to be used by more than one customer. A software product may be either standalone packaged software or embedded part of any other product.
• Software version enhancement project
  Is a project to create a new version of existing software. The existing software may be either customer specific software or a software product.
• ICT service development project
  Is a project to create a contract-based continuous or temporary ICT service. The service may be, for example, either software or hardware related, and consists of maintenance, support, help desk, or operating service.
• Package software configuration project
  Is a project where the result is an installed, parameterized and, user configured software package.
• Data conversion project
  Is a project where data is moved from persistent data storage of one information system to persistent data storage of another information system. The software developed in a data conversion project is often “throw away” in that it is only used once. Even so, the pieces of conversion software may reside on one or more hardware platforms.
• Software integration development project
  Is a project to create software that provides interfaces services between two or more information systems.

Note that the software development life cycle phases such as requirements specification, software implementation and system test, etc. are not considered to be independent ICT project types, but rather as phases within each sub-project itself.

When and how to divide an ICT project

It is important to divide an ICT project into multiple sub-projects as early as possible, preferably by the initiation phase. The following rules give guidance how to do this: (FIPA, 2005)

1. If the program consists of ICT development and other development work, such as manual process development, re-organizing staff, or technical development, different type of work should be assigned to separate projects.
2. If you apply incremental or iterative development approach, every increment or iteration should be assigned to separate projects.
3. Different type of ICT development work should be assigned to separate projects.
4. If the program must be stopped consciously for long time, for example to wait external decisions, the work before and after the break should be assigned to separate projects.
5. If two parts of product or service development are of a similar ICT project type, but differ from each other by development technology, they should be assigned to separate projects.
6. If two parts of product or service development are of a similar ICT project type, but differ from each other by development environment, they should be assigned to separate projects.
7. If two parts of product or service development are of a similar ICT project type, but differ from each other by development team experience, they should be assigned to separate projects.
8. If two parts of product or service development are of a similar ICT project type, but differ from each other by quality requirements of target result, they should be assigned to separate projects.
9. If two parts of product or service development are of a similar ICT project type, but differ from each other by stakeholder dependencies, they should be assigned to separate projects.
10. If two parts of product or service development are of a similar ICT project type, but differ from each other by risk level, they should be assigned to separate projects.

As we see from the number of rules above and the number of different possible combinations, this approach leads to a larger number of smaller projects. As such, this approach has a number of pros and cons. One of the biggest pros is improved manageability, which is so important to program and project success that neither the customer nor the supplier should resist it. This approach has been a successful component of on-time and on-cost delivery in the Northern and Southern SCOPE initiatives.

Exhibit 6: Scope Management Process components (Forselius, 2002)

There are several concepts introduced in the Scope Management processes that are not traditionally included in ICT projects as depicted in Exhibit 6. These include:

• Analysis and classification of requirements into independently managed projects (or subprojects)
• Functional Size Measurement of the Software Requirements document and Project Scope
• Baselining the Project Metrics
• Estimating the Project effort, duration, cost based on historical Project Actuals
• Feedback loop to estimate, then incorporate and track accepted changes into the existing project documents

In addition, the introduction of an independent Scope Manager to facilitate and perform many of the Scope Management Process tasks alleviates the already heavily committed project team members. The Scope Manager serves as an independent customer advocate and project team surveyor responsible to monitor and gauge the progress of the project scope development. Through the careful attention to project scooping and its management throughout the project, customers and suppliers alike can better specify, build, and acquire quality software products. Practitioners involved in Southern SCOPE report substantially lowered costs per software functional size since the introduction of Scope Management processes (Exhibit 7).

Exhibit 7 - Cost of SouthernSCOPE projects compared to traditional IT projects (ISBSG, 2005)

How to apply solid Scope Management for success on ICT projects

The five processes involved in the FiSMA Scope Management concept ( Exhibit 3) are integrated concepts, however, all steps are not mandatory on every ICT project. The initiation and estimation steps are pre-requisites for the other three components, and these subsequent steps are independent of each other. FiSMA recommends that organizations at least examine the last three steps for their applicability, but understands exceptions and lighter application needs exist. (Forselius, 2003) Organizations that will gain the most benefit from scope management are those representing business areas like banking, insurance and public administration because they are routinely involved in software acquisition and procurement. In these organizations, a core business is information management, and the business development centers on developing information systems and software. As such, project level scope management processes have proven to be insufficient for ongoing project governance.

In addition to software acquirers, the professional software suppliers are in need of organizational level processes to support continuous process improvement and organisational learning. All supplier organizations could benefit from applying scope management processes at both the project level and at an organizational level. Can every company gain from implementing the full Scope Management process set? Our experience bears out that there are some small and medium size suppliers whose process maturity is ad-hoc or in the initial standardization stage, and would be better served by concentrating first on developing or improving their core processes such as time recording and invoicing before attempting full-scale Scope Management. Nonetheless, the division of projects into software projects that will be independently worked can assist even the most disorganized or immature organizations to better manage their ICT projects.

Are there critical success factors for Scope Management?

Through our international collaboration and consulting, the authors have found that Scope Management (and for that matter, software process improvement) just doesn’t always succeed even with the best of intentions. Reasons for failure or partial adoption of sound ideas such as Scope Management can run the gamut between lack of support or understanding to internal sabotage by organizations weary from “whiplash” changes imposed by management.

The acronym P.O.W.E.R. illustrates the five essential ingredients for successful implementation of new initiatives: (Dekkers, 2000)

• Predisposition: encapsulates the desire, motivation, ambition, and commitment to take action on improvement opportunities. Without a solid predisposition for change, companies tend to abandon process improvement if short-term gains are not realized quickly enough, or when budget constraints threaten the improvement initiative.
• Outlook: people ultimately determine the success or the failure of new initiatives and it is of vital importance that there is an Outlook for success present. Everyone has experienced projects where this outlook was absent and where the prevailing mood was that the initiative would fail – and true to form, it usually did. Scope Management is too important to be viewed as the “management flavor of the month” and when the organization lacks an outlook for success, it becomes a self-fulfilling prophecy.
• Wherewithal: pertains to the capability, the potential, the aptitude, and the capacity for an organization to achieve the change it desires. A process immature organization cannot become world-class overnight and if it attempts to do so, it will demotivate its staff in the process. Goals must be achievable within the capability of the company and its people or the initiative will not succeed.
• Evaluation: this ingredient involves measurement, comparative analysis of data, and the identification of improvement opportunities. Additionally, the reward system in place for the organization must also be aligned to ensure there are no negative results afforded to participating teams or individuals. DeMarco and Lister summed up the need for measurement with “If you don’t know it, you can’t begin to do something about it.” DeMarco, 1997)
• Resources: allocation of resources includes formalized plans, organizational devices, automated tools, and human resources. While scope management and process improvement span more than a single project, their implementation should be treated in the same way as any formal implementation project. That is, the initiative must be prioritized, budgeted, scheduled, and executed with a sense of controlled urgency. If the success of an initiative really matters to an organization, there must be dedicated and allocated resources for its achievement.

If one or more of the POWER ingredients is missing from an organizational change initiative, the likelihood of failure increases. Each ingredient is an essential part of organizational change and they address both the important technical as well as cultural (people) issues. (Dekkers, 2000). Paul Willman identified similar components for effective change and went one step further to identify the resultant behavior if one important component is missing (Exhibit 8). In each row, a cell where there is not a “+” indicates an absence of the particular ingredient and the rightmost cell at the end of each row depicts the typical result. (Willman, 1996).

Exhibit 8 - Willman model for organizational change (Willman, 1996)

Through the results of NorthernSCOPE and SouthernSCOPE, Scope Management processes are a proven means to leveraging and augmenting professional project management on ICT projects. With the current levels of project rework in the vicinity of 45% of development effort, our industry surely needs to increase its ICT project success, and one proven way is through Concrete Scope Management.