ARCHIVED - Establishing the Baseline - Government-Wide Summary and Analysis of IT Project Practices

This page has been archived.

An Enhanced Framework for the Management of Information Technology Projects

Establishing the Baseline - Government-Wide Summary and Analysis of IT Project Practices

June 1, 1998
Chief Information Officer Branch
Treasury Board of Canada Secretariat

Acknowledgments

The authors of this document, David Holmes, (Treasury Board of Canada Secretariat, Project Management Office) and Denis Godcharles, (Godcharles Goulet Fournier) would like to acknowledge the contributions of the following participants:

Marj Akerley
Crayden Arcand
François Audet
Serge de Bellefeuille
Pierrette Benois-Doris
Darlene Bisaillon
Ray Blewett
Greta Bossenmaier
Larry Bristowe
Bill Brittain
Barry Brock (Colonel)
Aaron Caplan
Richard Chauret
Yvon Claude
Edward B. Cook
Kevin Collins
Paul Conway
Robert Cosh
Joan Delavigne
Bob Fraser
Barry Ferrar
David From
N.D. Funk
Brian Gallant
Michel Gilbert
Julia Ginley
Bruce Gordon
Réjean Gravel
Dick Gross
Terry Harding
Wayne Harrison
Dorene Hartling
Janice Hatt
Don Hobbins
Dave Holdham
Michael Jeays
Richard Johnston
Debbie Jones
Jim Klotz
Nabil Kraya
Gloria Kuffner
David Lafranchise
Robert Lalonde
Ken Leblanc
William Lowthian
Yves Marleau
Peter McLean
Doug McMillan
Guy Millaire
Henry Murphy
Peter Oberle
Heather Parry
Christine Payant
Patty Pomeroy
Tom Racine
Ron Ramsey
Jenny Steel
Katherine Stewart
Dianne Symchych
Mel Turner
Frances Walsh
Jim Westover
Bob Wilkinson
Howard Williams
Leslie Whitney
Chak Lam Wong

1.  Introduction

This section is an introduction to the Enhanced Framework initiative within the federal government and how it will be used to implement and promote best practices in the management and delivery of Information Technology (IT) projects

1.1 Background

The government is committed to delivering its programs and services more efficiently and effectively through the use of IT. Reviews of government IT projects conducted by the Treasury Board of Canada Secretariat (TBS) and the Office of the Auditor General (OAG) have identified issues with the government's management and delivery of IT projects.

To address these issues and enhance the framework for managing and delivering IT projects, a TBS Project Management Office (PMO) was formed. The purpose of the PMO is to provide guidance and support to departments, helping them ensure that the government's IT projects:

• Satisfy the requirements of the program functions or services they are designed to support;
• Deliver all expected benefits; and
• Are completed on time and within budget.

In May 1996, the PMO, in conjunction with operating departments, published a document of guiding principles and best practices that address project management issues experienced within the federal government. The resulting document, An Enhanced Framework for the Management of Information Technology Projects,¹ provides guidance for improvements to IT project management practices.

One of the directions to be embraced includes the promotion and implementation of industry best practices in areas relevant to the Enhanced Framework. Currently promoted practices are detailed in the Enhanced Framework II: Solutions: Putting the Principles to Work,² which is available through the PMO and on the Internet (www.tbs-sct.gc.ca). In order to expand and enhance this initial set of solutions and further assist departments in their improvement efforts, the PMO had a requirement to establish a baseline of project-related practices.

1.2 Purpose

The purpose of this document is to present the results from a series of workshops that examined the federal government's existing practices in managing and delivering IT projects. Summary results from a government-wide perspective are presented in this document. Individual department results are presented in separate documents.

1.3 Rationale for Establishing a Baseline of Current Practices

Sustainable improvements in IT project success rates can only be achieved through a clear understanding of an organization's project results and the practices that led to those results.

Deficiencies associated with the management and delivery of IT projects in the federal government have been documented.³ However, minimal information has been available about either the presence or absence of practices that led to these inadequate results. In order to better direct and guide improvement initiatives, a baseline that addresses practice strengths as well as deficiencies had to be established. A clear understanding of gaps or weaknesses would then enable departments to relate results to practices and thereby improve their ability to successfully manage and deliver IT projects. A continued lack of understanding of these practices and how they affect project results would likely lead to inefficient or inappropriate investments in implementing best practices, and delay improved returns on IT investments.

Finally, there was a need to develop a baseline across the government in order to provide a meaningful reference point for all departments. Currently available practice databases often have few occurrences of public sector organizations and may not reflect the "true environment" of the Canadian public service. This is the first time that this type of baseline has been produced for the federal government.

1.4 Intended Use

The resulting baseline has two key components. The first component is the individual departmental baseline. The second is this government-wide summary and analysis of the overall results. Within this context, the different uses of the baseline results are numerous. The departmental baseline will enable those responsible in departments to:

• Identify strengths and areas for improvement;
• Identify investment priorities for improvement;
• Measure progress in implementing best practices; and
• Compare results with others in various categories.

The TBS will use both components of the baseline to:

• Query submissions based on results;
• Identify investment priorities for improvement;
• Promote departmental improvement activities; and
• Monitor progress.

The baseline is a useful tool that sets the stage for significant improvement and provides a benchmark against which to measure progress.

1.5 Audience

Although many will have an interest in the baseline, it is targeted at two primary audiences within departments:

• The "supplier" of IT services and/or products who will benefit from a better understanding of the strengths and limitations of its organization as well as the possible areas for improvement; and
• The "acquirer" of the IT services and/or products who will benefit from a better understanding of the capabilities of its supplier as well as the range of practices required to manage and deliver IT projects.

2. Methodology

This section describes the approach used to establish the baseline.

2.1 The Foundation

The Software Engineering Institute's (SEI) Software Capability Maturity Model (SW-CMM) ⁴ and the corresponding CMM Based Appraisal for Internal Process Improvement (CBA-IPI) method was selected as the foundation for the baselining methodology. This method was preferred over other available methods because of its widespread support in the industry and its ability to provide the government with a thorough assessment of the processes currently implemented within departments.

The CBA-IPI approach, however, requires significant investment in terms of both human and financial resources, and it considerably impacts organizations⁵. As a result, the approach used was one that respected the principles and practices required in the CBA-IPI, yet minimized the impact on departmental participants. In essence, the methodology was streamlined to:

• Enable individual departmental assessments to be done in half a day; and
• Minimize the number of required participants by using a small but knowledgeable and experienced sample of IT practitioners and managers.

The streamlined methodology consisted of administering a questionnaire that was based upon one developed by the Software Productivity Centre (SPC) for their SoftGuide^TM product. The SoftGuide^TM questions apply to organizations currently operating at Level 1 or 2 of the SEI S/W-CMM. The terminology and degree of formality of the questions in SoftGuide^TM are more suitable to the size and structure of Canadian government IT organizations than is SEI's Maturity Questionnaire. The SoftGuide^TM approach has been used successfully in over 30 assessments.

2.2 The Questionnaire

The SoftGuide^TM questionnaire contains 89 questions from the 13 Key Process Areas corresponding to Levels 2 and 3 of the SEI SW-CMM.⁶ In order to properly address the full scope of the Enhanced Framework, the SoftGuide^TM questionnaire was expanded to:

• Address Project Governance issues identified in the Enhanced Framework;
• Cover the system-level activities normally preceding and following the SW-CMM Key Process Areas; and
• Address all types of government IT projects, including Software Acquisition and infrastructure projects.

Despite the substantial differences between departments—in size of IT expenditures, in IT management styles, and in IT Service Delivery Models—the questionnaire was applicable to all participating departments. Participants were able to relate to the questions and respond appropriately whether projects were traditional software development, commercial off the shelf (COTS) acquisition, or infrastructure upgrades. This shows that the Key Practice Areas assessed are generic and validates the baseline results as a tool that can provide guidance towards improvement. The final list of questions is provided in Appendix 1.

2.3 The Participants

Twenty of the largest departments in terms of IT-related expenditures were solicited to participate in the baselining process. Their level of IT expenditure was based on 1996/1997 data from a Central Accounts report dated June 5, 1997. All departments responded positively and key representatives from each participated in a half-day workshop conducted for their department. The list of participating departments and participants is provided in Appendix 2.

2.4 The Workshops

All the workshops were conducted from November 1997 to March 1998 by the authors of this report. Everyone participating in the workshop was given a brief presentation that described the Enhanced Framework, the SEI SW-CMM, and the assessment process. This presentation preceded the administration of the questionnaire.

The possible responses⁷ to the questions were as follows:

• Yes when:
  – The practice is well established and consistently performed;
  – The practice is almost always followed; and
  – The practice is considered standard operating procedure.

• No when:
  – The practice is not well established or is not consistently performed; and
  – The practice may be performed sometimes, or even frequently, but it is omitted under difficult circumstances.

• Does Not Apply when:
  – Participants had the required knowledge about the project or organization and about the question asked, but felt the question did not apply to their department. For example, the section on "Subcontract Management" will not apply if the department does not subcontract work.

• Don't Know when:
  –Participants did not know how to answer the question.

Rather than strictly observing the Yes/No criteria defined above, common sense was used to determine when to respond Yes or No. The "80/20" rule was adopted: when 80 percent of projects within a department implemented the practice, participants answered Yes. Such an interpretation of the Yes/No criteria is not unusual in assessment methodologies.

In addition, participants often qualified their responses with "Yes, but…" or "No, but…" followed by an explanation. Sometimes discussion of the perceived need—or lack of need—for improvement in a specific area led to the decision on what to respond. Participants used the Comments section of the questionnaires to qualify their response or to record the results of their discussions.

During each workshop, participants reached an understanding as to what constituted a "project" within a given department. This consensus was necessary in order to provide a sound and consistent basis for responding to the project-related questions. While these definitions were not necessarily consistent across all departments, TBS PMO representatives enforced an acceptable range of definitions to preserve the integrity of the baseline results. This understanding was documented in the workshop record.

All answers were recorded and sent to the participating departments for internal review and validation. These validated results provide the basis for the baseline.

3. Workshop Results

This section provides the workshop results summarized across participating departments, a detailed analysis of these overall results, and guidelines for reading and interpreting them. Where applicable, observations by the authors have been provided.

3.1 How to Read and Interpret the Results

The purpose of the baseline is to stimulate government departments to improve their ability to successfully manage and deliver IT projects. The results presented in this section must be read and interpreted within this context. While the results provide valuable insight into the government's project management and delivery capability, it must be understood that the population surveyed constituted only a small sample of the entire IT practitioner and manager knowledge base. Readers must be careful to neither jump to hasty conclusions, nor judge the government's IT project management and delivery capabilities solely on the basis of this baseline.

Specific departmental baseline components can be compared against the various summary profiles provided in this report. Several analyses have been conducted and can be used for different comparisons. These comparisons can provide some indication regarding the department's position vis-à-vis other departments.

3.2 Results

3.2.1 Overall Results
Overall results are given first, in order to provide an overview of the state of implementation of project practices across the government.

Figure 1 below presents the overall results. Each bar on the graph represents the percentage of satisfaction level for each Key Practice Area. Practices are on the "Y" axis while practice satisfaction levels are represented on the "X" axis.

Figure 1. Overall Results

Observations
The practices that achieved the highest satisfaction levels include:

• Subcontract management (85%);
• Requirements management (69%);
• Inter-group coordination (69%);
• Project planning (69%);
• Systems Engineering/Software Acquisition (69%); and
• Project tracking and Oversight (63%).

The practices that achieved the lowest satisfaction levels include:

• Integrated project management (11%); and
• Peer reviews (17%).

Analysis of Overall Results
Analysis of the overall results identify definite strengths in the management and delivery of IT projects as shown above.

Areas of improvement include:

• Project Governance. Departments scored particularly low in the areas of Project Governance and risk-based decision-making as defined in the Enhanced Framework. More specifically, departments scored 20% in the area of clear competency requirements for project managers, and 30% in using risk-mitigating techniques such as clearly defined gates, structured risk management, function point analysis, and earned value management;
• Process Focus and Process Definition. Few departments consistently develop and improve standard processes for use in projects. Whereas 70% said that the role of defining and maintaining standard processes existed within the organization, they scored less than 30% in:
  • developing action plans to address process deficiencies;
  • training individuals on process;
  • planning for process development or improvement activities; or
  • making process assets available within departments for re-use.

• Integrated Project Management. Organizations scored 11% on average in the area of project management methodology, and most do not have standard procedures to collect effort, cost, and schedule progress information;
• Software Product Engineering. Core to the delivery of IT projects, departments scored less than 40% in the area of Software Product Engineering (for example, Software/System Life Cycle or Software/System Development Methodology);
• Configuration Management/Quality Assurance. Departments had a satisfaction level of less than 40% in the areas of configuration management and quality assurance. Whereas the low satisfaction level for these processes was mostly due to inconsistencies in their implementation, some departments did not perform these processes at all.
• Peer Reviews. Departments scored 17% in the area of Peer Reviews as part of their approach to managing and delivering IT projects; and
• Collection and Management of Historical Data. Less than 10% of departments, on average, collected and managed historical data for current and future use in support of the planning process or process improvement initiatives.

3.2.2 Weighted Results
The same results are presented using a weighting factor. The weighting factor takes into account the relative size of each department, based on the amount of money it spends on IT relative to the total expenditure of the population of departments examined.

Figure 2 below portrays the weighted results.Each bar on the graph represents the weighted percentage of satisfaction levels for each Key Practice Area. The weighting factor was determined by computing the ratio of a department's IT expenditure over the total IT expenditure of the entire population of departments involved in this study. Weighted results were then obtained by adding the products of each department's satisfaction level and weighting factor. Practices are on the "Y" axis and satisfaction levels are represented on the "X" axis.

Figure 2. Weighted Results

Observations
The impact of the weighting factors on the overall results was generally positive, increasing the satisfaction levels of the following best practices:

• Subcontract management (94%, up 9%);
• Requirements management (73%, up 4%);
• Inter-group coordination (73%, up 4%);
• Project planning (82%, up 13%);
• Systems Engineering/Software Acquisition (77%, up 8%), and
• Project tracking and oversight (69%, up 6%).

The practices that achieved the lowest satisfaction levels include:

• Integrated project management (even at 11%); and
• Peer reviews (13%, down 4%).

Analysis of Weighted Results
Weighted results generally improve the government's overall performance. This is primarily due to more mature processes found in larger departments.

3.2.3 Overall Results by IT Expenditure Category

The overall results are categorized based on the size of IT expenditure in order to allow readers to compare departmental performance against those in the same IT expenditure range. These results are provided in Table 1 below and in a graphical presentation in Figure 3. For the purpose of this report, four categories were identified:

• Departments with IT expenditures less than $25M (5 departments);
• Departments with IT expenditures exceeding $25M, but less than $50M (8 departments);
• Departments with IT expenditures exceeding $50M, but less than $100M (4 departments); and
• Departments with IT expenditures exceeding $100M (3 departments).

IT expenditures were confirmed during the results validation process with the departments. Expenditures include all IT related expenditures (software development and maintenance as well as infrastructure capital and O&M expenditures).

Table 1. Overall Results by IT Expenditure Category

Table 1 is depicted below graphically.

Figure 3. Overall Results by IT Expenditure Category

Analysis of Results by IT Expenditure Category
Few trends can be identified from the results by IT Expenditure Category, other than the fact that there seems to be a correlation between the size of the department and the satisfaction level for each practice. In general, the bigger departments (that is, departments with the larger IT expenditures), are better at implementing and consistently applying processes. Nevertheless, departments in the $50M to $100M category generally appear more satisfied with project practices than those in the over $100M or more category. These results can be explained in many ways, including the fundamental fact that departments with larger IT expenditures have the opportunity to repeat management and delivery processes more often and consequently they become better at it.

3.2.4 Results by IT Management Model
The overall results are presented with departments characterized as having either a "decentralized" or a "centralized" mode of IT management. Some departments have a central IT organization that essentially does "everything" for its clients. Others have a decentralized IT capability where the responsibility for networks, the computing infrastructure and applications are shared among several groups. The responses of these two classes of departments were different, and the TBS PMO representatives wanted to allow departments to compare themselves against departments with the same management style as their own.

Figure 4 below provides a graphical representation of the results by IT Management Model. The lower bar of each pair represents the percentage of satisfaction levels for each practice achieved by the centralized departments. The upper bar represents the percentage of satisfaction levels for each practice achieved by the decentralized departments. Practices are on the "Y" axis and satisfaction levels are represented on the "X" axis.

Figure 4. Results by IT Management Model

Analysis of Results by IT Management Model
Results of the baseline categorized by management models reveal an interesting trend. It appears that centralized IT Management Models consistently achieve better satisfaction levels for the 15 key process areas with the exception of training. This trend may be explained by the fact that the departments that centralize the management of IT can better control their practices and the resources implementing the processes. Upon reflection, this is an unsurprising and predictable result. However, there are many valid business reasons for decentralizing the management of IT and readers are reminded not to jump to hasty conclusions. Departments with a decentralized IT management model may wish to baseline the practices in different areas and use the result to identify best practices and leverage them throughout the department.

3.2.5 Results by IT Service Delivery Model
The results are presented with departments characterized as having either an "in-source" or "out-source" IT service delivery mode. Some departments have considerable programming staff and do most of their work using internal resources. When using contracted resources, these departments will likely retain the overall responsibility for the project outcomes. Others use contracted resources to do most of the IT project-oriented work. These departments tend to transfer most of the risks to these contracted resources. Again, the issues associated with each approach are different, and departments may find it useful to compare against others in their own IT service delivery category.

Figure 5 below provides a graphical representation of the results by IT Service Delivery Model. The lower bar of each pair on the graph represents the percentage of satisfaction levels for each practice achieved by the "in-sourcing" departments. The upper bar represents the percentage of satisfaction levels for each practice achieved by the "out-sourcing" departments. Practices are on the "Y" axis; and satisfaction levels are represented on the "X" axis.

Analysis of Results by IT Service Delivery Model
Overall results categorized by IT Service Delivery Models are also revealing with respect to the levels of satisfaction. It appears that in-sourced departments achieve better levels of satisfaction across all Key Practice Areas with the exception of requirements management, project tracking and oversight, and configuration management. Once again, this trend may be attributable to the fact that the departments that in-source the delivery of IT can better control their practices and the resources implementing the processes.

Figure 5: Results by IT Service Delivery Model

3.2.6 Mapping the Results Against the Enhanced Framework Targets
This section maps the overall results to the objectives set out by the PMO in the Enhanced Framework II: Solutions: Putting the Principles to Work. This document sets improvement targets in terms the following plateaus:

• Plateau 0 (March 1998). Ensure that departments have in place the basic project solutions required to initiate and manage projects, and that they have plans for advancing to the next plateaus;
• Plateau 1 (March 1999). Achieve proper planning for projects and establish sufficient visibility into actual progress to allow senior management to take effective action when the project deviates from the plan;
• Plateau 2 (March 2000). Establish, at a project level, consistent and effective controls and processes that will ensure that requirements are managed, that the product integrity is maintained throughout the life of the project, and that the quality of the product is within the defined parameters;
• Plateau 3 (March 2002). Make the practices found in Plateaus 0-2 the way that government departments do business for all their projects; and
• Plateau 4 (On-going). Improve the organizational effectiveness of departments on a continuous basis when managing and delivering projects.

In order to get a better sense of the overall results against these plateaus, Table 2 maps practice satisfaction levels to each plateau.

Table 2: Mapping the Results Against the Enhanced Framework Targets⁸

Analysis of the Mapping Results against the Enhanced Framework Targets
An area of real concern, also identified above in Section 3.2.1, is Project Governance as outlined in the Enhanced Framework. The activities involved are those that get the right project off on the right track: an effective governance structure within the department; a sound business case approach to selecting projects; a definitive project charter and a clear accountability structure; a disciplined approach to training, developing and selecting project managers; and an effective risk management regime. All are key to the successful management and delivery of IT projects and it is particularly vital that this foundation be established properly.

Understanding that higher level practices can seldom be improved without the benefit of consistently implemented practices at the lower levels, this analysis provides guidance and direction to focus government-wide improvement initiatives.

3.2.7 Mapping the Results against the OAG findings
This section examines the baseline results against those of the OAG's main issues emerging from their review process of systems under development for the past three years (1995 to 1997)⁹. The latter results can be found on the OAG's web site at www.oag-bvg.gc.ca. OAG main issues are provided in the first column, along with the year they were identified (second column). Corresponding baseline references and satisfaction levels identified in the baseline are provided in the last two columns. Numbers in the third column refer to the questions found in Appendix 1 (PG=Project Governance, SE=Systems Engineering/Software Acquisition, CMM=Capability Maturity Model).

Table 3: Baseline results against OAG findings

Auditor General's Findings	OAG Ref.	Baseline Ref.	Average Satisfaction Levels
Smaller chunks for projects	OAG '95	PG 4.1, PG 4.2, PG 4.3	.35
Effective project sponsorship	OAG '95	PG 2.1	.70
Clearly defined requirements	OAG '95	CMM 1	.69
Effective user involvement	OAG '95	SE 1 CMM 12 CMM 1.1,1.4, 2.3, 2.5, 3.5	.75
Dedicated resources to projects	OAG '95	PG 2.4, PG 4.8, CMM 11.8	.59
Taking charge	OAG '96	PG 2	.58
Define requirements	OAG '96	CMM 1	.69
Improve software development processes	OAG '96	CMM 7, CMM 8	.34
Setting priorities	OAG '96	PG 1	.56
Measuring status of projects	OAG '96	PG 4.7, PG 4.1 CMM 3	.44
Implementing new government guidelines	OAG '96	CMM 7, CMM 8	.34
Planning	OAG '97	CMM 2	.69
Oversight	OAG '97	PG 4.7, PG 4.1 CMM 3	.44
Quality assurance	OAG '97	CMM 5	.40

Analysis of the Mapping Results against the OAG findings
Mapping the Baseline results to the OAG findings identifies similar deficiencies in project management and delivery practices. Nonetheless, the baseline report identified possible improvements in the areas of:

a. Project sponsorship;
b. Requirements management;
c. User involvement; and
d. Planning.

4. Concluding Remarks

4.1 Next Steps

It is recommended that departments use the baseline to confirm departmental practice improvement initiatives and to justify future plans for implementing industry best practices. It is further recommended that the steps identified below, be performed in the very near future in order to benefit from the momentum already set in motion by the participants:

• Establish an "Improvement" Infrastructure. To support the plan, departments should put in place an organizational structure that includes the appropriate governance structure. Key resources should also be committed;
• Goals Setting Phase. Departments should establish clear goals for implementing best practices in the coming year. Workshop discussions indicated that in every department, plans exist and activities are taking place that will lead to improvements in the Key Practice Areas assessed. In some cases, this represents a specific attempt to align with the Enhanced Framework. In others, it is simply management recognition that change is necessary and the relationship to the Enhanced Framework is purely coincidental. In either case, these plans and activities can form the basis for improvement plans as called for in the Enhanced Framework II document and targets set out therein should be used as guidelines to identify key milestones; and
• Acting and Leveraging. Departments should then proceed with the implementation of best practices and their plans. Not surprisingly, different departments demonstrated strengths in a number of different Key Practice Areas. In some cases these strengths may be able to be leveraged between departments by sharing available guides, handbooks, procedures, tools, and other artifacts. TBS PMO will be assembling these artifacts to expand and enhance the Enhanced Framework solution set.

4.2 Recommendations

The process of establishing a baseline of the current state of project practices is only the first step in implementing sustainable improvements and best industry practices as they relate to the management and delivery of IT projects within the federal government. The purpose of the baseline is to stimulate departments to improve their ability to successfully manage and deliver IT projects. This baseline document provides a snapshot of how the government is doing with regards to the implementation of these practices.

Each department should now, as indicated during the workshops that led to these results, develop a detailed action plan to initiate improvement activities. Based on workshop results, it is expected that this initial action plan will contain a subset of departmental plans already developed and approved for the upcoming year. The plan should provide high-level information regarding the background, business justification, and goals of the improvement initiative(s); the key work elements; the roles and responsibilities of stakeholders; key milestones; and resources assigned to the improvement activities. Templates and examples can be provided by the PMO to departments for their respective plans.

Departments should re-assess their organizations and measure progress. The PMO will make available an electronic and improved version of the questionnaire used to determine this baseline. Departments will be able to repeat this process within their organization and, possibly, to extend it to other areas not covered during this first pass. In some cases participants were not able to respond to the questions in a fashion that fairly represented the whole department. This was particularly true in some departments with a decentralized IT management style. It became apparent, in fact, that some departments should have several baselines to represent the different practices in place in different areas, rather than one baseline to represent the whole. Departments should make that determination in consultation with their practice implementation groups.

Details on how to implement industry best practices were provided as part of the workshops in a document entitled SEI IDEAL^SM Model. This document is also available on the SEI Web Site (www.sei.cmu.edu). TBS PMO is also sponsoring special interest groups that are focusing on the implementation of best practices as discussed in this report. Departments should make use of these tools.

4.3 Conclusion

Information Technology is critical to delivering government programs and services more efficiently and effectively. Departments cannot afford project failures. They also cannot afford not to harvest the benefits of the technology they deploy. The workshop results confirm earlier studies and reviews by the TBS, the OAG, and the private sector that there are outstanding problems with project management practices. The baseline results for each department provide a useful insight into necessary improvements areas and an inherent basis for priority setting.

Implementing industry best practices is a significant step towards operational effectiveness and sound comptrollership currently strongly promoted within the government. The opportunity offered to senior managers to embrace proven solutions to a widely recognized problem is an opportunity not to be missed. This observation is especially relevant in light of the major "Year 2000" projects now under way.

The overall summary presented in this document and the individual department baseline reports can be a useful tool for setting the stage for significant improvement in the area of IT project management. It can provide a meaningful benchmark against which each department can measure its progress.

End Notes:

1. Treasury Board of Canada Secretariat, An Enhanced Framework for the Management of Information Technology Projects, Ottawa, Ontario, May 28, 1996.

2. Treasury Board of Canada Secretariat, Enhanced Framework II: Solutions: Putting the Principles to Work, Ottawa, Ontario, March 1998.

3. The TBS review, documented in An Enhanced Framework for the Management of Information Technology Projects, identified deficiencies in IT project results. A number of OAG reviews, available on their web site at www.oag-bvg.gc.ca, also identified deficiencies. Private sector-led surveys conducted by the Standish Group in the United States and by KPMG in Canada also identified similar problems with IT project results. These reviews were conducted between 1995 and 1997.

4. Paulk, Mark C.; Curtis, Bill; Chrissis, Mary Beth; Weber, Charles V.; "Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24"; Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, February 1993.

5. It should be noted that the S:PRIME process, available through the Applied Software Engineering Centre and GrafP Technologies Inc. and used in some departments, was also considered since it is also founded upon the CBA-IPI but is less resource-intensive. It too, however, has more of an impact on organizations than was felt possible to cope with at this time.

6. Brief definitions of the Key Process Areas are provided in Appendix 1.

7. Unless otherwise noted, answers to the questions were based on the participants' knowledge and experience in their current environment.

8. Readers should note the Requirements Management Key Process Area has been moved to facilitate the reading of the mapping results.

9. It should be noted that the processes used by the OAG to determine the main issues with the management and delivery of IT in the government are different than those used by the TBS to establish this baseline. Whereas the OAG follows a targeted approach with a focus on specific initiatives within the government, the TBS approach examines the implementation of the same practices but at the organizational level.

Appendix 1

List of Questions

A Status Report on Federal Government Project Practices

Project Governance Related Questions

1. Business Alignment: Information Technology projects are aligned with, and support, business directions and priorities
   
   
   • Is approval for the project based on a business-case analysis that relates the investment directly to the business function and demonstrates the benefits of the investment to the department or government as a whole?
   • Is there a business case template used by all projects?
   • Is there a documented process for preparing the business case, obtaining approvals, reviewing the business case, etc.
   • Will the business case be reviewed and revalidated at each scheduled gate and whenever there is a significant change to the project or the business function?
     
     
2. Accountability Structure: Clear accountabilities are established
   • Are overall departmental accountabilities for the project defined in a Project Charter?
   • Is there a project charter template used by all projects?
   • Is there a documented process for preparing the project charter, identifying roles and responsibilities of stakeholders, obtaining approvals, etc.
   • Are all core project management responsibilities and functions performed by Crown management? (includes core functions associated with managing & controlling project plan, scope, time, cost, quality, risk, human resources, procurement, contract & communications)
   • If it has been necessary to outsource any core project management functions, are they being acquired from a supplier other than that involved in the primary development contract?
     
     
3. Project Management Culture: Project managers are developed and work within a corporate discipline
   • Does the assigned project manager have the knowledge, skills and experience required to managing the project's scope, size, complexity and risk profile?
   • Are the competencies expected and required of project managers documented?
   • Is there a documented process that defines a training and development path for project managers?
     
     
4. Risk Culture: Project management decisions are based on risk management
   • Does the project have scheduled checkpoints or "gates" when it will be reviewed and where management will decide on its future, and if necessary, take appropriate corrective action?
   • Does the department's defined project life-cycle detail when and where gates should be established and what criteria must be satisfied before clearing the gate?
   • Have only the funds needed to reach the next gate been allocated to the project?
   • Has a risk assessment consistent with practices outlined in SEI's Continuous Risk Management Guidebook been used to identify and assess the risks?
   • Is there a documented risk management process (including tools, techniques, practices) that all projects must use?
   • Has project complexity been determined at the initiation of the project using Function Point Analysis (FPA)?
   • Is a performance measurement tool based on the national standard, C/SPMS, being used to provide data to the (Crown) project manager on the time and money expended and on the work completed at frequent intervals?
   • Have PWGSC procurement officers been involved early in the project planning so as to develop a procurement process that reduces delays, and to design a procurement plan that best aligns the contracting plan with the project plan?

Systems Engineering/Software Acquisition Related Questions

Systems Engineering/Software Acquisition, in the context of this questionnaire, involves transforming an operational need into a description of the system configuration (including acquired systems) which best satisfies the operational need and integrating the efforts of all disciplines and specialties (software development, infrastructure, etc) to yield a software product.

• Is there a documented process to elicit, stimulate, analyze, and communicate customer needs and expectations to obtain a better understanding of what will satisfy the customer? (This process typically corresponds to the system requirements analysis phase in traditional system life cycles)
• Is there a documented process to allocate business requirements to various system map functions (including objects, people, supporting processes, products and services) as part of the system design activities and/or the selection of off-the-shelf solutions? (This process corresponds to the system design activities)
• Is there a documented process to study and/or analyze candidate solutions prior to selecting a solution that will satisfy the business problem and its constraints? (This process corresponds to the make/buy analysis often performed during the system design phase)
• Is there a documented process to derive and allocate technical architecture requirements as part of the system design activities?
• Are software acquisitions projects implemented within the same rigor as development projects (including planning, budgeting, scheduling, managing risk and controlling)?
• Do standard documented guidelines and procedures exist for the acquisition of software products? (e.g. product standards, architecture requirements and constraints, etc.)
• For the software product being acquired, is transition to the software support organization planned?
• Is there a documented system integration and test process to ensure that elements will function as a whole? (This primarily involves identifying, defining, and controlling interfaces, as well as verifying system functions that require multiple system elements.)

CMM Related Questions

1. Requirements Management. Requirements Management involves establishing and maintaining an agreement with the customer on the requirements for the project. The agreement covers both the technical and non-technical (e.g. delivery dates) requirements.
   
   
   • Are requirements agreed upon by the customer, project management, and project team members?
   • Are requirements documented and available to all project team members?
   • Are changes to requirements reflected in the project's effort and cost estimates, and size of product estimates?
   • Are changes to requirements negotiated and agreed upon by the customer, project management, and project team members?
   • Are requirements traced to design components, code components, and test plans or procedures?
   • Are requirements analyzed for completeness, understandability, feasibility, and consistency?
     
     
2. Project Planning. Project Planning involves developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work.
   
   
   • Are the project activities defined and documented in a plan? (Project Plan)
   • Do procedures or guidelines exist for estimating project effort and cost, and size of work products?
   • Are the commitments of external groups documented and agreed upon by the affected groups (i.e. configuration management, documentation management, quality assurance, customer, sub-contractors)?
   • Is the project plan reviewed by the project manager, managers of other affected groups, and project team members?
   • Are project risks (cost, resource, schedule, or technical risks) identified, assessed, and documented?
   • Are the planned activities of the project based upon a defined life cycle?
   • Have facilities (i.e. office space, computer equipment) and support tools been identified and procured or developed?
     
     
3. Project Tracking and Oversight. Project Tracking and Oversight involves tracking and reviewing the accomplishments and results against documented estimates, commitments, and plans, and adjusting these plans based on the actual accomplishments and results.
   
   
   • Is the project effort, cost, and schedule tracked on a frequent basis?
   • Are sizes of work products tracked and the sizing estimates updated accordingly?
   • Are the project activities adjusted and re-planned when the project actuals are found to deviate significantly from the original project plan?
   • Are internal project reviews conducted periodically with affected groups to track progress and issues?
   • Are reviews conducted at significant milestones with the customer to review results, plans, and status?
   • Are estimated and actual data for project effort, cost, and work product sizes recorded for use in this project and future projects?
   • Are technical issues or problems identified, documented, and tracked to closure (i.e. problem reports, issues database)?
     
     
4. Subcontract Management. Subcontract Management involves selecting a contractor, establishing commitments with the contractor, and tracking and reviewing the contractor's performance and results.
   
   
   • Are subcontractor's selected based upon an evaluation of their capabilities?
   • Do documented guidelines or procedures exist for the evaluation of subcontractors?
   • Are the commitments between the prime contractor and the subcontractor documented in a contractual agreement?
   • Does the prime contractor conduct periodic technical reviews with the subcontractor to review technical material and status?
   • Does the prime contractor conduct periodic management reviews with the subcontractor to review progress and status?
   • Does the prime contractor conduct an acceptance test as part of the criteria for accepting the subcontractor's product?
   • Is the subcontractor's performance evaluated periodically and reviewed with the subcontractor?
   • Is the product acceptance criteria documented in an Acceptance Test Plan which has been agreed upon by the prime contractor and the subcontractor?
     
     
5. Quality Assurance. Quality Assurance involves reviewing and auditing the products and activities to verify that they comply with the applicable procedures and standards and providing the project and other appropriate managers with the results of these reviews and audits.
   
   
   • Does a Quality Assurance (QA) Plan, containing QA activities, responsibilities, and schedule, exist for the project?
   • Are QA activities conducted in accordance to the QA Plan?
   • Does Quality Assurance report directly to the organization's senior management?
   • Are QA activities and their findings reported to the project periodically?
   • Are QA individuals trained in quality assurance?
   • Are issues of non-compliance that cannot be resolved within the project, escalated to the level of senior management?
   • Does QA verify that the activities of the project comply with the Project Plan and the designated standards and procedures identified in the Project Plan?
   • Does QA verify that work products comply with the standards, procedures, and contractual requirements, as stipulated or referenced by the Project Plan and Statement of Work?
     
     
6. Configuration Management. Configuration Management involves identifying the configuration of the product (i.e., selected work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the project life cycle.
   
   
   • Does a Configuration Management (CM) Plan, outlining CM activities, responsibilities, and schedule, exist for the project?
   • Are CM activities conducted in accordance with the CM Plan?
   • Are project work products, supporting tools, and any software or procedures required to regenerate the work products identified and controlled?
   • Does a configuration management (CM) library system serve as a repository for the controlled items?
   • Is there an established procedure for checking items in and out of the CM library system?
   • Is there an established procedure for generating baselines from the CM library system?
   • Is information on the contents of the baselines and the status of the CM library available to the project?
   • Is there an established procedure and mechanism for controlling changes to the controlled items (i.e. Change Request Procedure)?
     
     
7. Organization Process Focus. Organization Process Focus involves developing and maintaining an understanding of the organization's and projects' processes and co-ordinating the activities to assess, develop, maintain, and improve these processes.
   
   
   • Do activities to develop standard processes and to improve these processes exist within the organization?
   • Does responsibility for defining process development and improvement exist at an organizational level, and not a project level?
   • Are the project's or organization's processes assessed, periodically, to determine process strengths and weaknesses?
   • Are Action Plans based upon the process assessment generated and implemented?
   • Does the organization have a company-wide plan for process development and improvement activities?
   • Is there an Organization Training Plan for conducting process training across the organization?
   • Does senior management provide the support, resources, and funding to enable the process improvement activities to be effective?
     
     
8. Organization Process Definition. Organization Process Definition involves developing and maintaining the organization's standard processes, along with related process assets, such as descriptions of process life cycles, process tailoring guidelines and criteria, the organization's process database, and a library of process-related documentation.
   
   
   • Does the organization have developed and documented standard processes (i.e. description of project life cycle)?
   • Does the organization encourage and promote the use of standard processes?
   • Is there a collection of process assets (e.g. process descriptions, process tailoring guidelines, coding standards, development procedures) that can be easily tailored and used by the projects?
   • Are the standard processes continually assessed and improved?
   • Are new technology, tools, and methodologies related to process being assessed and evaluated?
   • Is estimated and measured process data retained in a database for use in process improvement and in planning future projects (e.g. size estimates, effort data, productivity data, defect data)?
     
     
9. Training Program. Training Program involves first identifying the training needed by the IM/IT organization, projects, and individuals, then developing or procuring training to address the identified needs.
   
   
   • Does each project specify its technical and managerial training needs (e.g. type of training required, by whom, and when)?
   • Do the individuals on a project receive the necessary training as identified?
   • Does a Training Plan for the organization exist, specifying training needs, type of training available, funding, resources, schedules, and standards for course development?
   • Are training courses developed in-house, developed and maintained according to the organization's training plan?
   • Does the organization's training program receive the necessary support, resources, and funding from senior management to make the program effective?
   • Are measurements used to determine the quality of the training program?
     
     
10. Integrated Project Management. Integrated Project Management involves developing the project's defined project management process and managing the project using this defined process. The project's defined project management process is tailored from the organization's standard project management process to address the specific characteristics of the project.(e.g. PMBOK)
    
    
    • Does the project have defined processes that have been developed from the organization's standard processes?
    • Do the activities described in the Project Plan follow the project's defined processes?
    • Is historical data from past projects (as contained in the organization's project process database) used for project planning and estimating? (This historical data includes software size, effort, cost, schedule, productivity, and activity data.)
    • Is the project's effort, costs, and schedule managed according to a procedure?
    • Is the size of the work products managed according to a procedure?
    • Are the project's risks identified, assessed, documented, and managed according to a procedure?
      
      
11. Product Engineering. Product Engineering involves performing the engineering tasks to build and maintain the work products using the project's defined engineering process and appropriate methods and tools.(e.g. Method 1, DMR P+, etc.)
    
    
    • Is the project's defined software process supported by effective mechanisms and tools?
    • Are procedures for using the defined software process documented, and adhered to?
    • Is requirements analysis and verification conducted in accordance to the project's defined process?
    • Is the product designed in accordance to the project's defined process?
    • Is the product implemented according to the project's defined process?
    • Is the testing conducted according to the project's defined process?
    • Are the work products (i.e. outputs) of the requirements analysis, design, implementation, and test activities consistent with each other and the customer requirements?
    • Are the necessary resources (i.e. technology, skills, equipment) available to the project?
      
      
12. Inter-group Co-ordination. Inter-group Co-ordination involves the participation of other project groups (organization level versus project team member level) such as infrastructure, testing or quality assurance to address system-level requirements, objectives, and issues.
    
    
    • Are commitments between project groups agreed to by the affected groups and documented? (Commitments could be documented in the Project Plan.)
    • Are representatives from affected project groups involved in establishing the project requirements and in negotiating with the customer?
    • Does an established procedure exist for identifying, recording, tracking, and closing inter-group issues?
    • Do the project groups work together on a regular basis to monitor and co-ordinate technical activities and to resolve technical issues?
    • Is the Project Plan used to co-ordinate and track the activities of the various groups?
    • Are work products delivered to other project groups reviewed to ensure they meet the group's needs?
      
      
13. Peer Reviews. Peer Reviews involve a methodical examination of work products by the producers' peers to identify defects and areas where changes are needed
    
    
    • Is peer review of work products conducted on the project? Examples of work products suitable for review are requirement specifications, architecture, design descriptions and test plans.
    • Is the review material distributed to the reviewers prior to the meeting and with sufficient time allocated for the material to be reviewed?
    • Are defects identified during the review meeting recorded and tracked to closure?
    • Does the Project Plan or a Peer Review Plan identify the work products to undergo peer review?
    • Are peer reviews conducted in accordance with a documented procedure?
    • Are peer review checklists, which identify the criteria for the review of the product, used by the reviewer?

Appendix 2

List of Departments and Participants

The following departments have participated in the Treasury Board of Canada Secretariat exercise:

Department	Represented By
1. Agriculture and Agri-Food Canada	Marj Akerley Ray Blewett Brian Gallant Bruce Gordon Terry Harding
2. Canadian Heritage	Larry Bristowe Crayden Arcand
3. Citizenship and Immigration Canada	Christine Payant Don Hobbins
4. Correctional Service Canada	David From N.D. Funk Doug McMillan Richard Johnston
5. Environment Canada	Jim Klotz Henry Murphy Chak Lam Wong
6. Fisheries and Oceans Canada	Réjean Gravel Robert Cosh William Lowthian Dianne Symchych
7. Foreign Affairs and International Trade	Greta Bossenmaier David Lafranchise Bob Fraser
8. Health Canada	Dorene Hartling Bob Wilkinson
9. Human Resources Development Canada	Joan Delavigne Ron Ramsey Michel Gilbert
10. Indian and Northern Affairs	Serge de Bellefeuille Yves Marleau Peter Oberle
11. Industry Canada	Tom Racine Nabil Kraya Patty Pomeroy Pierrette Benois-Doris Jenny Steel Jim Westover
12. Justice Canada	Aaron Caplan Janice Hatt
13. National Defence	Barry Brock (Colonel) Wayne Harrison Bill Brittain
14. Natural Resources Canada	Yvon Claude Paul Conway Peter McLean Ken Leblanc Leslie Whitney
15. PWGSC	Dave Holdham Julia Ginley François Audet Debbie Jones
16. Revenue Canada	Darlene Bisaillon Richard Chauret Barry Ferrar Gloria Kuffner Katherine Stewart
17. Royal Canadian Mounted Police	Edward B. Cook Guy Millaire
18. Statistics Canada	Dick Gross Michael Jeays Mel Turner
19. Transport Canada	Kevin Collins Robert Lalonde
20. Veterans Affairs	Heather Parry Frances Walsh Howard Williams

Appendix 3

Results