Process Mutation Models of Agile Management Methodologies EVANGELOS MARKOPOULOS 1, JAVIER BILBAO 2, EUGENIO BRAVO 2, TODOR STOILOV 3, TANJIA E.J. VOS 4, CARLO FIGA' TALAMANCA 5, KATRIN RESCHWAMM 6 1 Department of Informatics University of Piraeus 80 Karaoli & Dimitriou Str., Piraeus GREECE epm@unipi.gr 2 Applied Mathematics Dept University of the Basque Country Alda. Urkijo s/n., Bilbao SPAIN javier.bilbao@ehu.es 3 Dept Hierarchical Systems, Institute of Computer and Communication Systems Bulgarian Academy of Sciences Acad. Bonchev str. Sofia BULGARIA todor@hsi.iccs.bas.bg 4 Information Technology Institute University of Valencia Camino de Vera s/n, Valencia SPAIN tanja@iti.upv.es 5 Technology Division ICT Area Via Giacomo Peroni 386, Roma ITALY c.talamanca@innova-eu.net 6 The Fraunhofer Institute for Factory Operation and Automation Fraunhofer IFF, ICCL Sandtorstrasse 22, Magdeburg GERMANY katrin.reschwamm@iff.fraunhofer.de Abstract:- Approaching the way an information technology project can be managed is based upon a number of parameters dealing with the project, the implementation process, the project constraints, the expected quality, and many other project needs and expectations that define successful the project management concept. All projects have the same goals, which are all related to successful implementation. This paper will introduce an approach that will utilize the project constraints and the project management dimensions based on the project goals and expectations per case. This agile like approach, will be enhanced with the concept of process mutation and methodological mutations over the evolution and the progress of the project implementation. Key-Words: - Management, Process Mutation, Agility, Process Framework 1 Introduction management methodologies have been blamed as time and budget consuming, bureaucratic processes. This is possible when the methodology, which has been selected to support the management of a specific project under specific restrictions, is not the proper one. The selection of the method, one can use to perform project management can be more complex than the project itself. Most of the well-known and widely accepted project management methodologies are either too theoretical, or too restricted to specific management views. Selecting a methodology to be used of-theshelve can be more risky than managing a project without a methodology. Standards, methods and best practices need to be adjusted to the implementation environment and project constraints in order to be successfully used. The adjustability of the project management process is based on the identification of the project and the risks associated with the project implementation process. Those risks affect significantly the project implementation environment and management methods as well [1]. The development of a project management methodology with adjustability capabilities can be achieved only if the project management dimensions and project facets are identified. Following the identification of the project environment and the characteristics of the project management stages other more complex issues need to be taken in consideration dealing the project changes that affect the organizational stability, the technical stability and other types of changes affecting the stability of the implementation process. This project environment stability can be obtained by process mutation over the project implementation progress. 2 Management s Process mutation is based on project determination an identification. A project is not identified by its subject, neither by its goals but by its overall environment and dimensions which affect both the ISBN: 978-960-6766-49-7 731 ISSN: 1790-5117
project goals, objectives and the selection of the management approaches to be followed [2]. The following four project management dimensions describe the project environment, management goals, constraints and expectations [3]. Organizational: Management by managing the project in an organizational level. Formation of steering committees; monitoring by job description and tracking by project milestones and project deliverables and documentation. Planning: Management by monitoring the plans and estimations drawn in the early phases of the project. Tracking : Management by volume; Quantitative management; Tracking on the planned activities in a demanding way following the project plan in detail, or tracking by specific guideline requirements. Engineering: Qualitative management; Management by technical quality assurance. Monitoring and supporting the engineering processes followed in the project. Technical quality control to assure that the results of the project will be the expected results at once, prior to their delivery. 3 Management Facets The project management dimensions are highly associated with the project management facets. The management practices selected to be used or being used in project management methods, vary among projects. An information technology project has many differential factors that can influence its management approach [4]. Those factors are divides in management facets. An information technology project has four prime facets; the technology, which identifies the type of the project the operational which identifies the complexity of the project; the volume, which identifies the size of the project and the methodology facet which identifies the constraints to use a methodology. The technological facet of a project can be defined by the following set TF = {algorithmic complexity, software, hardware, telecommunication, services,. etc.} the same set of elements can be defined as: TF = {te 1, te 2, te 3.te n } (te = technological element). TF i..n defines the technological elements a project may have. The operational facet of a project can be defined by the following set : OF = {budget, time, effort, data,.} the same set of elements can be defined as : OF = {oe 1,, oe 2, oe 3.oe n } (oe = constraint element), which defines the constraints elements a project may has. On the other hand, both of these project facets need to be measured against the size factor. The volume facet of a project, third one, can be defined by the following set VF = {Complex, Large, Medium, Small,.} the same set of elements can be defined as VF = {ve 1, ve 2, ve 3.ve n } (ve = volume factor). VF i,n defines the size elements a project may have. The methodological facet, of a project, which can be defined by the following set MFi= {Time for Method, Experience on a Method, Budget for Method, Complexity of Method, Experience on Method, } the same set of elements can be defined as MF = {me1, me2, me3.men} (me = methodological element), VF i,n defines project constraints on methodological elements. If complex software, for example, needs to be developed under custom requirements in a tight schedule then it is obvious that time for using a project management methodology is not much left. Likewise as software needs to be developed by technical wizards then it is very difficult to use a project management methodology to those who never worked in a controlled environment [5]. Figure 1 presents the relationship of the project management facet elements on the project management dimension, affecting significantly the project management approach that will be selected. e1 fv Volume Facet e2 do Organizat. e3 e4 e5 de Engineer. fo Operationa l Facet e6 dp Planning dt Tracking Fig. 1. management facets and dimensions relationship. Identifying a methodology that can satisfy all the constraints of a project is so impossible as is to find a project with all of these constraints. Successful project management is based on a combination of engineering and managerial processes and tasks [6], [7] and the adjustment of the process around the project constraints and definition. e7 e8 e9 e10 e13 e15 e16 e14 fm Methodolo gy Facet ft Technology Facet e11 e12 ISBN: 978-960-6766-49-7 732 ISSN: 1790-5117
This process adjustment can be considered as a project by itself, since the selection of a methodology, which can be used towards managing a project, needs not to be restricted to a single methodology. If a project has many implementation and management constraints, then more than one methodology can be used to support its management effort. 4 The need for process changes Dynamic organizational environments are continuously changed, and the project management processes on theses environments shall be adjusted to theses changes. The adjustment of the project management processes is based on the freedom and capability of the project management methodology used [1]. Today, agile methodologies allow some type of process change based within the logic, objectives and processes of the methodology. The capability to integrate methodologies in order to successfully approach a project goal or objective can be very risky but also necessary. As project management facets and dimensions change over the project implementation period there is also a need for changes in the methods and practices used to manage the implementation process of the project. This need can be viewed as process mutation, where processes are evolved form different methodological approaches into one management model using different processes from different methodologies on different project management phases and stages. 5 The concept of Process Mutation The notion of mutation was always as a means of interpreting, and sometimes misinterpreting complex information technology problems. The Formal Transformation Model [8], for example, does nothing more than restraining a project s development to a finite set of technical stages, and reapplying them, thus gradually forming the final outcome, through a so called transformation. The Evolutionary Development Model [9] functions similarly; it also breaks a project down to numerous subprojects, the latter being defined by specific development phases, and managing each subprojects individually. According to the previously mentioned examples, the implementation of a project can be evolved through its implementation stages differently. This project process evolution can be characterized as an implementation process mutation on the project implementation phases and constraints. 6 Appling process mutation on the systems development life cycle It is commonly use to define the planning activities for the implementation of a project as the first project implementation phase. When a project is in the phase of planning, then several methodologies, such as the SDPP, RDPP, COCOMO, Function Points of Analysis, 5 Step and others which base the management primary one the planning concept, could be possible used alone or in conjunction with other methodologies such as the PROMPT, PRINCE, PRODIGY, SUPRA, etc, which base the management primarily on the project organization concept. The combination of such a methodological approach in the project planning phase could be an ideal one, preparing the project to move into more technical phase where other type of methodologies could possible take over the project management support. A possible project implementation phase following the project planning phase could be the project implementation estimation phase, where the input of the planning phase is used to identify quantitative and qualitative implementation and management goals and targets. Possible methodologies that could be used in this phase could be the SCALABLE, TENSTEP, BPMM, RDPP, SDPP, Ariadne-PM, IPM and other, specialized on project implementation estimation. After the project planning and implementation estimation phases the project moves in to the more technical and engineering phases which manages the actual realization of the project requirements and development of the project deliverables. Those implementation phases which can be the requirements management, systems analysis, systems design, coding, parameterization, system testing, system integration, system documentation and others can be very well supported by technically oriented management methodologies such as I.E., LCM-AIS, DοD-STD-2167A, SEFER, WWPMM, DSDM, SDLC, AIM, ITPM, and other. Over the years different methodological approaches have been developed in order to solve one part or hopefully the entire management process in the implementation of an information technology project [10]. Unfortunately the crisis in information systems project management, and even more in software project management was, is and seems that will still be [11]. The integration of processes deriving from different methodologies not only in specific project phases, but even in specific activities within a ISBN: 978-960-6766-49-7 733 ISSN: 1790-5117
specific project phase can significantly support the management effort. This process selection, per case can be considered as an activity with surgical sensitivity on selected project needs and constraints. On the other hand the determination of the selected processes form specific methodologies for specific project activities can not be predefined since the determination of the way the environment of the project will change or react on different types of changes can not be predicted. The project management processes will be mutated based on the behavior or the project environment and the project progress. This mutation will the one that will realize the needs for specific processes on specific project implementation activities. 7 Systems development and systems acquisition process mutation An information technology project does not need to be a systems implementation project specifically. Information technology projects can also be the systems acquisition projects, where organizations purchase technologies instead of developing them [12]. The management of the acquisition process can also be supported by many methodologies such as SA-CMM, Ariadne-PM, ITIL, ITPM, WWPMM, and others based on the acquisition phases, goals, and other project constraints [13]. The total project implementation or project acquisition phases could possibly be represented by a mutational information technology project management model, where each stage and even more each stage activity could be supported by a specific management technique, method or approach (figure 1). On the other hand it is widely accepted that each project must follow a specific project management method in order to assure consistency on its development management and also maintenance effort [14]. Unfortunately no methodology can be considered as the silver bullet or the one that can successfully support all management goals and objectives under all project constraints. It is clear that a methodology besides the need to be readjusted on the environment of each project, and not only to the goals and objectives of each project, must also be readjusted to the needs and objectives of each implementation phase on each project. In such project management process transformation need the mutational project management concept can be complementary on the agile project management concept since both are based on the readjustment of the management processes on the project needs affected by the project s environment[15]. The difference between project process transformation and project process mutation is that the agility of the process transformation, which is the adjustment of the processes, is replaced with the agility of the process mutation which is the replacement of the process with other more suitable process in order to meet the specific process goals and objectives per case and per instance. Stage Planning Stage Development Process I.E., LCM-AIS, DοD-STD- 2167A Identification Stage Acquisition Process SΑ-CMM, ITIL, ITPM, WWPMM Planning PROMPT, PRINCE, PRODIGY, etc need formalization SDPP, RDPP, COCOMO, FPA, etc. Fig. 2. Methodological approaches per project phase 8 Results Uselessly and long lasting project management processes need to be mutated on the changes of the project environment. Unlike process transformation, the process mutation is based on processes changes which incorporate processes form the project management methodologies used and other project management methodologies that could be use in order to manage a specific project task or achieve a specific goal. Process mutation is not restricted to processes existing in a project management methodology, or the transformation of the processes with the project management methodology. The process mutation has not limits, rules or conditions, and gets adjusted and readjusted to the project evolution and progress. References: [1] Keil M., A Framework for Identifying Software Risks, CACM vol.41, no.11, November 1998, pp 76-83. [2] Markopoulos E., Panayiotopoulos J-C., A Management Methodology Selection ISBN: 978-960-6766-49-7 734 ISSN: 1790-5117
Approach based on Practical and Organizational Constraints, WSEAS Transactions on Computers, Issue 8, Vol 4, pp 934-942, August 2005. [3] Reel, J.S, Critical Success Factors in Software s, IEEE Software, May 1999, pp.106-113 [4] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981 [5] Humphrey W., Managing The Software Process, Addison Wesley, 1989. [6] Roetzheim W., Structured Computer Management, Prentice Hall, 1988 [7] Hoffmann H., and Geiger J., Quality Management in Action: a Swiss case study, Vol. 15, No.1, pp. 35-53, 1995. [8] Pressman, R., and Ince D., Software Engineering. A practitioner s approach. European Adaptation Fifth Edition, McGraw Hill, 2000 [9] Markopoulos E., Kaminaris S., Adapting Quality Assurance on the Software Development Cycle. Proceedings of the 3rd Middle East Quality Forum. Nicosia, Cyprus June 27-30 2000 [10] Metagroup, IT Performance Trends 1999, Rubin Systems Inc, 1999 [11] Glass, R., Is there really a software crisis, IEEE Software, vol. 15, no. 1, January 1998, pp.104-105. [12] Markopoulos E., Panayiotopoulos J-C., Managing Information Technology Systems Acquisition s, WSEAS Transactions on Communications, Issue 9, Vol 5, pp 1823-1831, September 2006 [13] NASA., NASA Software Acquisition Life Cycle, NASA Office of Safety, Reliability, Maintainability and Quality Assurance, Washington D.C. 229-1988. [14] Markopoulos E., Panayiotopoulos J-C., An Evaluation, Correlation and Consolidation of Information Technology Management Processes, Proceedings of the 2006 International Conference on Engineering and Mathematics, July 10-11, 2006, Bilbao, Spain. [15] Ambler S., Agile Modeling John Wiley & Sons 2001 ISBN: 978-960-6766-49-7 735 ISSN: 1790-5117