Introduction
Project management as a practice today draws a lot of attention based on the benefits that accrue from its successful application (Alberto, et al. 2006). As business processes keep changing there is a need for a defined process to initiate, plan, execute and monitor these processes (Schwalke 2005; Nicholas 2000). This discipline normally presents itself through project management. The dynamic nature of business processes lately has resulted in the need to have an approach that can well adapt to the ever-changing business environment. On the surface, agile project management is not any different from the other project management approaches with the typical steps running from initiation through to monitoring (Boehm 2010; Thomas 2010).
However, this approach has a number of strengths over the conventional project management approach. This approach encourages stakeholder involvement where the stakeholder assumes a position on the project team itself (Cohn 2005; Highsmith 2004). Feedback is also given greater weight with user requirement metrics and effective controls put in place. This has made the approach a better choice for today’s dynamic business process build-ups.
This approach identifies and employs the most significant metrics putting every one in the picture while ensuring the importance of their input when this is appropriated. A typical agile project management team is composed of the project leader who can also double up as the vision bearer of the business vision (Chin 2010). The other team members are drawn from various specialties pertinent to the project and they perform their activities in a cross-functional approach.
Agile project management bears an intrinsic ability to address change even as the project progresses. This is made possible by the fact that the team approaches the project while considering the fluidity and adaptability of the organization (Guaniera, et al. 2000).
This is very unlike the traditional project management that proceeds on the assumption that risks and processes are predictable and manageable upfront. This approach also thrives on hierarchy and organizations having this structure are assumed to portray a better-established order. This however may not be true considering that the agile project management works well where the structure is not rigid. It has been traditionally considered that problems are better solved by a systematic disintegration into manageable portions that are later on reassembled at the end of the pipeline to give the overall picture.
Agile project management may not consider it so where stories which are overviews are translated into tasks and handled by the team within an assigned period of time (Schwaber 2004). During project management initiating, planning, executing and monitoring the project must be within the project constraints of time, cost and quality and project management help organizations to achieve this and hence ensure the success of their projects. Project management requirements are significant and planned by a well-defined team which has the technical capacity to work within the defined discipline.
However when these disciplines are not clearly followed the project is likely to slip or altogether fail to result in loss of money and a dented reputation. This study considers two such cases pinpointing the areas that contributed to the project failures.
London Ambulance Service CAD dispatch system 1992
The London Ambulance Services a reputed firm that has been in service for quite a while. Their major aim is to provide professional ambulance service especially within the city of London. As at January 1993 LAS had a staff of 2,700 serving a population of about 7 million. The firm had 800 vehicles supported by one helicopter making about 2 million journeys every year (London Ambulance Service – A Brief history 2010).
The LAS then received an income of about £ 70 million. The London Ambulance Service (LAS) management saw a need to invest in information technology to streamline their services while offering them a competitive advantage. They settled for a computer-aided dispatch (CAD) system that was supposed to help streamline and make efficient the service provision. The system was expected to process the primary control functions at LAS. These functions would typically include:
- Management of the strategic positioning of equipped ambulances to minimize response time
- Effecting communication to the targeted dispatch units
- Identification of the ambulances to dispatch
- Reception of incident calls and identification of their location
The board at LAS contracted System Options Ltd in August 1991 to initiate the project. The project was worked on by the contract analyst assisted by the systems manager who had earlier produced the specification. However the ambulance crew was never consulted during this process. LAS during tendering indicated that the system supplier would take full responsibility for the delivery of the system. However, from the onset System Options Ltd (SO) appeared inexperienced to handle a project of such magnitude even though the board turned the responsibility to them and sanctioned that they take over and initiate the project.
Soon it became apparent that the CAD dispatch system was not progressing as expected. There was no well-defined project team. The members also lacked the technical know-how of project management. Lack of a properly structured approach meant that the benefits of PRINCE management methodology would not be of much benefit to the team. Further still no clarification was available of how this management methodology would benefit the project. There was no communication plan in place even as the temporary team members remained uncommitted to meetings. The trust that senior management gave to inexperienced System Options Ltd generated a false impression as far as the health of the project was concerned.
The single-sourcing policy by the board shut out competitive bidding that eventually affected the quality and delivery of the system. Inadequate testing meant that integration processes were not well addressed and flaws would soon emerge. The hurried implementation cut short any adequate user tests and maintenance which would later affect the working of the system. Seemingly there was no experienced project manager as a role and in his or her place was LAS contract analyst with other mid level LAS managers who did not have prior knowledge on project management (Finkelstein 1993).
Based on DISC a model of behavior by Marston we infer a board that is exhibiting dominance, influence and compliance. The board at LAS has a need and sees the opportunity to unilaterally proceed and address the problem though there is evidence that a similar earlier project had also failed. They are not seeking to do further consultation before embarking on this project. The fact that the system manager and contract analyst derive the systems requirements specification disregarding the input by the ambulance crew clearly indicates influence and compliance. This could well point to an organizational culture that involves the seniors making unilateral decisions.
As far as it goes PRINCE as a project management methodology was employed though none of the team members had knowledge of how it would be applied to the project. While we closely look at the situation at LAS the aspect that influences compliance could be personal on the side of the contract analysts who assumed independence after the board approving System Options Ltd to proceed with the project. It could also be organizational on the part of the system manager who teamed up with the contract analysts and they independently generated the systems requirements specification without consulting the ambulance crew who were the eventual users of the system.
The LAS project had some professional conduct issues and practice especially so with System Options Ltd who even on knowing that they could not deliver the project of such a magnitude went ahead and assumed the role. They were later to make some underestimations that would eventually affect the overall project. They remained in the project hoping that Apricot would be contracted to take the full mandate of running the project.
System Options Ltd, failure to give appropriate advice to the board even in relation to this matter was an issue of professional conduct. A close analysis of whatever transpired indicates that more negotiations and consultations should have been carried out and all the stakeholders consulted for their input. As such the team composition had representation from SO and LAS; however there was no representation by the customer whom LAS provide their service to (Rioux 2001). Successful project management must put in consideration all stakeholder requirements however this was unlikely the case during this project. This was part of the reason that the project was not successful.
Integrated Cargo System, Australian Custom Services 2005
This was an ambitious project initiated in the year 2000 by the Customs in conjunction with the government (Barber 2001.). At this juncture it was called cargo management re-engineering (CRM). The Integrated Cargo System (ICS) was part of the CRM. An IT firm EDS initiated the project in 1997.They were later replaced by computer associates in 2001. Customs also engaged IBM to implement the connect facility of the ICS.
By 2004 the export functionality was successfully integrated whereas the import functionality was integrated in 2005. However this resulted into some disruptions. This factor coupled with the potential threats that resulted after the 9/11 attacks, the CRM started to redefine their implementation especially so as concerns border protection (Booz 2006). Generally the issues that arose included:
- System malfunctions due to data integrity issues.
- Other stakeholders of the system were using software that had failed and therefore generated erroneous information.
- Due to the unreliability of the third party software that Custom clients were using, some of them later attempted to switch to ICS directly resulting in system overload.
- The help desk was overwhelmed by calls from the industry which most often went unanswered.
Customs were the sole initiators of the project carrying out an outsourcing exercise which located a number of developers who would later be engaged in the project. We can clearly define dominance by Customs who had wanted to streamline their service to the government and community. Customs never made any consultations with the industry or community and government. The fact that Customs carried out the project unilaterally indicates that there was influence. As far as we can possible understand Customs were able to see the need to have cargo management re-engineering of which ICS was a part which pointed towards their steadiness.
Though the ICS seemed to work properly with the air cargo industry, it failed to integrate with the sea cargo and as a result discrepancies and bottlenecks became evident at this point of system integration. Customs seemed to portray compliance in this project choosing to proceed with the project unilaterally though the project would later affect the other stakeholders. While looking at this case it is likely that the compliance here was on an organizational level. One of the obvious reasons of disruption of the ICS was limited consultations with other stakeholders. It would have been of great benefit if Customs consulted with the government and industry to come up with the integrated cargo system (Beinat 2001).
Comparison of LAS CAD and ICS
The LAS CAD dispatch system and the Customs ICS share a number of things. The common denominator in these two cases is the lack of a defined project management approach. These projects lacked a well-defined project management team with roles and responsibilities. Ineffective communication stands out commonly among these two projects which may have been due to lack of a project team. A defined project team would have been responsible for coming up with an effective communication plan (El-Hakim 2002).
Personality traits seemed to play a part in both cases with dominance, influence and compliance aspects showing strongly both for the case of the LAS who were the main stakeholders and Customs.
Some pertinent recommendations as concerns the success of IT projects include the following:
- An all-encompassing project team with a project leader and team members who are conversant with the discipline of project management. The team must include representation from other stakeholder and therefore all inclusive
- A defined budget and timeframe or schedule plan for the proposed project
- A well defined risk management strategy
- Structured methods for project progress monitoring including quality assurance
- A project manager who necessarily bears the business vision to be addressed through the project
- Continuous documentation
- Competitive tendering processes to bring on board competent stakeholders.
- Adoption of dynamic project management approaches to promote flexibility and adaptability during the process.
Decision-making
Decision-making is a very vital process in or every day life. This process generally falls into cognitive and normative categories where the former approach is based on the surrounding whereas the latter is based on logic (March 1994). Decision-making differs from problem solving in the sense that problem solving mainly focuses on the problems and their causes while decision-making establishes a set of objectives in a particular situation and derives their weighted classification. The objective with the most weight is preferred in decision-making. The techniques employed in decision-making would therefore include:
- Focusing on the advantages versus disadvantages of the subject
- Establishing a simple priority either weighted or unweighed
- Choosing the first option which appears suitable to achieving desired results.
Green IT also known as green computing has attracted attention lately (Harris 2008). The whole process involves the redefining of computing in terms of the products and processes to ensure that they are environmentally friendly. Green computing involves the manufacture of recyclable hardware with reduced toxic components as well as the incorporation of processes within the computing process itself that conserve energy (Wallace & Webber 2009).
It is most definite that the adoption of green computing approach within any given organization results in many benefits for that particular organization.
All products have a lifespan and green computing advocates a longer lifespan for these IT products. This means that e-waste quantities will be considerably reduced thereby resulting in a cleaner environment (Curles 2000). For computing the more efficient a process can be the better in terms of productivity and energy efficiency. Green computing advocates efficient algorithms that in turn translate to efficient systems which translate to efficiency in energy consumption.
These same processes could be defined in such a way as to route resources to energy saving locations. Virtualization and simulation are such approaches where physical systems can be optimized to run a number of processes without the acquisition of extra hardware (Wallace & Webber 2009; Harris 2008). Practices such as telecommuting have been long known to save on costs all across from office space, to power usage and gas emissions.
When implementing a green IT infrastructure a decision can be made based on the benefits that this approach will bring to the organization. It must be noted that more and more companies are adopting the green IT approach and therefore the venture would most definitely boost the firm’s relevance in the industry.
An initial assessment of the firm’s capacity to adopt this change must be carefully considered. While considering all this the likely cost should also be put into perspective and the likely benefits such as energy saving can be quantified and compared with the cost of adopting this approach. Most likely the results indicating the savings in energy consumption and legislative fees waivers that have been used in a number of countries to encourage green computing are likely to surpass the initial cost of implementation.
It is however necessary to make a thorough consideration of how this adoption will affect the current business processes, the quality of data and the policies within the organization.
The decision-making must be in line with the firm’s objectives so that the firm’s strategy is not affected (March 1994). The firm’s management must be convinced that the decision being made is in the firm’s interest and this must be supported by quantified evidence. Normally a careful assessment of the monetary gains from the decision made is suitable although in this case improved service and quality of data must also be carefully addressed.
For this particular case it is necessary to clearly project the total monetary gains that will result from adopting green computing infrastructure and the efficiency this will bring to the organization thereby improving productivity and enhancing quality of data. In approving this, the management can then be able to integrate this decision into the firm’s strategy. It is most definitely expected that the decision will go through the typical stages of decision making which will include orientation, conflict, emergence and finally reinforcement. At each of these stages techniques to aid the management to make the decision must be continuously employed. This should involve all stakeholders including the sister firm in US.
List of References
Alberto, G. et al., 2006. Adopt green IT and green computing practices. Low carbon, 32 (7), pp. 68-75.
Barber, D., 2001. Australian Customs and Border Protection Service. Potsdam: CIPA International Symposium.
Beinat, A., 2001. Earth week event urges green computer practices. Vienna, Austria: Global Publishers.
Boehm, R., 2010. Agile Project Management. Web.
Booz, A.H., 2006. Review of the Integrated Cargo System. Web.
Chin, G., 2010. Agile project management. Web.
Cohn, M., 2005. Agile estimating and planning. New Jersey: Upper Saddle River.
Curles, B., 2000. LASCAD Failure, 3D Models. LASCAD, 33 (4), pp. 38–41.
El-Hakim, S.F., 2002. Problems with Customs new IT system. ICS, 3 (6), pp. 143-148.
Finkelstein, A., 1993. Report of the Inquiry into the Ambulance Service. Web.
Guaniera, A. et al., 2000. Ambulance Services – A brief History. Padova: University of Padova.
Harris, J., 2008. Green Computing and Green IT best practices on regulation and industry initiatives, virtualization, power management, materials recycling and telecommuting. Sydney: Emereo Pty Ltd.
Highsmith, J., 2004. Agile Project Management: Creating Innovative products. Munich: Addison- Wesley Professional.
March, J.G., 1994. Primer on Decision-making: How decisions happen. Concord: Free Press.
Nicholas, J.M., 2000. Project Management for Business and Technology: Principles and Practice 2nd Ed. New Jersey: Upper Saddle River.
Rioux, M., 2001. A Guide to the project management, Body of Knowledge. Project Management Institute, 40(1), pp. 10-19.
Schwaber, K., 2004. Agile project management with scrum 1st Ed. Redmond: Microsoft Press.
Schwalke, K., 2005. Information Technology Project Management 4th Ed. Cambridge: Course Technology.
Thomas, S., 2010. It is a delivery thing: Agile Project Management – Pragmatic Agile- Agile Project Management. Web.
Wallace, M. & Webber, L., 2009. Green Tech: How to plan and implement sustainable IT solutions. New York: AMACOM.