A Review on Project Management and Issues Surrounding Dynamic Development Environment of ICT project: Formation of Research Area Marini Othman, Abdullah Mohd Zain, Abdul Razak Hamdan
A Review on Project Management and Issues Surrounding Dynamic Development Environment of ICT project: Formation of Research Area *1
Marini Othman*1, Abdullah Mohd Zain*2, Abdul Razak Hamdan*3 Information Systems Dept, Universiti Tenaga Nasional, Kajang 43009, Selangor, Malaysia *2, 3 Faculty of Information Technology and Science, Universiti Kebangsaan Malaysia
[email protected],
[email protected],
[email protected] doi: 10.4156/jdcta.vol4.issue1.10
Abstract.
and Project Management, a review is made encompassing the background of project development and management; standards, methods, and tools that are associated to having good management in relation to ICT-based project; elements of traditional project management; challenges in project management which strong emphasis on Risk Management; and the current research and trend in Project Management. The rest of this paper is organised in five sections. The immediate following section provides an overview of project management, popular definition and its traditional concepts. The following section presents summarisation and analysis of some of the current methodology, good practices frameworks, and tools related to management of Information Technology and Information Systems project. The next section presents some of the more recent research pertaining to the performance of complex ICT related project. The last section summarises the important points from the review and proposed a potential high level solution.
This paper presents a review of methods, practices, and analysis on performance and challenges of Project Management for ICT projects with regards to accommodating change. Specifically, the main interest of the review is to understand the impact that is brought by the dynamic environment of projects developed today. The dynamic environment is synonymous to instability but the traditional project management approach favours a stable environment. The following were undertaken: 1. Review of the existing and popular standards, practices, and tools. 2. Study on reasons leading to project failures 3. Analyses of how much of these failures are connected to the dynamic/unstable/changing nature of the development environment. The undertakings lead to a high level solution proposal. It is hoped that the undertaking has formed a strong foundation for further research dedicated at improving project management approach of ICT project development given an unstable environment.
2. Project Management Although the idea of project management has emerged as early as when human started building massive structure such as the ancient pyramid (Nicholas, 2001), the modern project management discipline as we know today has been around for a more than sixty years (Camci and Katnour, 2006). Project management has since emerged as its own field, supported by bodies of knowledge and researches across many discipline. Although still relatively new, the field of Software Engineering has its own bodies of Knowledge that include various methodologies, frameworks, tools and techniques supported by a continuous growing base of research (Rehman and Hussain, 2007). Project Management can be defined as “the application of skills, knowledge, tools and techniques to meet the needs and expectations of stakeholders for a project” (Mathur, 2006). A project can be defined as
Keyword Project management, chaos management, accommodating change and dynamic environment,
1. Introduction This research basically involved the study of project management for complex ICT-based project. Specifically, the research invokes the study for ways to accommodate chaos in a complex project development environment. The concept and theories reviewed in this study are basically from Project Management of Software-based project development and Chaos Theory and stems into narrowed discipline of Agile Method, Adaptive Method, Measurement, and Risk Management. To enable a fair understanding of Project Development
96
International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 a temporary endeavour undertaken to produce a unique product or service” (Mathur, 2006). A rather classical definition of project management appropriately summed it as having three characteristic: 1. a set of objectives; 2. a set of activities complex enough that requires managing and; 3. a defined start and finish time (Cooke-Davis, 2001).
The basic idea of project management is to ensure success of a project development. However, many studies have claimed that project management of many software application and technology-based development projects either fail to reach their goals or fail completely (Camci and Katnour, 2006).
2.2 Chaos in Project Management
2.1 Issues Related to Project Management
According to the Standish Group's "ChaosStudy" reported in 2000 only 28% of all IT application development projects have succeeded, while 23% failed (cancelled before completion or never implemented) and 49% challenged (completed but failed to achieve the project goals like cost, time or specifications). This is partly due to changes that have taken place in the past decade. Today’s development era pose a highly competitive environment which is characterized by high speed of technological churn, turbulent markets, demands learning and flexibility ability of organizations (Patah and de Carvalho, 2007). A later study by Standish Group showed a slight improvement in the success rate. But, it is still alarmingly high. The following Table 1 tracks the progress of project performance for over 60,000 projects spanning over a decade (Standish Group 2008):
The traditional project management address the issues surrounding resources such as labour, time, and money. However, the more recent issue surrounding ICT project management has incorporated challenges in accommodating and adapting to the dynamic environment. As the world progresses and undertakes change, the Project Management discipline too much move along and adapt to the new environment. Negative consequences of improper management includes cost overrun; time slippage; technical shortfalls impairing performance; and failure to obtain anticipated benefits (Laudon and Laudon, 2006) University of Massachusetts at Amherst for example stated “evolution and improvement of software development processes and their support” as part of their research focus (University of Massachusetts, Amherst 2007). The project group at University of Joensuu, Finland, has as one of their main goals is to develop a flexible environment to assist in implementation and computation of software product metrics. Relevantly, these research focuses and goal has everything to do with incorporating change. There are well over 40 renounced research groups in the software process in Europe and United States and Canada (University of Massachusetts, Dartsmouth 1998). There are even more unlisted from other parts of the world. This shows the extent of importance of matters regarding to uncovering and understanding development processes and management related to software, application, and its related technologies. In Malaysia, the Multimedia Super Corridor flagship projects and organisational management information systems have attracted researches with particular interest in issues related to management of the project development (Faizah 2005; Abdul Manaf 2006). The introduction of the Multimedia Super Corridor has initiated more than 900 home-grown and foreign-owned companies under its concept. This prompts an urgency to understand the current practices of its related development and management (Fauziah, Aziz, and Abdul Razak 2006). The study conducted by Fauziah et al found that half of the organisation surveyed used informal and ad-hoc development with reasonable control of schedule and cost.
Table 1. Performance of development projects Succeeded Challenged Failed
1998
2000
2002
2004
2006
26 46 28
28 49 23
34 51 15
29 53 18
35 46 19
Source: The Trends in IT Value Report by Standish Group, 2008 The most recent Standish report reveals a more alarming finding in its CHAOS Summary 2009, It reported, "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions", "44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used" (Standish Group 2009). A clearer presentation of the 2009 finding compared to the findings in 2006 is presented in the following Table 2. Table 2. Comparing development project performance of 2006 and 2009
97
Succeeded
2006 35
2009 32
Challenged
46
44
Observation 3% drop in successful project
A Review on Project Management and Issues Surrounding Dynamic Development Environment of ICT project: Formation of Research Area Marini Othman, Abdullah Mohd Zain, Abdul Razak Hamdan Failed
19
24
5% increase in failed development
personnel
Another important observation that can be derived here is that “planning” is an area prone to becoming a factor for failure. Combining the earlier and later observations, it is most worthy to relook on the management of planning in view of providing room to manoeuvre for necessary change in planning. This would entail in management that does not look at change as reason for failed project. Rather, change in viewed and acknowledged as common and ways to absorb change is a way of managing. A project management methodology covers all the areas that a project manager needs to do with regards of development. It is generally clear that there is no universally accepted single categorization of areas in project management. However, the most common areas cover the management of cost, time, resources, scope, communication, and risk. The following approaches are representative of some of the categorization of areas found by the research: a common standard practice (PMBOK), a common consultative approach, and an academic (textbook) approach typically taught at college level. The three representations are summarizes as following: The following Table 4 summarised the areas representative of categorisation based on standard practice, consultant approach based on experience, and a traditional academic discussed above.
A simple observation that can be made from Table 3 is that problem is associated to activities taken are somewhat lacking in effort (such as insufficient early planning, contingency planning, commitment and cooperation) and inexact estimation (such as scope and priorities). These observations indicate project management as being more of an inexact science (or arts) rather than exact science. Table 3. Reasons leading to failure insufficient early planning unrealistic project design scope underestimated customer/management change insufficient contingency planning inability to track progress inability to detect problems insufficient number of checkpoints staffing problems technical complexities priority changes no commitment to plan by team uncooperative support groups sinking team spirit, and unqualified project
(observed by esearcher’s) Planning Yes Design Yes Design/ Yes scope People/ Planning/ Yes Technical Planning
Yes
People/ Method Technical Technical People/ Technical Planning
Yes
People People People people
Table 4. Comparison on Emphasis Avneet Mathur (Experienced IT Consultant) Cost management
Category
PMBOK (Standard practice)
Cost
Cost Management
Time
Time management
Resources
Resource management
Scope
Scope management
Scope management
Communication
Communication management
Communication management
Risk
Risk management
Others
Integration management Procurement management
Risk management Issues management Quality Change Control management 7
Activities
8
Sommerville (Academic or textbook approach) Project costing Project planning and scheduling Human resource (personnel selection and evaluation Report writing and presentations Proposal writing Project monitoring and review
Source: Turbit, 2005; Mathur 2006; and Sommerville 2001
98
6
International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010
An important discrepancy posed by the IT consultant in the form of an area dedicated to Change control management highlights acknowledgement to the importance of addressing change in the more recent development environment.
and MSC Malaysia Organisation Quality Management System (oQms) Programme is seen to be the champion in introducing such standards to the local developers (MDeC 2008).
3.1 Discussion
2.3 Traditional Development Method Favours Stable Environment
All of the above standards are purported to help reduce risk associated with development project. It is without doubt that these standards are fully able to provide clear goals and instructions to achieve them. However, in the tackling of change, although all standards have some form of mechanism associated to respond to change, the emphasis given to planning and the amount of documentation associated to planning gave the impression of dutifulness to execute original plan and that flexibility is not favoured. PRINCE2 and PMBOK for example, require so much resource (manager’s time and attention) to attend to documentation and even more documentation will be required for any amendments. This discourages changes and flexibility. Most often, change is addressed as risk or incident which is often negatively associated. The truth is not all changes are bad. Some changes are sometimes opportunity to improve development project outcome. The agile version of MSF is however is highly adaptive to change and has reduced disruption in the project environment by focusing on people which is one of the primary factors that triggers change and chaotic challenges.
In the traditional management practice of software development processes are seen as something that can be planned and controlled in order to achieve the planned result. Developers execute developmental process in a manner similar to computers execute software application (Riehle 2000). The execution of plan gave no room for flexibility. Stability is something that is very much expected in the development environment. Projects suited for more traditional methodologies are those that are stable in nature and involved high stakes (Sommerville 2001; Waters 2008): • • • •
Involve stable technology and have fixed requirements, where it is known that few changes will occur Involve mission critical or safety critical systems, where formal methods must be employed for safety or insurance reasons Are large projects which may overwhelm informal communication mechanisms Have complex products which continue beyond the project scope to require frequent and significant alterations, where a recorded knowledge base, or documentation set, becomes a fundamental necessity to support the maintenance
Another important observation is that most of the existing methods address the needs to manage functional specification of the development. The nonfunctional aspects such as technological change, financial ability change, policy shift, entrance and exit of key personnel has yet to be clearly addressed.
3. Standards, Practices, and Tools Today’s post-industrial era presents a highly competitive environment characterized by the speed of technological changes and turbulent markets, demands learning and flexibility ability of organizations. This in turn, demands that project management be considered as a strategic issue for companies planning for success (Patah and de Carvalho 2007). Where such planning is concern, some of the more popular good practices, standards, benchmark and tools that are highly regarded are: CMMI, ITIL, ISO2007, PMBOK, PRINCE2, MSF, RUP, and Adaptive or Agile Methodology (ISACA 2008). In Malaysia, the Multimedia Development Corporation (Mdec) through its MSC Malaysia Capability Development Programme
4. Project Risk Management Risk management is a focus area within project management. It is also often treated as an area by itself. Risk is generally viewed as the likelihood that an event which can trigger loss or create damage (sometimes however, the result may be a favourable one). The challenge lies in not knowing for certain how and when it is going to happen. The fear is that improper planning of how to treat the situation will lead to a chaotic situation. Risk Management is about dealing with uncertainties. Chong and Brown identify
99
International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 four fundamental ways in which risks are bear: Avoid; Mitigate; Share; and Absorb (Chong and Brown 2000). In software based project, some of the most common questions regarding risk and exposures are (Intaver Institute 2008): • What is the chance of your project being completed on schedule and within budget? • What is the chance that the particular task will be on the critical path?
Project Launch Identify scope and goals
Risk Analysis Identify and assess risks
• •
In risk handling, a common cycle usually consists of the following phases: Project Launch, Risk Analysis, Risk Management, Main Project Activities, Project Milestone Review, and Project Closing. The following Figure 1 depicts the sequence of phases and their main activities:
Risk Management Create risk strategy collaborate with risk-sharer implement risk policy
What tasks affect the project duration at most? What is the project success rate?
Main Project Mainstream operational tasks
Project Milestone
Project Finish
Reassess risks
Project handover
Figure 1. Project Life Cycles with Risk Handling A complex system or simply “complexity” is by itself, another contributor to chaos. Because change is even more difficult to be accommodated by a system which is complex, a complex system is assumed to be chaos-prone. The economic environment of Malaysia, for example, is a complex situation made up of multitudes of variables and commands fleets of expert to its steer. However, the complexity of this environment too has a pattern. The economy has over time has a name for the financial turbulence (which is synonymous to economic chaos) that it faces; and has come to term with the inevitable visitation of this turbulence which does somehow send some form of prior alerts (which are actually patterns!). The economic turbulence that visits Malaysia more than a decade ago (1996-97) can be described as follows: Chaos in the form of currency devaluation has inflicted the Malaysian MSC development at the early execution of the plan, economic-crisis hit the globe and Malaysia became no exception. Malaysian currency plummeted, low currency exchange, and value of allocated budget was suddenly devalued at about half. This automatically leads to an overrun in project costing. However, effective financial management of the country has enabled her to proceed though with many spending cutbacks (Nur Zakri 2002). Due to the complexity of the applications within the MSC development, the chaotic scenarios were aggravated. At the point of this writing, in the year of 2008, following the fuel and food crisis, an equal if not worst economic turbulence is expected to peak next year (year 2009). Hopefully, recognising the pattern that
5. Chaos management Chaos management is a rather new concept observed in project management. Managing chaos has gained importance due to the rise in the need of complex systems and the instability of today’s development environment. In managing Chaos, proactively recognize and prevent situations that typically cause projects to fail. In a scientific context, the word chaos has a slightly different meaning than it does in its general usage. Chaos, with reference to chaos theory, refers to an apparent lack of order in a system that nonetheless obeys particular laws or rules; chaos, in this context is synonymous with dynamical instability, a condition discovered by the physicist Henri Poincare in the early 20th century that refers to a natural lack of predictability in systems (Rae 2004). The two main components of chaos theory are the ideas that system: i. ii.
No matter how complex they may be, they rely upon an underlying order, and that, Very simple or small (insignificant) systems and events can cause very complex behaviours or events. This idea is expressed as sensitive dependence on initial conditions.
Based on the first idea, chaos, with an underlying order has a pattern! The following idea suggests that it has a consequence. If we are able to identify the pattern then, the risk of what the chaos elements will bring to a project can be managed easier.
100
International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010
6. Adaptive Project Management
was experience more than a decade ago, we are better prepared to face the challenge. From a more optimistic point of view, Martha Blakefield suggested that chaos are not abnormality, it is rather an essential design characteristics of some systems. Blakefield (1998) cited the work of Robert Lampton on the science of chaos as follows: “All chaotic systems seem to have an unusual sensitivity to initial conditions. They are systems in which seemingly inconsequential changes turn into major differences in outcome. Scientists have found evidence of ‘chaos’ in astronomy, epidemiology, meteorology, air turbulence, the stock market, and the human body. It is in the study of the human body that some scientists are beginning to realize just how important chaos is.” The Standish Group, who is a prime and reputable reporter of project development named their report as CHAOS Report when the success and failures of a project management is examined by ten CHAOS Success Factors. Each Success factor is supported by one of the Laws of CHAOS (Law of the Two Faces, Cheetah’s Law, Law of the Roads, Law of the Longtailed monster, Law of the 5 Deadly Sins, Law of the Mad Hatter, Panda’s Law, Law of the Empty Chair, Law of the Tuxedo, Hammer Law). The research is only able to find the explanation for the some of the Laws which is explained in the following paragraph. The Law of the Empty Chair, states that the best possible person (for example, a development team member) will leave at the worst possible time. The Law of The Hammer is due to Abraham Maslow who was popular for the phrase “if all you have is a hammer, everything looks like a nail.” In the information technology context, it refers to the situation where a familiar technology or concept is applied obsessively to many software problems”. The Law of the 5 Deadly Sins is explained from the agile project management aspect (Haas 2006) as: • • • • •
Management of chaos may require that changes are made to adapt to a situation. Adaptive management can be defined as a structured and systematic process for continually improving decisions, management policies, and practices by learning from the outcomes of decisions previously taken (Intaver 2008). Adaptive management has been adapted by many engineering discipline. In the software development however, the prominent adoption of adaptive management is marked in 2001 when a group of seventeen prominent software gurus met in the Snowbird resort in Utah which among others to discuss effective software development processes. The independent thinkers as well as competitors named themselves the “Agile Alliance”. During the course of this meeting, they wrote the “Manifesto for Agile Software Development” (Highsmith, 2001). Change in software technology has resulted in fundamental change to how we should deal with software development (Yourdon 2000 and Fowler 2003). Rather than resisting change, developers should be accommodating changes. Systems development must strike a balance between being stable and hovering over adapting to change because, systems that are too stable will simply lose relevance and die as environment evolves while on the other hand, systems that are extremely chaotic will self-destruct (Tan et al, 2005) The Manifesto for Agile Software Development is about “about delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important, and lose the word "asset". So in the final analysis, Agile Methodologies is about values and culture”. The Agile Manifesto suggested that effective adaptive management is possible only in creative business environments with self-organizing teams and trusted and motivated individuals. It does not claim to do away with methodology; instead, it restores credibility to the word methodology. “We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.” (Highsmith, 2001) Similar to those of adaptive management, the Agile Manifesto shares the basic principals as follows (Intaver 2008):
Failure to conduct pre-project business analysis and ongoing project evaluation Failure to conduct a formal project kick-off Failure to maintain the core team Failure to manage the project value throughout the project life cycle Failure to manage the project benefits
From the reading of the topic chaos management, it is found that the topic is closely related to the areas which concern complexity, instability, change, and control. Such areas are identified via keywords such as adaptive, agile, and risk management and methods.
101
A Review on Project Management and Issues Surrounding Dynamic Development Environment of ICT project: Formation of Research Area Marini Othman, Abdullah Mohd Zain, Abdul Razak Hamdan •
Regular adaptation to changing circumstances, including changing requirements Constant collaboration in project teams and with clients Iterative development processes
decisions are made quickly to deal the developing situation, the tendency to consistency is often an obstacle to making these crucial decisions.
The ideas that emerged from the agile project management have spread rapidly beyond software project development. Many teams and organizations are applying the agile approach to complex projects. One of the ‘relatives’ of agile project management is flexible product development. Flexible product development offers the ability to make changes in the product, even late in the development cycle (Intaver 2008). Agile project management methods focus mostly on the organizational aspects of adaptation process which stresses on two important principles:
What is exactly “Agile Project Management”? It basically is to equip project managers with tools and methods useful in facing today’s issues of changing requirements and unprecedented technologies. A survey study on the critical success factors of agile software development project using quantitative approach was conducted by the Capella University, Minneapolis (Chow and Cao 2008). The researchers noted that the success of agile software engineering methods has mostly been anecdotal, and research in this subject is still scant in the academic circles. Success is reflected by the overall perception of success of a particular project. The overall perception is based on four attributes: Quality (i.e. delivering a good working product), Scope (meeting all requirements by the customer), Timeliness (delivering on time), and Cost (within estimated cost and effort). The following is a list of potential critical success factors of agile projects that they identified and compiled. Tables 5, 6, 7, 8 present the compilation of failure factors and success factors of the Capella University study based on four categories or dimensions: organizational, people, process, and technical.
• •
• •
7. Agile Software Project and Concerns
Iterative decision-making (decision is based on learning from the outcomes of previous decisions) Strategic flexibility (to avoid irreversible decisions)
Although more and more project managers are using the adaptive management there are several barriers that hinders the acceptance of this nontraditional approach. The article by the Intaver Institute, Canada is heavily referred in providing the barriers that challenged the acceptance of Adaptive Management. The barriers are as follows:
Table 5. Success and failure factors for Agile Projects from the Organizational Dimension
People Project Managers frequently do not realize that adaptive methods will most likely bring better project results than traditional project management processes, where the project plan is defined completely before initiation. Project managers are reluctant to embrace adaptive management due to a number of psychological biases that prevent people from accepting adaptive principles.
Failure Factor • • •
Tendency to Be Consistent A person, who is “inconsistent” in his decision, opinion, or action, is often interpreted as having a character flaw. When people are accused being inconsistent, they tend to become very uncomfortable. A politician who for example may be a strong supporter of a cause years before, suddenly turn to be against it now may seem to be admitting that he was being wrong then. In reality, inconsistency may be not so bad, if it is an acknowledgement of changing circumstances or new information. The tendency to appear consistent is very common in project management. When there is new information about the project and it is critical that
• • •
Lack of executive sponsorship Lack of management commitment Organizational culture too traditional Organizational culture too political Organizational size too large Lack of agile logistical arrangements
Success Factor • • • • • • • •
Strong executive support Committed sponsor or manager Cooperative organizational culture instead of hierarchal Oral culture placing high value on face-to-face communication Organizations where agile methodology is universally accepted Collocation of the whole team Facility with proper agilestyle work environment Reward system appropriate for agile
The factor related to the people dimension is mainly due on their competency, skill, knowledge and
102
International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 expertise. player.
It also lies in their ability to be a team
Failure Factor customer role
Table 6. Success and failure factors for Agile Projects from the People Dimension Failure Factor • • •
•
Success Factor
Lack of necessary skillset Lack of team work Resistance from groups or individuals
•
Lack of project management competence
•
• • •
• • •
•
Team members with high competence and expertise Team members with great motivation Coherent, self-organizing teamwork
Failure Factor •
Managers knowledgeable in agile process Managers knowledgeable in agile process Managers who have lighttouch or adaptive management style Good customer relationship
•
• •
• •
Success Factor
Lack of complete set of correct agile practices Inappropriateness of technology and tools
Ill-defined project scope Ill-defined project requirements Ill-defined project planning Lack of agile progress tracking mechanism Lack of customer presence Ill-defined
• • • • • •
Bad customer relationship
Failure Factor
• •
• • • • •
Well-defined coding standards up front Pursuing simple design Rigorous refactoring activities Right amount of documentation Regular delivery of software Delivering most important features first Correct integration testing Appropriate technical training to team
Chow and Cao have classified a fifth category or dimension for success factors of agile software projects. The fifth category is project. Unlike the dimensions classified in the failure factor, the fifth dimension (project) only classify factors contributing to success. Mostly the factors listed in the project dimension characterised small, dynamic, self-contained team (not dependent or have multiple dependency). Another interesting factor for success in the project dimension is prior planning for costing and risk.
Success Factor •
Customer having full authority
Table 8. Success and failure factors for Agile Projects from the Technical Dimension
Table 7. Success and failure factors for Agile Projects from the Process Dimension
•
•
As shown in Table 7, technical factors are more likely to be a cause of success compared to being a cause for failure. The proper and correct choice and use of tools and methods are contributors to the performance of the project.
It is observed in the Process dimension, a preliminary planning which sets the scope, configuration and requirement affects the performance of the project. The involvement of customer, project monitoring and tracking, and communication are also important factor that could affect the performance of the project.
•
Success Factor
Table 9. Success Factors for Agile Projects based on Chow and Cao fifth dimension (project)
Following agile-oriented requirement management process Following agile-oriented project management process Following agile-oriented configuration management process Strong communication focus with daily face-to-face meetings Honouring regular working schedule – no overtime Strong customer commitment and presence
Dimension
Factor
Project
• • • • • •
103
Project nature being non-life-critical Project type being of variable scope with emergent requirement Projects with dynamic, accelerated schedule Projects with small team Projects with no multiple independent teams Projects with up-front cost evaluation done
A Review on Project Management and Issues Surrounding Dynamic Development Environment of ICT project: Formation of Research Area Marini Othman, Abdullah Mohd Zain, Abdul Razak Hamdan •
existing standards and practice is still lacking in their approaches to be flexible and accommodative to change and therefore is chaos-prone. The Figure 2, on the right depicts a proposed high level block diagram that contains a block which accommodates chaos: the acknowledgement of chaos triggers which receives treatment by a set of frameworks which accommodates and absorbs the change. The framework is a layer of “absorbent” for chaos and minimizes impact to the development environment:
Projects with up-front risk analysis done
Full-size table View Within Article
Chaos Triggers
Source: Chow T. and D-B Cao, 2007 From Table, 9 it can also be concluded that a project that does not have the attributes listed, or have the opposite attribute may have be facing greater challenge and their success rate may be threatened. Following this, it is more challenging to develop a project which has the nature of being life-critical, project which are not dynamic and takes a long time to develop, large project team, there are multiple independent team, have not spend adequate amount of work pertaining to cost and risk prior to the actual project development.
Pre Development Framework
Development Framework
Existing Project Management Practice
8. Discussion At the end of the literature review, a very general question can be drawn as follows: “How should a complex (large, long-time to develop, has high interdependency between components, in other words, non-agile) project be managed to ensure its success?” Taken the changes that the world goes through, the development environment today too, are prone to undergo change. What is appropriate today may not be appropriate tomorrow. However, if we have excellent foresight, we may be able to amend our method so that it does not lose relevance. Excellent foresight is based on excellent hindsight. As the popular saying goes, “history repeats itself”, the past may provide clues to what may happen in the future. The available standards and practice have come a long way to provide for acceptable if not good development environment. However, it does not promise success. Among the challenge lies the need to accommodate change. The existing standards have been providing excellent documentation and clear instruction to perform task to achieve a certain goal. But it does not provide an equally clear plan or instruction if the task or goal or even instruction became impossible or impractical to carry out hence, creating a chaotic situation. In other words, the
Resources: People, finances, time
IS /Softwar e Develop ment
Technology
Miscellaneous
Figure 2. Proposing a Change Accommodating Framework There have been strong indications that successful projects are the ones that have solid planning in the area of costing and risk before development actually take place (Chow and Cao 2008). This leads to the importance of a predevelopment stage that trash out all possible issue that may plague the development later on. Solid planning must be made to prepare the development environment to face chaos. Some degree of change may be an opportunity for improvement. On the extreme, findings pertaining to possible change and chaos during the predevelopment may cause the development to be cancelled altogether. In any case, systems development must include an environment which allows for chaos: balance between being steady and hovering over adapting to chaos (Tan, Wen and Awad 2005).
104
International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 As a conclusion to the literature review, the research has establish a useful area for dedication aimed at improving project management approach for chaos prone ICT development environment in dealing with change. Specifically the interest lies in what are the aspects that may require change throughout a development project, how does it impact the environment, is the change bearable, and how could we chaos-proof the development environment?
[15] A Project Perfect powerpoint presentation. http://www.projectperfect.com.au [2 May 2006] [16] MDEC 2008 brochure www.mscic.com.my, 26 Jun 2007. [17] Nicholas J. M. 2001. Managing Risk in Project, Project Management for Business and Technology, Chapter. 10. Prentice-Hall. [18] Rea L. M. and Parker R. A. 1997. Designing and Conducting Survey Research, A comprehensive Guide, Chapter 5: 82 – 94. [19] Riehle D. 2001. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other. Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP 2000). Republished in Giancarlo Succi, Michele Marchesi (eds). eXtreme ProgrammingExamined. AddisonWesley, 2001: 35-50. [20] Standish Group. 2009. CHAOS Report 2009 -Surprising New Results Announced. The Standish Group International Inc. Boston MA. [21] Tan, J. H. Wen J. and Neveen A. 2005. Healthcare and Services Delivery systems as Complex Adaptive Systems. Communication of the ACM, May/Vol 48, No.5.
9. References [1] Abdul Manaf Bohari. 2006. Pengurusan projek ICT/IS organisasi berdasarkan pendekatan sistem maklumat: satu tinjauan umum. ICT dari perspektif profesional: isu-isu pengurusan dan organisasi / penyelenggara. Petaling Jaya, Selangor: Pearson/Prentice Hall pp: 437459. [2] Asim ur Rehmen and Rashid Hussein, 2007, “Software Project Management Methodologies/Frameworks “A Comparative Approach””, International Conference on Information and Emerging Technologies, ICIET 2007, 6 – 7 July, 2007, pp 1 -5. [3] Blakefield, M. 1998. Order or Chaos. Answer Magazine, Petersburg, Kentucky, USA, June. [4] Camci A. and Katnour T, 2006, “Technology Complexity in Projects: Does Classical Project Management Works?”, PICMET 2006 Proceedings, 9-13 July, Istanbul, Turkey, pp 2181-2186 [5] Chong Y. Y. and Brown E. M. 2000. Managing Project Risk, Business Risk Management for Project Leaders. Prentice Hall. [6] Chow T. and Cao D. B. 2007. A Survey Study of Critical Success Factor in Agile Software Project. The Journal of Systems and Software 81 (2008) 961–971. [7] Cooke-Davis T. J. 2001. Towards improved project management practice: Uncovering the evidence for effective practices through empirical research. t.tp.:t.pt. [8] Fauziah Baharom, Aziz Deraman & Abdul Razak Hamdan. 2006. The Development of Conceptual Model for Assessing and Certifying Software Process. Proceeding of the 2nd Malaysian Software Engineering Conference (MySec’06). Pp79 - 84 [9] Fowler, M. 2005. The New Methodology, http://www.martinfowler.com. [26 July, 2006]. [10] Geraldi J.G, 2008“The balance between order and chaos in multi-project firms: A conceptual model”, International Journal of Project Management 26 (2008) 348-356. [11] Haas K B, 2006. The Five Deadly Sins of Agile Project Management, t.tp.:t.pt. [12] Highsmith J. 2001. History: The Agile Manifesto www.agilemanigesto.org/history.html.[26 July 2008] [13] Intaver Institute, Adaptive Project Management. Project Decision and Risk Analysis Journal, Intaver Institute Inc., Canada. http://www.intaver.com/indexwhitepapers.html [26 July 2008] [14] Mathur A. Introduction to Project Management
105
