Complex IT Projects in Education: the Challenge

International Journal of Computer Science Research and Application INTERNATIONAL 2012, Vol. 02, Issue. 01 (Special Issue), pp. 115-125 JOURNAL OF ISSN 2012-9564 (Print) COMPUTER SCIENCE ISSN 2012-9572 (Online) RESEARCH AND APPLICATION © Author Names. Authors retain all rights. www.ijcsra.org IJCSRA has been granted the right to publish and share, Creative Commons 3.0

Complex IT Projects in Education: The Challenge

Stefan Morcov 1

1 SIVECO Romania SA E-mail: [email protected] 0040 722 458 953

Abstract

Complexity is a new concept in project management that becomes more and more important when dealing with today’s projects. The term “complexity” in project management moved from the status of attribute to the status of discipline. IT projects display even more traits of complexity due to the new technologies involved and to the traits of innovation and unpredictability associated with them. A n IT project in education is primarily an education project, and typical project and software models and metrics are not applicable as such, which raises the complexity of IT projects in education to an even higher level. The project management theories have starting to evolve since the late 1990s to incorporate a dimension of complexity. Still, these are not fully integrated. And especially in education, the development o f a framework methodology for the setup and management of complex projects is required in order to tackle with the complexities of combining the intrinsic complexity of IT projects, the education aspects and the risks introduced by the wide range of stakeh olders involved in major education transformations.

Keywords : eLearning; Education; Complex projects; Project Management; Education Management

1. Introduction

The rapid development within society of the use of information and communication technologies has meant a revolution in the way schools and training institutions work, following the general trend of the whole society. Not only academic institutions apply IT tools in the management of their day-to-day activity, but the eLearning 2.0 paradigm involves the implementation of virtual collaboration and communication learning environments based on web 2.0 tools, including delivery of multimedia-rich simulations and experiments for a personalized curricula. In the same time, education poses a significant amount of issues related to adoption and impact. Because an IT project in education is primarily an education project, and typical project and software models and metrics are not applicable as such. The term “complexity” in project management moved from the status of attribute to the status of discipline. Complexity does not necessarily relate to size, but it relates to interdependencies and interactions between the project’s components, between the project and external factors. A complex project is described by nonlinearity, complex feedback loops and significant impact of small factors (Lorenz's butterfly effect). The project management theories have starting to evolve since the late 1990s to incorporate a dimension of complexity. Still, these are not fully integrated. And especially in education, the development of a framework methodology for the setup and management of complex projects is required in order to tackle with the complexities of combining the intrinsic complexity of IT projects, the education aspects and the risks introduced by the wide range of stakeholders involved in major education transformations. The paper makes a summary of evolutions in the discipline of complex IT project management. It also describes the special issues related to the management of complex IT projects in education, based on practical 116 International Journal of Computer Science Research and Application, 2(1):115-125

project examples. Finally, the paper underlines key areas of research required to formally define complexity in project management, to practically measure complexity and to advance towards a formalisation of project management practices and methodologies required for dealing with such projects.

2. The intrinsic complexity of IT projects

Software projects still are, after tens of years of experience and research, difficult to estimate, plan, execute and evaluate, especially with regard to impact. The industry lacks a practical definition of complexity as regards project management (Whitty & Maylor, 2009) (Williams T. , 1999) (Whitty & Maylor, Feb 2007) (Vidal, Marle, & Bocquet, 2011). The existing definitions are vague and non-measurable, which reduces the evaluation to a single method: “expert-judgment”). The execution of a (complex) project remains defined by a combination of personal skills, experience and formal methods – where formal methods remain difficult to adapt to specific organizations and projects, and their usage is still extremely rare in practice, in organizations of all sizes. The project manager continues to search for the right question rather than for the right answer, and to use methodologies for organizing his own ideas rather than follow them. In the same time, a practical but systematic approach should give the project manager a framework in which he/she should be able to construct, organize and manage his project in a more structured fashion.

3. Education of the future – technology enhanced education

Education and training are the keys to success in the current global information society. To succeed in today's environment, new skills must be developed that will continue to respond to changes; these skills depend on the ability of employees to think critically, to solve problems and anticipate new opportunities. The rapid development within society of the use of information and communication technologies has meant a revolution in the way schools and training institutions work, following the general trend of the whole European society (Commission of the European Communities, 2001). The key components defined in 2001 were equipping the schools, training of the teachers, networking and resources. The strategic focus demanded creating a theoretical, psychological and pedagogical framework for the integrating of ICT resources in education. In the same time, a strategic approach to their implementation was required. Throughout history, education and training, as engines of development in any society but also mirroring their environment, in all its forms – formal, continuous, vocational, has adopted naturally the technological evolution. Higher education has influenced and even provided leadership for the technological advance of our society. Lower levels of education have always been lagging behind, with technology adoption rates lower than the society itself. This is currently expressed in the slower adoption of Internet connectivity, IT resources for education (such as multimedia educational content or eLearning platforms) and ITC resources in management. More than this, information technology has a higher degree of development than teaching. The basic education model throughout the world is still following industrialist principles and is only recently being influenced and slightly changed by the less recent theories of (Piaget & Inhelder, 1969) - social constructivism, Vîgotski - social constructivism, Bloom-Anderson - taxonomies of learning objectives or (Gardner, 1983) - multiple intelligences; as facilitated by the introduction of new educational resources – the computer, the Internet. We are facing a change comparable to the introduction of paper and printed books in schools (Jugureanu R. , 2010). Introducing IT in the basic education systems of the world is a strategic, political priority on all continents. From strategic formulation, this priority translates into complex technical problems of implementing mass- projects, with wide geographical coverage, and with tight deadlines. The national programs of introducing IT in education were pioneered approx. 10-15 years ago, initially in highly-developed countries (US, Britain, France) and did not reach a significant coverage until recently. As all pioneering projects, the failure rates were incredibly high for the initial projects and their impact on education was irrelevant, but the literature is rarely quoting failures – both for political reasons, as huge amounts were invested, as well as from practical measurement difficulties as described hereafter. One difficulty is time-span: the results of a project implemented on a large scale in an education system can only be measured after years, and the results on the society itself may be fully perceived only after one generation. This is a perfect application of the popular culture principle that “The impact of Technology is often overestimated in the short-term and underestimated in the long-term”. ICT resources in education are changing slowly the way we learn today, but change dramatically the way society will function tomorrow. 117 International Journal of Computer Science Research and Application, 2(1):115-125

Another difficulty is establishing the targets, as the success indicators vary widely from project to project; from mere quantitative metrics related to provided resources (such as number of computers), to more elaborated usage rates of the provided resources and satisfaction-surveys, and very rarely to impact on pedagogical results (ISTRATE, 2009). It is obviously difficult to measure the success of a project when the business concept itself evolved dramatically over the last 10 years. eLearning was described 10 years ago as delivering text on a computer or over the Internet, using web or email, typically as a faster replacement for regular mail in distance learning programs. Currently we are talking about an eLearning 2.0 concept (Karrer, 2006) (Downes, 2005) which uses virtual collaboration and communication environments based on web 2.0 tools, including delivery of multimedia-rich simulations and experiments through highly personalized curricula, facilitating project-based learning models and collaborative web-based learning environments. Not including the various sub-categories and sub-types of eLearning that evolved: CBT/CBL (usually self-paced, asynchronous), CAT/CAL (usually instructor-led, synchronous or asynchronous), WBT/WBL etc. And this is all only one of the aspects of the IT projects in education – the pedagogical area. The other major area is the management at all levels – classroom, school, district, region or country, focusing on automating administrative processes, managing resources (human, material and virtual), managing time, examinations, paper-work, projects and funding. We are no longer implementing eLearning projects – we are implementing integrated eEducation projects covering both pedagogical aspects as well as administrative aspects; management of teaching and learning; management of examinations; collaboration and communication within the physical school and outside; decision-making at all levels.

4. Complex Projects – The Underlying Challenge

The project, as the base brick of the researched topic, has been rigorously defined by practitioners and research. The project is a concept sufficiently understood and easy to recognize. The most common definition defines the project as a temporary (time-delimited) endeavor undertaken to create a unique product or service (Project Management Institute, 2003). Each of these characteristics are easily measurable: temporality and uniqueness. According to (Vidal, Marle, & Bocquet, 2011), “a project is a temporary and unique endeavour undertaken to deliver a result. This result is always a change in the organization, whatever it is in its processes, performance, products or services. Each project is unique because there is always at least one of the following parameters that changes: targets, resources and environment”. More abstract definitions following the same line of thought are given by (Cova & Salle, 1992): “a one shot approach, to scan, bid and negotiate”. But this is operationalized the same way: own goals, low frequency, predetermined time and resource limitations. Some papers derive from the characteristic of uniqueness of a project to also include innovation as a trait (Vaaland & Håkansson). Projects have always been faced with problems in managing duration, costs, in measuring progress and managing quality. In 1995, in a highly controversial report, Standish group reported that 31.1% of projects were cancelled before completion, 52.7% of projects cost 189% of their original estimates and only 16.2% of software projects were completed on-time and on-budget. Regardless of the controversy surrounding Standish’s research methods and exact numbers, these reflect a state of mind and fact in IT, that was initially observed in the 1930’s and is still obvious, and which is popularly expressed through a significant set of software paradoxes: the Mongolian horde concept, the 1st law of cycling, the LOC paradox. Experience shows that if a rolled-out IT system has no problems, than nobody is using it, and if a testing team finds no bugs then they are simply not testing. “A program that is used in a real-world environment necessarily must change” (Belady & Lehman, 1985). The problems related to IT projects are increasingly important as projects become more and more large and complex. The cowboy programming or hero programming paradigms, which were the rule between 30 and 10 years ago, are becoming more and more exceptional situations, as modern IT projects require an army of experts specialized in niche domains: graphic designers, software architects, system architects, networking and communication experts, security experts, system analysts and designers, system administrators, functional administrators, technical leaders, project managers and project coordinators, ergonomists, QA, QC, business- domain experts, trainers, technical support experts, database designers, and – yes - programmers. Most definitions of complexity in project management derive from the complexity theories, which itself is not fully understood or defined. According to (Morel & Ramanujam, 1999), there is no universally accepted definition of complexity; it can be understood differently not only in different fields, also within the same field. (Saynisch, 2010) states that the theory of complexity itself is currently being defined, and is moving from a 118 International Journal of Computer Science Research and Application, 2(1):115-125

characteristic to a science”. (Calinescu, Efstathiou, Schirn, & Bermejo, 1998) conclude that “there is a high diversity of opinions on what complexity is, why it should be measured and how this can be done”. The definition of (Edmonds, 1999) refers to both causes and effects; complexity is thus the property that makes it difficult to formulate its behaviour. The traditional line of thought in defining complex projects was based on size. According to this approach, a complex project was a project difficult or complicated because of high risk or involvement of a multitude of management and technical factors (Whitty & Maylor, 2009). This description refers to a structural complexity. In the same time, according to this definition, one can easily reduce a complex project to a set of simple smaller projects, by using simple decomposition methods. This type of “complex project” is thereafter manageable by traditional methods – the challenge is reduced to managing several (even many) simple, smaller projects. This leads to the conclusion that 2 non-interdependent simple projects, or 100 non-interdependent simple projects, if added, still make a simple project – a bigger but simple project. The keyword here being… non-interdependency. Complex projects are better defined in the sense of complex systems, using the definition of complexity from natural and social sciences, where the term is used to describe systems that consist of several interacting parts. Complex systems are defined by nonlinearity, continuous interactions with their environment and complex feedback loops (Cooke-Davies, Cicmil, Crawford, & Richardson, 2007). They also display emergent behaviour and significant changes provoked by small factors (the butterfly effect (Lorenz, 1963): does the flap of a butterfly's wings in Brazil set off a tornado in Texas?). The complex project was thereafter defined as consisting of many varied interrelated parts (Baccarini, 1996). A complex project is thus primarily defined by interdependencies and dynamic complexity, rather than structural complexity. A complex project is unpredictable to a large degree and influenced heavily by small differences in initial conditions as well as by changes in the surrounding environment. Even if, in most theoretical definitions, size is not included, or is specifically excluded - such as the reference paper (Baccarini, 1996), size is critical to project management practice. A small project, even if complex following the “complexity theory” definition, cannot actually be considered a real complex project in practice, since the costs for solving a complex, but small problem, will not justify implementing special methodology or tools. On the other hand, managing size is a problem per se. The size of a project determines as well the size of its team and in practice one rarely can split a project into non-interdependent parts. According to Fichtean/Hegelian Dialectics, quantitative change leads to qualitative change (Hegel, 1874). Also, as (Bennet, 1995) puts it, from 100 line programs 45 years ago to multi-million line systems now, it is impossible for one person to understand a complete software system. And productivity is a reverse function of the size of the team - due to communication issues and planning constraints. Ideally, we have a small team working on the project for a long period of time, which requires little overhead of communication, information transfer, interpersonal relations. The basic equation of (software) project management is the triangle of cost + time + scope (+quality, but quality can be seen as a component of the scope and is usually considered as an underlying characteristic, not an individual dimension in software project management – thus being visually placed in the centre of the triangle). If the scope remains constant, time is reverse proportional to cost, so theoretically the project will be less expensive if it has a very long duration - and accordingly a reduced effort. In practice, constraints such as marketing environment (opportunity costs for not marketing a product in time), financing arrangements and costs, legal or customer-imposed constraints, force all projects to compromise between cost and time – an increased cost is accepted for finishing the project faster (usually by project crashing or fast-tracking). Even if the technology allows a faster development time, e.g. by using COTS, frameworks or tools, this adds even more to the complexity of a project by including new dependencies. For example: if the development of a new version of a mass-marketed software product (computer game, mobile phone software) would be 5 years, the software would be developed chipper, but it would be completely out-fashioned at the time of release – the functionality would be deprecated and the hardware and communication infrastructure (computing power, bandwidth) would significantly surpass the software capabilities. If detailed planning is extremely difficult in project management in general (thus wave-crest planning being the norm), in complex projects it becomes impossible, as even the definition of the work breakdown structure might change, and sometimes even the objectives are impossible to define before-hand (College of Complex Project Managers And Defence Materiel Organisation, 2006). The mainstream importance in the management of complex projects has subsequently moved on individuals rather than on frameworks and models (Williams T. , 1999). Since a complex project is difficult or even impossible to plan, processes are less important than managerial skills. The skills, training and experience of 119 International Journal of Computer Science Research and Application, 2(1):115-125

project managers have always been considered key success factors of the project; but when project management practice is recognized officially as not functioning for the most critical tasks – management of complex projects – their competence and expertise becomes even more important. As Dalchar stated in a milder formulation of the controversial Chaos reports (Standish Group Int’l, 1994), “contemporary project management practice is characterized by: late delivery, exceeded budgets, reduced functionality and questioned quality. As the complexity and scale of attempted projects increases, the ability to bring these projects to a successful completion dramatically decreases” (Dalcher, Dec. 1993). Project management practice has always been a balance between skill and method. For complex projects, there is an increasing need for formal methods of project management in order to re-equilibrate the balance. Moreover, there is no clear practical demarcation between “structurally complex” projects and “real complex” projects. All software projects have a degree of complexity in them – be it only because of the unpredictability of the development process per se, if not taking into account external or (inter)dependency factors. There is no such thing as a project without problems; a well-managed project is not a project without a mess, but a project with a well-managed mess. Even if the definition is that a complex project is unpredictable and cannot be planned (by analogy to a complex system), this does not mean that all complex projects are in practice open-ended. The “good enough” solution is not sufficient in industry. As an example, a research project is typically a complex project. One does not know exactly where one would arrive. One will never conclude that the research job finished – research is open by design (there will always be a new problem or question to solve, even if the research topic was defined in a very narrow scope). Still, for a research project as well as for a development project, sponsors demand for milestones, deadlines and quantifiable results. Sponsors of projects (complex or non-complex) demand planning, milestones and targets. Not meeting the objectives equals to failure even if the project has been defined as a complex project. So the issue remains that, even if in theory complex projects cannot be planned or measured, in practice this answer is not acceptable. The question is how to plan and manage complex projects in practice. The agile approach is answering well to the problem of open-ended projects. In the same time, it answers badly to the problem of meeting the objectives. In an agile project, sponsors must agree to the principle that the objectives are open both in terms of scope and deadlines. This works reasonably well for instance in the development of products, where features are added one at a time. This does not work well in fixed-terms projects, where deadlines are fixed and the exact definition of scope/objectives has a huge importance. Real- life projects have targets and deadlines to be reached, and penalties attached to these milestones. The definition of a complex project itself is at the moment sufficiently abstract to be interpretable. In practice, organizations have defined quantitative metrics for raising flags that a project may fall under the “complex project” definition. These quantitative definitions cannot be perfectly aligned with the abstract definition of complexity (there is no practical way to define numerically that a project has “complex” interdependencies); even more, they are usually defining structural complexity on mere size. Examples of such flags for raising attention are: - budget; - numbers of stakeholders: number of team members; number of users; - effort required; - the expertise of the organization in the area of the project; - the number of stakeholder organizations (e.g. subcontractors), their size, the amount of subcontracted work; - the number of business areas concerned by the project; - diversity of the components to be included in the solution. This is usually linked to the diversity of business problems, but also includes technical requirements such as:

The final verdict regarding the complexity of the project is still a human decision, based on a set of qualitative rather than quantitative factors. It is the same principle as the basic decomposition rule: a project will be decomposed (into components, work packages, activities and tasks) not until each component has a clearly-defined size (“5 days”), but until the responsible of the lowest component understands exactly what needs to be done in the specific component.

5. Scope definition, analysis and design of complex projects

120 International Journal of Computer Science Research and Application, 2(1):115-125

The IT culture developed a significant set of analysis methods and tools, from simple concepts to complex frameworks, linked to corresponding development methodologies and life-cycles. As simple analysis and design methods used independently, we could mention prototyping or RAD. Object- oriented analysis and design, functional analysis or data-oriented analysis and design are generic concepts that both may be used when using the classical life-cycle, which continues to be highly usable as development methodology for small/simple projects as it insures a clear identification of scope very early in the project. As size and/or complexity of the project increases, the classical life-cycle model is no longer functional, nor the semi-formal development methods (rapid prototyping or rapid development). More sophisticated methods appear – models that allow for iterations and increments (spiral, RUP, agile, feature-driven, test-driven development), and which overcome the classical problems of the classical life-cycle: allowing for changes in scope during the project execution (after this 1st phase), changes in the requirements, new requirements being discovered, or old requirements becoming deprecated; or allowing for change in general. One of the major challenges posed by complex IT projects is the impact of the project itself on its environment. The project itself will change its own initial requirements, underlining its characteristics of dynamicity and open-ending. A complex project should therefore consider, even from its inception, to have change management as one of its work packages. The analysis of initial processes and of the resulting processes is a mandatory phase in the preliminary (general) analysis. As a consequence of the uncertainty characteristic, in complex projects one cannot assume that the requirements will be discovered in only 1 initial stage, no matter of the analysis method. On the contrary, we should expect that new requirements will appear during the project’s execution. A possible answer could be doing the analysis in increments (therefore choosing an incremental rather that iterative life-cycle). This would allow change (even in the definition of the scope) during the project, so as to better align to the real project objectives/requirements, not only to the formalized project objectives/requirements. Also, it would contribute to forcing the team to perform in smaller loops and thus reduce the “99% finished” risk, and keeping up the pressure on the team by imposing intermediary (but real) milestones. The term “real milestone” is used to differentiate between an externally-imposed milestone from an internal task deadline. A milestone imposed from the exterior (legal, contractual, assumed towards end-users or customers) has intrinsic authority, whereas an internal deadline (project plan, tasks) has only the authority transferred to it from the authority of the manager. A major disadvantage and risk is of having the scope changed uncontrollably during the project. The stakeholders would usually discover new needs and change the requirements or even the scope during the project’s execution. In this case, it does not suffice to claim that change is inherent in all projects and just needs to be controlled – the controlling process itself will be severely impeded. The application of a strict change management procedure is difficult in the context of a methodological framework that is built on the principle of changing scope and requirements – thus lacking a stable initial configuration. While acknowledging that a key factor in selecting a method/tool is the level of knowledge/experience of the team with working with the method/tool, one of the open questions is how the complexity of the project should impact the selection of analysis and design methodologies.

6. Complexity Extended: IT Projects in Education

Projects in education are significantly difficult to manage and evaluate, considering the multitude of factors impacting the results of education, but also the time-span (the results of a project implemented on a large scale in an education system can only be measured after years, and the results on the society itself may be fully perceived only after one generation). ICT resources in education are changing slowly the way we learn today, but change dramatically the way society will function tomorrow. Establishing the targets is a challenge per se, as the success indicators vary widely from project to project; from mere quantitative metrics related to provided resources (such as number of computers), to more elaborated usage rates of the provided resources and satisfaction-surveys, and very rarely to impact on pedagogical results. It is obviously difficult to measure the success of a project when the business concept itself evolved dramatically over the last 10 years, and continues to evolve faster than society itself. eLearning was described 10 years ago as delivering text on a computer or over the Internet, using web or email, typically as a faster replacement for regular mail in distance learning programs. Today we have an eLearning 2.0 concept which uses virtual collaboration and communication environments based on web 2.0 tools, including delivery of multimedia-rich simulations and experiments through personalized curricula, facilitating project-based learning models and collaborative web- based learning environments. 121 International Journal of Computer Science Research and Application, 2(1):115-125

This leaves the decision-makers and civil society trailing behind – as an example, even if all the education systems in Europe have already integrated eLearning (in various degrees), there is no European policy on eLearning. Teachers and pupils use eLearning. But decision-makers and society continue to reduce eLearning to eSkills (learning IT, not learning using IT as a resource). This creates an additional need to identify and manage the stakeholders of any eLearning project.

7. IT Projects in education: the architectural decision

The choice of architecture in national education projects starts from the basic principle of centralized vs. decentralized systems. The choice of architecture is not only technical as much as economical and political. The economical environment defines the level at which central coordinating organizations (national or regional education administration) has the power to allocate financial resources and capabilities to manage them, in contrast to the power and capabilities of local educational administration. Politically, we should consider the strategic policy on the decision-level of each administration layer.

Figure 1. IT projects in education - a holistic view

Two major streams of thought dominate the political context worldwide: the necessity to standardize and mutually recognize qualifications, and the drive towards decentralization of the decision-making process. In the European context, these are reflected in the Bologna process (as part of the process of consolidation of the European Union) and in the decentralization strategy, respectively. The Bologna process is aiming through standardization towards a centralization of the decision-making process. The strategy does not aim for centralization per se, but centralization is an outcome of the process. The technical environment of complex IT systems is benefiting from a new wave of technologies that allow for increased interoperability (SOA, XML, or in the context of eLearning: SCORM, IMS, AICC, SVG, MathML, ChemML) and common usage of resources (grid, cloud computing). As (Bennet, 1995) says, the means to deal with complexity in software development is to employ a modular design and build systems as separated layers of abstraction. Modularization and reusable components, nowadays embedded in modern technologies such as OO, reduces impact of scale and complexity issues. In practice, systemic decisions must account for individual conditions in each educational community that often build-up to external technical constraints to any project. The majority of schools do not have reliable Internet connection - not even in Europe, and Internet connection is a rare exception in Asia, South America or Africa. IT-adoption is both facing social problems, political problems (Jugureanu A. , 2010) as well as technological problems (Parayil, 2005). While Europe develops strategies to enhance even more an already 122 International Journal of Computer Science Research and Application, 2(1):115-125

accelerated rhythm of learning ICT skills for its graduates (Kolding, Robinson, & Ahorlu, 2009), in 2004 there were thirty countries with an Internet penetration of less than 1% (The Digital Divide at a glance) and the entire African continent had an Internet penetration of less than 3%. Based on these underlying conditions, three types of projects may be identified in the area of major IT education projects: - Projects decentralized as architecture, but centralized as decision and methodology. Case studies may be found in France, Morocco, Romania, Moldova. - Projects centralized both as architecture and as methodology. Significant case-studies are North Ireland, Cyprus, UAE, Azerbaijan, Malta. - Fully decentralized projects in UK or US. We should be aware that there is no single rule to cover all situations. Each continent and country has specific circumstances that influence the choice-architecture.

8. The eEducation Concept

IT in education entered from two different directions: administration and pedagogy. There are various levels of interaction between the two areas. The following project components are derived from practical examples of projects of introducing IT in education sectors in various countries such as Romania, Azerbaijan or Morocco.

8.1. eGovernment – support for management and administration

One area is eGovernment – the introduction of IT systems for the management of education. This area concerns two layers and various business processes. - Management of schools; - Management of the system. The main business processes for the management of the schools are: - Management of the school structure, organization and study groups; - Management of students; - Management of results: grades/grade-books, attendance, activities, performance evaluations, bonuses or penalties, extra-curricular activities, contests, awards. - Communication with parents; - Management of teachers; - Curricula management; - Evaluation and examination management; - Social benefits; - HR management; - Management of material resources (buildings, classrooms etc.); - Scheduling and calendars; - Quality management. The main business processes for the management of the educational system are: - Management of the school life-cycle (authorization and evaluation cycle); - Communication. - Normalized examinations management; - Standardized curricula management; - Quality evaluation at systemic level; - Decision support.

8.2. Pedagogical support

The second area of IT usage in education concerns the pedagogical approach. 3 different business processes are to be considered: - Management of the learning process, with the main functions: - Virtual classroom – synchronous teaching/learning sessions; - Management of asynchronous/self-paced learning sessions; - Testing, evaluation and results (up to personal portfolio functions). - Management of courses: planning, scheduling, enrollment, executing, evaluation, monitoring. 123 International Journal of Computer Science Research and Application, 2(1):115-125

- Communication and collaboration support. - Management of the learning resources and curricula (virtual library): - Management of atomic learning resources (RLOs); - Management of course content and lesson plans. - Content authoring.

4. Conclusion

Some key issues need answers in the sub-domain of software project management for complex projects in education. While it is still difficult to define a complex project, even by using concepts from other sciences such as sociology and biology (such as the complexity and chaos theories), there is no practical definition or metrics to be implemented in real projects. A definition is not proven, but researchers and practitioners must be able to easily work with it: it must be functional. The degree of required functionalism, or the type of functionalism required by practitioners and theoreticians, is different. A definition of an abstract, theoretical concept uses also abstract, theoretical concepts A theoretical, abstract definition may be useful in fundamental research, and is rarely usable in practice. The need for a practical definition of complex projects derives directly from project management practice. As argued in the previous chapter, projects are becoming more and more complex, and complex projects require specialized methodologies and specialized project managers. Also as argued in the previous chapter, any project displays a certain degree of complexity. An organization that makes extensive use of project management as part of its key operations needs to easily differentiate between ”simple projects” and ”complex projects”, because the specialized management of complex projects incurs supplementary costs, top-skilled/specialized project managers, specialized methodologies and procedures, special top-management attention. The definition required must be functional in their case. It must be specific to the business domain. It must allow easy computation and categorization. Ideally, the analyst that computes values and classifies projects on a complexity scale should just use values from project managers and should not necessarily be an expert project manager; he would only use expert judgment techniques in special cases, since the required experts are expensive to be used just to classify any project. The project management theories have starting to evolve since the late 1990s to incorporate a dimension of complexity. Still, these are not fully integrated (Saynisch, 2010). And especially in education, the development of a framework methodology for the setup and management of complex projects is required in order to tackle with the complexities of combining the intrinsic complexity of IT projects, the education aspects and the risks introduced by the wide range of stakeholders involved in major education transformations. At this moment, processes are less important than managerial skills when dealing with the management of complex projects. Project management practice has always been a balance between skill and method. For complex projects, there is an increasing need for formal methods of project management in order to re- equilibrate the balance.

References

Atkinson, R., Crawford, L., & Ward, S. (2006). Fundamental uncertainties in projects and the scope of project management. International Journal of Project Management , 24 (8), 687–698. Baccarini, D. (1996). The concept of project complexity, a review. International Journal of Project Management , 14 (4), 201-204. Belady, L., & Lehman, M. (1985). Program evolution: processes of software change. London, UK: Academic Press. Bennet, K. (1995). Legacy Systems: Coping with Success. IEEE Software. Bennett, J. (1991). International Construction Project Management: General Theory and Practice . Oxford: Butterworth- Heinemann. Calinescu, A., Efstathiou, J., Schirn, J., & Bermejo, J. (1998). Applying and assessing two methods for measuring complexity in manufacturing. Journal of the Operational Research Society (49), 723–733. Castejón-Limas, M., Ordieres-Meré, J., González-Marcos, A., & González-Castro, V. (2010). Effort estimates through project complexity. Cicmil, S., Williams, T., Thomas, J., & Hodgson, D. (2006). Rethinking Project Management: Researching the actuality of projects. International Journal of Project Management , 24 (8), 675–686. College of Complex Project Managers And Defence Materiel Organisation. (2006). Competency Standard for Complex Project Managers (Version 2.0 ed.). 124 International Journal of Computer Science Research and Application, 2(1):115-125

Commission of the European Communities. (2001). The concrete future objectives of education system. Brussels. Cooke-Davies, T., Cicmil, S., Crawford, L., & Richardson, K. (2007). We’re not in Kansas anymore, Toto: Mapping the strange landscape of complexity theory, and its relationship to project management. Project Management Journal , 38 (2), 50-61. Cova, B., & Salle, R. (1992). Project marketing and network theory: a gift approach. 8th IMP Conference , (pp. 20-38). Lyon. Crawford, L., Morris, P., Thomas, J., & Winter, M. (2006). Practitioner development: From trained technicians to reflective practitioners. International Journal of Project Management , 24 , 722–733. Dalcher, D. (Dec. 1993). The new project management mindset for the 21st century. Proc. 1st British Project Management Colloquium. Henley-on-Thames, UK. Downes, S. (2005). E-learning 2.0. Retrieved from http://www.elearnmag.org/ subpage.cfm?section=articles&article=29-1 Edmonds, B. (1999). Syntactic measures of complexity - Thesis of the University of Manchester for the degree of doctor of philosophy in the faculty of arts. Gardner, H. (1983). Frames of Mind: The Theory of Multiple Intelligences. New York: Basic Books. Hegel, G. W. (1874). The Logic. Encyclopaedia of the Philosophical Sciences. Hertogh, M., & Westerveld, E. (2010). PhD thesis: Playing with Complexity - Management and organisation of large infrastructure projects. ISTRATE, O. (2009). The Evaluation of eLearning Programs. Jaafari, A. (2003). Project management in the age of complexity and change. Project Management Journal , 34 (4), 47-57. Janssens, G., Hoeijenbos, M., & Kusters, R. J. (2011). Complexity Impact Factors on the Integration Process of ERP and Non ERP Systems - A Basis for an Evaluation Instrument. ICSOFT - 6th International Conference on Software and Data Technologies , (pp. 17-22). Seville. Jugureanu, A. (2010). A critical discussion in terms of the "digital divide" debates. The 6th International Scientific Conference - eLearning and Software for Education. Jugureanu, R. (2010). Project based learning on multi-touch systems. The 6th International Scientific Conference - eLearning and Software for Education. Kailash, A. (2008). Project complexity redux. Retrieved from http://eight2late.wordpress.com/2008/07/02/project- complexity-redux/ Kailash, A. (2008). Rumours of a new project management paradigm. Retrieved from http://eight2late.wordpress.com/2007/11/03/rumours-of-a-new-project-management- paradigm/#project_paradigm_complex_defns Karrer, T. (2006). What is eLearning 2.0? Retrieved from http://Elearningtech.blogspot.com Kolding, M., Robinson, C., & Ahorlu, M. (2009). Post Crisis : e-Skills Are Needed to Drive Europe' s Innovation Society. IDC White Paper. Laurenz, E. J., & Chris, V. (2010). The Rise and Fall of the Chaos Report Figures. IEEE Software , 30-36. Lewin, R. (1993). Complexity: Life at the edge of chaos. London. Lorenz, E. N. (1963). Deterministic Nonperiodic Flow. Journal of the Atmospheric Sciences , 20 (2), 130–141. McComb, S., Green, S., & Compton, W. (2007). Team flexibility’s relationship to staffing and performance in complex projects: an empirical analysis. Journal of Engineering Technology Management (24), 293–313. Moll, J. v., Jacobs, J., Kusters, R. J., & Trienekens, J. J. (2004). Defect detection oriented lifecycle modeling in complex product development. Information & Software Technology , 46 (10), 665-675. Morel, B., & Ramanujam, R. (1999). Through the looking glass of complexity : the dynamics of organizations as adaptive and evolving systems. Organization , 10 (3), 278-293. Morris, P., & Hough, G. (1987). The anatomy of major projects: a study of the reality of project management. Chichester: Wiley. Parayil, G. (2005). The digital divide and increasing returns: Contradictions of informational capitalism. Information Society , 21 , 41-51. Piaget, J., & Inhelder, B. (1969). The Psychology of the child. New York: Basic Books, Inc. Project Management Institute. (2003). A Guide To The Project Management Body Of Knowledge (3rd ed.). Project Management Institute. Saynisch, M. (2010). Beyond frontiers of traditional project management: An approach to evolutionary, self-organizational principles and the complexity theory-results of the research program. Proj Mgmt Jrnl , 41 , 21--37. Sinha, S., Thomson, A., & Kumar, B. (2001). A complexity index for the design process. In P. E. Publishing (Ed.), International Conference on Engineering Design ICED’01 , 1, pp. 157-163. Glasgow. Standish Group Int’l. (1994). Chaos, tech. report. The Digital Divide at a glance. (n.d.). Retrieved from http://www.itu.int/wsis/tunis/newsroom/stats/ Thomas, J., & Mengel, T. (2008). Preparing project managers to deal with complexity – Advanced project management education. International Journal of Project Management (26), 304–315. Toffler, A. (1971). Future Shock. London: Bodley Head. Turner, J., & Cochrane, R. (1993). Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them. International Journal of Project Management (11), 93-102. Vaaland, T. I., & Håkansson, H. (n.d.). Exploring interorganizational conflict in complex projects. Retrieved 2011, from http://www.impgroup.org/uploads/papers/130.pdf 125 International Journal of Computer Science Research and Application, 2(1):115-125

VIDAL, L.-A. (2009). THINKING PROJECT MANAGEMENT IN THE AGE OF COMPLEXITY. PARTICULAR IMPLICATIONS ON PROJECT RISK MANAGEMENT (PhD Thesis). Paris: ÉCOLE CENTRALE DES ARTS ET MANUFACTURES « ÉCOLE CENTRALE PARIS ». Vidal, L.-A., Marle, F., & Bocquet, J.-C. (2011). Measuring project complexity using the Analytic Hierarchy Process. International Journal of Project Management , 29 , 718–727. Whitty, S. J., & Maylor, H. (2009). And then came Complex Project Management (revised). International Journal of Project Management (27), 304–310. Whitty, S. J., & Maylor, H. (Feb 2007). And Then Came Complex Project Management. Proceedings of 21st IPMA World Congress on Project Management. Williams, T. (2005). Assessing and moving on from the dominant project management discourse in the light of Project Overruns. IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT , 52 (4), 497-508. Williams, T. (1999). The need for new paradigms for complex projects. International Journal of Project Management , 17 (5), 269-273. Williams, T., Eden, C., Ackermann, F., & Tait, A. (1995). The effects of design changes and delays on project costs. Journal of the Operational Research Society , 46 (7), 809-818.

Brief Author Biography

Stefan MORCOV is a computer science engineer, having graduated Politehnica University Bucharest. He has an Executive MBA diploma from Tiffin University- Ohio and the University of Bucharest and specializes in software engineering, project and product management. He has 11 years of experience in the setup and management of complex integrated projects in education in Europe, Africa and Asia. He is also in charge of complex project implementations for European Union agencies such as the Publications Office, Eurostat, DG Sanco, DG Devco-EuropeAid and others.

Copyright for articles published in this journal is retained by the authors, with first publication rights granted to the journal. By the appearance in this open access journal, articles are free to use with the required attribution. Users must contact the corresponding authors for any potential use of the article or its content that affects the authors’ copyright.