Abstract
The Information and Communications Technology (ICT) world is addicted to dysfunctional behaviour and the problem is spreading globally. The impact of this addiction is devastating - billions of dollars are spent on rework and enhancements to (often defective) software. While professional project management and process improvement initiatives have improved the situation, the sad truth is that the parties in the ICT relationship (the customer and the supplier) are largely co-dependent on pattern of dysfunction characterized by ineffective communication and eroding trust. As part of the industry, we believe that all parties to the problem need to face up to their role and take steps to sustainable recovery. For many ICT projects, this is a surmountable problem with positive outcomes. By tackling the issues head-on, progress is reported by two countries: Australia and Finland, through formalized scope management concepts embodied in their southernSCOPE and northernSCOPE approaches respectively. Within the first few years, both initiatives have reversed the trend of failed projects posting increased ICT program success and improved customer / supplier relationships. Both approaches are based on project management best practices combined with customer-centric scope management.
This paper focuses specifically on the northernSCOPE 12-step process for ICT program “recovery” established and practiced by the Finnish author. It also outlines the qualifications for the new Certified Scope Manager (CSM) job role standardized by the European Certificates Association (ECA) in support of northernSCOPE. SouthernSCOPE is a similar approach developed by the Victorian Government in Australia and is composed of 8 of the steps of northernSCOPE. (For the interest of readers in the Southern Hemisphere, we have indicated which northernSCOPE steps are not included in the southernSCOPE method.)
Introduction
Personal addiction habits are so pervasive a problem in society that Alcoholics Anonymous formulated a 12-step program for recovery, for which many recovering alcoholics, their families, and recovering addicts of other behaviour are thankful. The basic premise, established over 75 years ago, involves admittance of the facts, determination, trust, continuous self-control, and very often external help and support. The recognition that addictive behaviour does not constitute goodness (or badness) of the person(s) involved can be essential to a successful recovery. Though it's not easy, numerous of people have changed their behaviour permanently by following these famous 12 steps. While not immediately obvious how this applies to software, one might consider the response of an alcoholic to the request to add another drink to his/her evening in a similar manner to a project manager who takes on more projects that have not been scoped properly (or in some cases, at all):
“Yes, of course, my friend! Why not. Not a problem for me. I can always manage one more.”
The denial together with a lack of recognition of addictive behaviour makes change especially difficult in organizations. The Information and Communications Technology (ICT) world is addicted to dysfunctional behaviour (fixed price agreed before requirements) and it is a spreading global problem. The impact of this addiction is devastating - billions of dollars are spent on rework and enhancements to (defective) software. A staggering 2/3 of ICT projects are deemed failures by the annual CHAOS report (Standish Group, 2003), with schedule extensions, cost overruns, and poor quality software more the norm than the exception to the rule. One can find a story in practically in practically every news-day describing ICT projects over-budget by 100's of percent, years behind schedule, or cancelled after millions have been spent.
Almost a decade ago, software suppliers recognized their role in this addiction, and started investing in process improvement. Similarly, customers focused on technology in the hopes that they could better direct suppliers to implement the right solution. Professional project management and software process improvement initiatives helped streamline the supplier side of ICT programs and projects. However, the issues at play are systemic and involve customers and suppliers. The truth is that ICT remains largely dysfunctional because the main two parties to the ICT relationship (the customer and the supplier) are co-dependent on the current situation where effective communication and trust characterize underlying issues. Questions of how to improve this state of affairs, in an industry of advanced technology, bright project managers, and leading edge maturity models, led two countries, Australia and Finland, to investigate further - with results worthy of attention.
Breakthroughs to change the addictive behaviour and put ICT programs on the road to recovery are already established in Finland with the 12-step northernSCOPE, and in the Victorian Government sector of Australia with their 8-step southernSCOPE approach. Both initiatives examine and advance ICT programs through steps that initialize, scope, split into manageable sub-projects (as necessary), quantify their size, cost (on the basis of currency per unit size), manage and deliver through professional ICT Scope Management. The results of both approaches are profound: success rates on ICT projects have skyrocketed, and cost overruns have plummeted to levels unprecedented in the ICT industry. In 2005, the International Software Benchmarking Standards Group proclaimed “the cost overruns for projects using the southernSCOPE method were found to be less than 10% whereas the industry norm was 84% (ISBSG, 2005).
This paper focuses on the concepts of the more recent northernSCOPE, and the differences between it and southernSCOPE will be noted as appropriate. Additionally, the new job role of a Certified Scope Manager (CSM) as established by the European Certificates Association is briefly mentioned. 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 by-product of project management.
Why Scope Management
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.
Scope management has been proven to effectively address five out of six of the most common reasons cited for ICT project cost overruns and uncontrolled project growth: (Wright, 2000)
- lack of user input,
- incomplete requirements,
- changing requirements,
- technology incompetence, and
- unrealistic expectations.
Scope management is critical to successful ICT project completion. NorthernSCOPE places scope management dead centre in the overall PMBOK® Guide knowledge areas because it involves and interfaces with all of the other eight areas as depicted in Exhibit 1.
Exhibit 1 - Scope Management Concepts of northernSCOPE (Forselius, 2003)
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 1, 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…<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) 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 as depicted in Exhibit 2.
Exhibit 2 - Mapping of northernSCOPE's processes (rectangles) against PMBOK® Guide Process Groups (ovals)
Scope management is best carried out by an independent and knowledgeable scope manager trained in ICT project management, customer relations (communication), software estimation, requirements elicitation, functional size measurement, change management, and best practices. As a third party usually hired by the customer, the scope manager is an advocate to both the customer(s) and the supplier(s). The role is similar to a construction inspector/coordinator – providing project oversight, governance, measurement, communication, change management, progress reporting, and experience data collection. The European Certificates Association (ECA) formalized the northernSCOPE based Certified Scope Manager (CSM) job role in October 2007.
northernSCOPE
northernSCOPE is a 12-step approach to professional scope management developed in the late 1990's by the Finnish Software Measurement Association (FiSMA, 2007). Since 2005, the Finnish author has trained tens of Certified Scope Managers, and it has now commenced globally 4SUM Partners and Quality Plus Technologies (Dekkers, 2007).
northernSCOPE is summarized in Exhibit 3. While there may be multiple customers and/or suppliers (e.g., hardware, software, integration suppliers), the scope manager works with all of those affected. Each step is further explained following Exhibit 3.
Exhibit 3 – The 12 steps of northernSCOPE
Step 1: Scope manager retained, customer-driven high level requirements
northernSCOPE is initiated when the customer or software acquirer (or the software supplier) recognizes the need for, and retains, a scope manager for a new ICT Program. (Note at this point, customers may refer to the “project”, however, it is more likely an ICT “program” with several projects. See step 2.) We advocate using a Certified Scope Manager (CSM) to ensure there is a basic level of knowledge and experience with northernSCOPE.
The first task is a meeting with the customer (typically the program or project steering committee) to outline the roles and responsibilities of the scope manager, the customer(s), and the software supplier(s). This meeting allows the customer to ask questions and to clarify their role. The scope manager also reviews the high level customer requirements for completeness and clarity, and discusses their envisaged scope and expectations with the customer
Step 2: Divide program into subprojects
Using the high level requirements from step 1, and the program subdivision rules of Exhibit 4, the scope manager divides the program of work into appropriate subprojects. Note that this is similar to subdividing a construction project into distinct subprojects – each of which is typically managed separately and involves unique tasks. This is important to do as early as possible, preferably by the initiation.
Exhibit 4 illustrates the ICT program subdivision rules, while Exhibit 5 depicts the seven possible (sub) project types. From the number of rules in Exhibit 4 and the possible combinations, this approach leads to a larger number of small projects. As with any approach there are a number of pros and cons. One of the biggest pros is improved manageability, which is so important to program/project success that neither the customer nor the supplier should resist it. This subdivision has been a successful component of on-time and on-cost delivery in northernSCOPE. (Note: this is not part of southernSCOPE).
Exhibit 4: Guidance on dividing ICT programs into projects and sub-projects (FIPA, 2005)
There are seven distinct ICT project types listed in Exhibit 5, and while it is understood that there are many additional variations on these seven project types, these were the most common in practice.
Exhibit 5 - ICT Project Types (Forselius, 2003)
The software development life cycle phases such as requirements through to implementation are not considered as being independent ICT project types, but rather as phases within each sub-project itself.
Step 3: Scope manager does early FP for each subproject and estimates total size
Using the high level customer requirements for each subproject from step 2, the scope manager performs an initial functional size estimate where appropriate. Note that the functional size measures only the functionality of the software – equally important are the quality and technical requirements as outlined in step 4. The functional size of the program software is the sum of all its subprojects.
Depending on the completeness of the functional user requirements (remember that this prior to a supplier engagement) – this estimated functional size gives the scope manager and the customer a “ball park” idea of how big the ICT program could be. If the functional requirements are too vague, then the customer must do work to at least identify the business processes to be supported by the software. If a customer cannot state their needs, then a supplier cannot provide an appropriate solution.
Several subproject types (and also work such as support and fixes) are inappropriate for sizing with functional size measurement. These include technical upgrades, maintenance work, etc. Function points are a “square foot” type of measure used to quantify the functional user requirements for software, and without them, the work effort must be estimated using another method such as an hourly rate or historical-based estimate. It is important to communicate to the customer about which subprojects can and cannot be sized using functional size measurement.
Step 4: Scope manager and customer determine and analyse quality requirements
This step is unique to northernSCOPE and examines the quality requirements for each subproject based on the ISO/IEC 9126 quality model. It is well established that the non-functional requirements for software can dramatically increase the work effort and cost of software development, however, often these requirements are not identified until too late in the project to respond effectively. “A tiny change in Non-functional requirements (NFR) can cause a huge change in the cost.” (Boehm, 2005). Boehm went on to cite the tripling of a $10 million [USD] project to $30 million [USD] when the response time (of a NFR) went from four seconds to one. SouthernSCOPE does identify this as a step in their approach.
Step 5: Customer issues request for proposal (RFP)
In this step, the customer, with the assistance of the scope manager, prepares the RFP and evaluation criteria for the program and then issues it to a set of software suppliers. The “laundry lists” of the high level functional and quality requirements apportioned by sub-project are included as attachments to the RFP in order for suppliers to submit unit pricing estimates.
Step 6: Customer selects supplier based on submitted unit cost per FP
The scope manager assists the customer to evaluate the supplier responses and provides high-level input to the validity of their rates based on industry (ISBSG and Experience® Pro software) rates. The customer selects one or more suppliers to meet the program needs.
Step 7: Requirements specification developed
This is the first step in northernSCOPE where the scope manager does not play an active part The customer works directly with the supplier(s) to develop and “flesh out” the requirements for the subprojects.
Step 8: Scope manager baselines FP size and product development
The requirements documents for those subprojects for which functional size is appropriate are the input to this step. The scope manager reviews the requirements and develops the function point (FP) count “baseline” for each. This step is similar to finalizing and size a house floor plan, and becomes the base against which any changes and progress are made.
Step 9: Scope manager sizes project changes, cost impact evaluated (based on same cost / FP)
As changes are made and approved for the project (by the customer or by the supplier in agreement with the customer), the scope manager collects the data and records it in the Experience® Pro software in order to track the work performed by the supplier. A cost estimate is also made of the impact of accepting such changes at the point in the project where they are identified (based on the cost / FP originally quoted by the supplier). A formal change management process facilitates this step.
Step 10: Scope manager quantifies progress
As each project progresses, the scope manager receives documentation from the supplier(s). Using the baseline(s) from step 8, the scope manager records the progress and prepares a formal status report for the customer. Usually this occurs on a monthly basis, but the exact timeframe of this reporting is established with the parties after step 7. Note that this step is not done in southernSCOPE
Step 11: Project finishes and customer pays supplier based on FP delivered
This is the second and final step of northernSCOPE where the scope manager is not directly involved. The customer pays the supplier(s) based on the FP delivered for each subproject and on whatever other mechanism for units of payment are used on the non-function point countable subproject(s). From the customer and supplier points of view, the program of work is now complete and the project manager closes the project(s).
Step 12: Experience data collected & stored
The scope manager finalises the project by recording the data collected during the project(s). Actual values for work effort and related project variables are entered into Experience® Pro scope management software along with relevant project attributes. Note that this step is not done in southernSCOPE.
It is worth noting that there are several concepts introduced in the Scope Management processes that are not traditionally included in ICT projects. 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 Actual values
- Feedback loop to estimate, then incorporate and track accepted changes into the existing project documents 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 6).
Exhibit 6 - 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 centres 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.
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.
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. In summary: Success needs a good 12 step program, admittance of the facts, determination, trust, continuous control, and help and support from a professional Scope Manager.