an information systems acquisition management framework · an information systems acquisition...

An Information Systems Acquisition Management Framework

EVANGELOS MARKOPOULOS Department of Informatics

University of Piraeus 80 Karaoli & Dimitriou Str., Piraeus

GREECE

JOHN-CHRIS PANAYIOTOPOULOS

Department of Informatics University of Piraeus

80 Karaoli & Demetriou Str., Piraeus GREECE

Abstract:- Each participant in a project has a different point of view on what is successful project management and how it shall be accomplished. This paper takes into consideration the prime processes of 43 methodologies used mainly for information technology project management and creates a methodological framework for managing the an information technology project primarily from the user (customer) perspective. The framework is supported by best practices, and has been designed in such a way that captures all project management activities before, during and after the implementation of a project in an adjustable manner. The structure of this framework allows the management of any type size, and complexity projects. Key-Words: - Systems Acquisition, Project Management, Methodologies, Process Framework 1. Introduction Project management and software project management in particular is primarily based on understanding the nature, scope and goals of the project in order to perform the proper allocation of resources needed towards its successful implementation [1]. A very important but trivial management principle is the definition of success. Resource allocation, management effort [2], managing technical people [3], requirements elicitation and tracking [4], acceptance criteria definition [McGrew], and performance measurement [5] can be considered as differential factors towards defining project success under the spectrum of project control, which is [6], and always was [7], the project management success definition. Controlling a project successfully is to ensure the minimum surprises along the way [8]. The whole concept of project management is based on a number of activities, operating as satellites to the project implementation process. Requirements management, change management, quality assurance, risk management and other managerial activities can not be categorized in a staged

interpretation [9], [10], [11], since they can be applied on the entire project implementation process. 2. Project Management Conceptions All organizations today that can be considered as Software and/or Technology Intensive Organizations[12], can be roughly placed in two categories. The ones developing systems and the ones acquiring systems. The first category of organizations cover the ones which have internal software development or systems development teams that either produce IT products, services, applications and systems which support their operations and functionality. Software houses, telecommunication organizations and systems integrators are top of the list in this category. On the other hand, financial institutions and governmental authorities (public companies or agencies) which have structured systems development departments or even business units, could also be part of this category. Organizations in this first category usually perform project management by following systems

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp614-619)

engineering models [13], [14], [15]. They have a systems development methodology, composed of the major systems development phases in a development life cycle model. Project management to those organizations is primarily the proper execution of the development phases and the system’s life-cycle model in general, within budget, schedule and quality, which is measured primarily by implementation performance and compliance to the requirements. Software and or Systems Engineering form the basis of this type of project management [16],[17]. The second category covers all the other organizations excluded from the first one. The organizations in this category do not have the maturity, capability and needs above all, to develop their own information technology systems. Such organizations derive mainly from the industry and the service sectors, supported by either small internal IT departments or external consultants. These organizations acquire technology instead of creating it. The primary goal of these organizations is to receive / accept a system that will function according to their needs within a predefined budget and schedule. Project management for those organizations is directed towards managing the tender process through which the vendor is selected, managing the signed contract, managing the deliverables of the project and actually managing time and material related to project cost and schedule. Software and or Systems Acquisition form the project management basis [18].[19] for this second category of organizations. This engineering-acquisition relationship defines a project management concept for all types of organizations. 3. A Project Management Framework for System Acquisition An Information Systems Acquisition Management Framework (ISAMF) has been developed by taking into consideration the practical need for a project management approach to be used by all types of organizations. In order to develop ISAMF, a detailed analysis of 43 project managing methodologies, guidelines, and frameworks, has been conducted towards the identification of the commonly used practices in project management, systems acquisition and software engineering under different goals and dimensions. The goal of ISAMF is to be used mainly be the software intensive small to medium size enterprises

which rely primarily on tracking the acquisition processes than inspecting the engineering ones. Thus the whole concept of ISAMF is based on the requirements and contract management process which are heavily applied throughout the entire project management effort. 4. Phases in the Information Systems Acquisition Management Framework The structure of ISAMF is composed of fifteen (15) phases. Table 1 presents this basic set of phases that can form this project management framework. The first column indicates the generic name of each phase, the second column indicates the methodologies supporting this phase generic name, and the third column indicates other methodologies that support the name of the phase but with slight naming and activities deviations.

Phase Name Methods

Supporting Methods Supporting Relations

Scope. SDLC, IPM, SCALABLE, TENSTEP

LFA, 5STEP, SEFER, LCM-AIS, WWPMM, AUSGuidelines

Requirements management

AIM, SW-CMM, SE-CMM, ISO9000-3, DoD2167A, DSDM

PROMPT, Ariadne-SD, LFA, AIM, NATO-CALS, SA-CMM

Project Proposal

CBAM, SEFER Ariadne-PM

Project Planning

SDLC, ITIL, ITPM, SW-CMM, CBAM, IE

DoD2168, ISO9000-3, LFA, Ariadne-PM, SE-CMM

Plans for resources and technical issues.

PRINCE, PRODIGY, SUPRA, SCALABLE

SDLC, SDPP, RDPP, SUPRA, 5STEP, AIS

Management structure.

PRINCE, PRODIGY

SUPRA, 5STEP, AIS

Contract Tracking and Oversight Evaluation

SA-CMM WWPMM, Ariadne-PM, AUSGuidelines

Software project tracking and oversight

WWPMM, SW-CMM,

SUPRA, ITPM, SDLC, DoD2167A, DoD2168, ISO9000-3, CBAM, Ariadne-PM, AUSGuidelines, SE-CMM

Deliverables management

WWPMM, PRINCE,

IDEAL, MITP, ITPM, Princeton


PRODIGY, EUROMETHOD

Quality Assurance

WWPMM, PRODIGY, SUPRA, IPM, SCALABLE, TENSTEP, ITPM, ITIL, SW-CMM, ISO9000-3

AUSGuidelines, DoD2168, Ariadne-PM, SE-CMM

Change management.

WWPMM, ISO9000-3, DSDM, AIS

Ariadne-PM

Risk management

WWPMM, IPM, SCALABLE, TENSTEP, EUROMETHOD, ITPM, SE-CMM

CBAM, AUSGuidelines, Ariadne-PM

Transition & Support

SDLC, AIM, IPM, ASAP

SA-CMM, LCM-AIS

Acceptance ISO9000-3 Ariadne-SD Post-Implementation Review/Evaluation Phase

ITPC AUSGuidelines

Table 1. Phases composing the Information Systems Acquisition Management Framework

The methodologies listed in the second column of table 1, support the phases listed in the first column in a very precise way. Most of the phase activities are quite relevant between the definitions and goals in all methods. Unlike the second column, the methodologies listed in the third column support conceptually the related phases from a different perception. The activities, for example, of the ‘Quality Assurance’ phase can be more or less found in other related methodologies which do not refer to them as ‘Quality Assurance’, but as ‘Quality System’, ‘Quality Management’, ‘Software Quality Program Implementation’, or even ‘Standards Management’. All these different versions of the ‘Quality Assurance’ phase have the same goal and scope of what a Quality Assurance phase covers in both activities and deliverables. Another more ‘theoretical’ phase, like the ‘Scope’ of the project, which is referred in the supporting methodologies as ‘Concept Phase’, ‘Project Definition’, ‘Goals’, or even ‘Objective Analysis’. In a similar way, the ‘Contract Tracking and Oversight Evaluation’ phase has been referred by the supporting methodologies as ‘Managing Contractors’, ‘Contract Management’, or ever ‘Sponsor agreement management’.

5. Information Systems Acquisition Management Framework phases description and dependencies Table 2 describes the phases of the Project Management Framework for System Acquisition, while indicating the dependencies among them.

Phase Description Dependent

Phase Dependenc

y Type Scope. Identification of

project scope, stakeholders, adjacent systems and acceptance criteria.

Requirements Management

-


Requirements elicitation, analysis, and management through the development process.

Scope Partial Finish to Start

Project Proposal

Creation of the Request of Proposal and management / evaluation of the proposals.

Requirement Management

Finish to Start

Project Planning

Project actual decomposition, planning, estimating and scheduling on resources, effort, budget and quality.

Project Proposal Requirement Management

Finish to Start Partial Finish to Start

Plans for resources and technical issues.

Human resource management at all project levels and hierarchies.

Project Planning

Finish to Start


Establishing and following a management structure based on organizational and workflow corporate models.

Plans for resources Project Planning

Partial Finish to Start Finish to Start


Contract management through the develop. process based on the proposed & contractual vendor obligations.

All Management Phases

Start to Start


Monitoring the development process based on inspection and


Start to Start


reviews. Deliverables management

Management of all contractual and non-contractual documents produced by the projects engineering and management methodology.


Start to Start

Quality Assurance

Monitoring the compliance to the quality plan through the implementation of the defined quality standards.


Start to Start

Change management.

Documentation, Implementation, scheduling, monitoring and impact analysis of systems changes.


Start to Start

Risk management

Identification of technical and non-technical risks in systems implementation and maintenance.


Start to Start


Monitoring and supporting the transition process (migration) to the new system.

Testing Phase of the Development model

Finish to Start/Partial Finish to Start

Acceptance System acceptance. End of project


Finish to Start

Post-Implementation Review/Evaluation Phase

Project evaluation based on the systems performance and implementation metrics.

Acceptance Finish to Start

Table 2. Phase Dependencies of the Project Management Framework for System Acquisition From the dependencies of the phases included in this project management methodological framework it can be noted that the entire framework is based on reviews and inspections towards the management of the system’s quality via requirements management. Figure 2 presents the relationships and dependencies of the phases composing this framework.

Figure 2. Process model of the Information Systems Acquisition Management Framework. It must be noted that figure 2 indicates only a few start-to-finish dependencies. This is due to the fact, that most project management activities performed by the customer, can be applied in the entire project management sphere not depending from other activities. For example, project tracking, risk management, quality assurance, change management, deliverables management, contract tracking and other phases have activities not restricted to a specific period of time during the system’s implementation.

6. System Acquisition Framework Milestones and Prime Deliverables The project management framework for system acquisition is supported by a minimum set of milestones, listed in table 3, whose implementation indicates its proper usage. It can be noted that the prime deliverables in this framework are not closely related to the phase’s milestones, since this framework depends on reviews and inspections that produce reports instead of documents.

Phase Milestone Prime

Deliverables (Documents)

Scope Requirements management

Project Proposal

Project Planning

Plans for resourcing Management

structure

Contract Tracking and Oversight EvaluationProject tracking and oversight

Deliverables management Quality Assurance Change management

Risk management

Post-Impeme-ntation Eval.

Acceptance Transition &

Support

End of Project Implementation

Beginning of Project Implementation


Scope Stakeholders identification.

Basic System Functionality.

Acceptance criteria

System Scope Document.


Requirements Elicitation.

Requirements Acceptance.

Requirements Document.

Project Proposal

Creation of Request for Proposal.

RFP Dissemination. Tender Evaluation.

Request for Proposal.

Tender Evaluat. Document.

Project Planning

Decomposition Acceptance.

Estimations Acceptance

Project Plan.

Plans for resourcing and technical issues.

HR team definition. HR management model.

HR management model.


Identification of management workflow

Management procedures.

Management staffing.

Management structure document.


Contract updates (if needed).

Contract observance document.


Tracking Plan. Implementation of Reviews and Inspections.

Tracking Plan Document.

Progress Reports

Deliverables management

Deliverable inspection. Deliverable acceptance.

Deliverable acceptance document.

Quality Assurance

Standards definition. Quality Plan. Quality Reviews. Quality Re-Inspections.

Quality Plan. Quality observance document.

Change management.

Accept change. Test change implementat.

Change document. log.

Risk management

Risk Acceptance. Risk Plan. Risk Implementation.

Risk Document.

Risk implement. document.


Transition environment identification.

Transition data identific.

Transition procedures ident.

Transition Acceptance.

Transition Plan.

Transition Log.

Acceptance Acceptance Test. Acceptance test plan.

Post-Implementation Review/Evaluation Phase

Metrics Evaluation. Know-How Documentation.

Upgrade plan.

Metrics document.

Upgrade plan document.

Table 3. Phase Milestones and Deliverables of the Project Management Framework for System Acquisition 7. Advantages and Disadvantages for Using the Information Systems Acquisition Management Framework The ISAMF has been developed though an analysis and integration of the best management practices from 43 project management methodologies. This background can be considered an advantage towards using the frameworks since it encloses trends and best practices from the international project management community. Another advantage can be considered the fact that the framework excludes the engineering practices from the management effort, which could only be understood by engineers, and focuses on the requirements and contract management concepts which have be considered critical to the success of a project [20],[21]. Advantages and disadvantages are fuzzy considerations. Disadvantages of this management framework can be considered its advantages. The fact probably that the framework is build based on international best practices might not provide flexibility to be used by small organizations. On the other hand the fact that the framework has excluded the engineering practices from the management ones well can be considered as an incomplete or insufficient framework to cover the entire concept of a project (acquisition and implementation management). A long list with advantages and disadvantages can be easily generated from an academic point of view, with all of them to be substantially valid and contradictory at the same time. This framework was developed not to be evaluated as a best practice or silver bullet on systems acquisition management. It has been developed to serve as a tool to the majority of software intensive organizations that have no luxury to study, evaluate, analyze, adjust or even compose well defined process frameworks.


8. Results The Information Systems Acquisition Management Framework, as presented in this paper can be considered a ready-to-use, practical and well documented approach towards project management and specifically towards acquisition management which is a hyper-set of project management activities for almost all organizations obtaining technology, and investing in its proper usage. Despite the fact that the framework is composed from the best practices in project management internationally, a significant result is the differentiation from the engineering project management which is targeted mainly to the suppliers and a group of customers with high technological maturity. Another result is the breakdown of the framework into three process groups. The processes during the planning and the acquisition of the technology, the management of the project implementation and the post completion processes. This process categorization created a clear distinction among the project management activities, and encourages each manager to enhance the group of process that seems to be more close to the project management goals of each project. Once the acquisition and management goals have been identified, the project can successfully be implemented. Organizations suffer not because they cannot solve their problems, but simply because they cannot identify them [22] References: [1] Pressman, R., and Ince D., ‘Software

Engineering. A practitioner’s approach. European Adaptation’ Fifth Edition, McGraw Hill, 2000

[2] Zahniser, R., ‘Timeboxing for To Team Performance’, Software Development, March 1994, pp. 35-38

[3] Curtis, B. et al, ‘People Management Capability Maturity Model’, Software Engineering Institute, Pittsburgh, PA, 1994

[4] Holttzblatt k., and Carmel E., ‘Requirements Gathering: The human factor’, a special issue of CACM, vol. 38, no. 5, May 1995

[5] Olve N-G,. Roy J., and Wetter M., ‘Performance Drivers: A practical guide to using the Balanced Scorecard’, John Wiley, 1999

[6] Reel, J.S, ‘Critical Success Factors in Software Projects’, IEEE Software, May 1999, pp.106-113

[7] Putnam, L., Fitzsmmons, A., ‘Estimating Software Costs’, Datamation, vol 25, No, September 1979, pp 89-98

[8] De Marco T., ‘Controlling Software Projects’, Yourdon Press, 1982

[9] Keil M., ‘A Framework for Identifying Software Project Risks’, CACM vol.41, no.11, November 1998, pp 76-83.

[10] Bach J., ‘The highs and lows of change control’, Computer vol. 31, no. 8, August 199, pp.113-115

[11] Dewhurst E., ‘Total quality management and information technologies: an exploration of the issue’, International Journal of Quality and Reliability Management, vol. 16, no. 4, pp. 329-405, 1999

[12] Markopoulos E., ‘An Empirical Adjustable Software Process Assessment Model for Software Intensive Small and Medium Size Enterprises’, 7th European Conference on Software Quality, Conference Notes, Finland, pp16-19, 2002

[13] Royce W. W., ‘Managing the Development of Large Software Systems’, Proceedngs of IEEE WESCON, pp 1-9, 1970

[14] Boehm B., ‘A Spiral Model of Software Development and Enhancement’, IEEE Computer, vol. 21, no. 5, May 1988 pp 61-72

[15] Davis A., and Sitaram P., ‘A Concurrent Process Model for Software Development’, Software Engineering Notes, ACM Press, vol. 19, no. 2, Aprl 1994, pp. 38-51

[16] Humphrey W., ‘Managing The Software Process’, Addison Wesley, 1989

[17] SEI., ‘SE-CMM’, Technical Report, SECMM-95-01, CMU/SEI-95-MM-003, 1995

[18] SEI., ‘SA-CMM’, Technical Report, CMU/SEI-99-TR-002, ESC-TR-99-002, 1999

[19] NASA., ‘NASA Software Acquisition Life Cycle’, NASA Office of Safety, Reliability, Maintainability and Quality Assurance, Washington D.C. 229-1988.

[20] ISO/IEC 12207:1995, ‘Information Technology-Software life cycle processes – Amendment 1’, 2002

[21] ISO/IEC 15504, ‘Draft Standard for Software Process Assessment’, 1997.

[22] Gartner, J. ‘Renewal of Organizations.’, 20th Annual Meeting of the Board of Trustees, Midwest Research Institute, Kansas City, MO. May 3, 1965
