Best Practices from Crossroad Bank (Belgium)

Back in the eighties, the Belgian social security sector risked a complete meltdown. A so-called Crossroad Bank was erected, headed byFrankRobben. With the careful implementation of a strategic information infrastructure he helped to redesign all administrative processes, thereby reducing the number of paper forms and the length of the remaining forms strongly. This enhanced not only efficiency and effectiveness of the system, but also the quality of service delivery, the level of enforcement and last but not least the legitimacy of the social security system. An international renowned best practice was born......
Source:http://wiki.triastelematica.org/index.php/Case:CrossRoad_Bank_Belgium(2)

Read more: http://ksz.fgov.be/en/international/page/content/websites/international/aboutcbss.html

Minnesota HealthMatch: A perfect storm for IT failure

Most projects fail due to shifting requirements, inattentive management, poor communication, lousy business fit, politics, and other assorted errors in judgment and organizational maturity. Only in the most unusual circumstances does bad technology dooms a project to failure.

In those cases where poor judgment and lousy communication meet genuinely bad technology, it creates an awful perfect storm where IT failure is almost certain. Minnesota’s Department of Human Services (DHS) just closed out such a project, called HealthMatch, in which everything seemed to go wrong, the organization wasted millions of dollars, and little or nothing remains to salvage.

HealthMatch was an automated system designed to match Minnesota residents with appropriate state-run health programs, based on eligibility. The variety of residents’ needs and situations, together with the complexity of state programs and 16,000 eligibility rules, made this a daunting task.

HealthMatch started in 2002, with a budget of $13 million and anticipated completion date of two years. The project included three main components: a health care system eligibility rules engine, employee workflow, and a client portal for state residents to initiate cases into the system.

A 2003 analysis by the Minnesota Legislative Audit Commission reported that HealthMatch faced problems such as: “income determination errors, DHS’s income estimates not matching actual income, misreported insurance information, and oversight weaknesses”.

Minnesota Public Radio reported:

Programming outsourced to India had so many errors it was scrapped…. A subcontractor with expertise in Medicaid rules dropped out. Three project managers and five deputies cycled through HealthMatch in four years. The Legislature tinkered with eligibility rules. The department dragged its feet on developing system requirements and made changes that required redoing completed computer code.

Almost ten years after the project was conceived, Minnesota has now closed the final chapter and agreed to pay the software developer, Affiliated Computer Services (ACS), $7.25 million, to settle a lawsuit for unpaid invoices. Altogether, the state spent over $41 million on HealthMatch.

SHARED RESPONSIBILITIES

The IT Devil’s Triangle concept tells us that every major software implementation project includes three parties: enterprise customer, system integrator, and software vendors; most failures involve contributions from all three groups. In this case, there was no system integrator, because HealthMatch was a custom product, with the vendor, ACS, presumably responsible for both technical development and integration.

According to a 2007 analysis (PDF download) performed by the Minnesota Legislative Audit Commission, both the Department of Human Services and ACS made significant errors that contributed to this failure. The $7.25 million financial settlement supports this view; Minnesota Public Radio says that, “ACS asked for an additional $19.4 million for partially completed work. The Department of Human Services offered $3 million.”

The 2007 report explicitly describes shared responsibility for problems on this project:

[T]he system’s design was substantially modified twice, and each change lengthened HealthMatch development. However, the project has also repeatedly failed to meet scheduled benchmarks, even when these scope changes are taken into account. In our view, both DHS and its contractor, [ACS predecessor company] Albion, share responsibility for project setbacks.

Despite definite assessment of shared responsibility, the report describes how the parties cast blame on each other:

Although each has accepted some responsibility, DHS and [ACS predecessor company] Albion administrators disagree vehemently over the relative importance of various factors in causing delays….

NUMEROUS POINTS OF FAILURE

in 2008, the Legislative Audit Commission issued another assessment report (PDF download), further examining reasons for delays, cost-overruns, and poor deliverables. The report presents a scathing condemnation of the Department of Human Services, external vendor ACS, and even the core technology underlying the eligibility rules engine.

The 2008 report describes a litany of reasons this project failed; including basic aspects of technology, management, staffing, business requirements definition, and so on. These snippets, from the document, give a flavor for the mismanagement and errors related to HealthMatch:

• DHS received free, perpetual license to use the @Vantage software [PDF download of current @Vantage brochure] upon completion of the design phase of the project. Shortly after the HealthMatch contract began, the vendor dismissed the Fox Systems personnel assigned to the project, thereby severing the relationship with Medicaid experts who had enabled the vendor to meet minimum DHS project qualifications and leaving a significant gap in the requisite skill set.
• The most critical step the team made in assessing continuation options was to come to a recommendation regarding use of the @Vantage rules engine….The analysis findings finding resulted in a unanimous recommendation to pursue…discontinuing use of the @Vantage rules engine and developing a new health care system. This recommendation is predicated on the high risks associated with the @Vantage system in terms of development time frames, ability to meet critical success factors, and alignment with federal, State, and agency strategic IT direction.
• [F]rom a technical viewpoint, some of the @Vantage components have features that are incomplete, error prone, and not always efficient to use. Compounding issues with @Vantage, the vendor implemented HealthMatch with poor quality, a lack of technical management, and times a lack of correct use of @Vantage features.
• Because many HealthMatch requirements were captured in the context of @Vantage limitations, existing requirements need to be reviewed…. Hire Requirements Analysts who possess the skill-set to write and manage changes to requirements.
• Best practices were not being enforced or adhered to consistently across all project management process areas (project governance, planning, schedule, scope, cost, management, quality management, communications management, and risk and issue management.)
• HealthMatch staffing and position descriptions for HealthMatch were not adequately defined or supported to meet business requirements and timelines.
• [D]iscrepancies were found during the assessment between the level of completion that had been indicated in the project plan and the actual findings while analyzing the project artifacts. In some cases [coding] is several versions behind the current design version even though the project plan tasks had been marked at 100% coding completion.

STRATEGIC ANALYSIS

Major failures generally arise as the confluence of multiple issues coming together to form a larger problem. Three foundational elements came together to cause the HealthMatch failure:

1. Undisciplined and inexperienced program management in the Department of Human Services
2. An inconsistent, and probably over-extended, vendor
3. Immature and poor tested technology

Each of these factors is so basic, that weakness in any one could have put the project at significant risk. All three occurring together make HealthMatch appear like an expensive, ill-fated comedy of errors in which failure was inevitable.

Despite spending $41 million, the Associated Press reports that Minnesota DHS, “still uses aging systems developed decades ago and paper applications processed by state, county and tribal workers. It’s a system tailor-made for errors, with one audit finding rates of improper denials and approvals of 10 to 14 percent.”

In addition, this past Friday, a Minnesota lawmaker introduced a billdirecting “the Minnesota Department of Human Services to find a contractor to develop software that would match applicants for health care, welfare and food stamps with the appropriate programs.” Déjà vu, anyone?

Advice to CIOs: Significant and chronic problems, such as those experienced on HealthMatch, usually indicate deep structural issues on a project. In such cases, completely restarting the project may be the best solution, despite the immediate costs and political challenges. Although recommending termination of a strategic project is difficult, wise CIOs take decisive action before a situation escalates out of control.

Innovative CIOs collaborate with lines of business, including their organization’s CFO, to place long-term objectives above parochial local politics. While this may create short-term anxiety, it is the right thing to do and ultimately separates ordinary CIOs from those who are truly great.

Source : http://www.zdnet.com/blog/projectfailures/minnesota-healthmatch-a-perfect-storm-for-it-failure/12648

A Success Story of Teamwork and Cooperation - Dabbawala System

In Mumbai, India, the Dabbawalas, also known as Tiffinwalahs, continue to deliver thousands of home cooked meals feeding hungry office workers and students. The Dabbawala system is an example of a very successful system that has been in place for decades through sheer ingenuity, cooperation and teamwork. With little cost and no sophisticated technology, the system has proven effective in meeting client requirements.
In 1998, Forbes Global magazine, conducted a quality assurance study on the Dabbawalas' operations and gave it a Six Sigma efficiency rating of 99.999999; the Dabbawalas made one error in six million transactions.

Watch Video Here

Source: http://www.icmrindia.org/casestudies/catalogue/Leadership%20and%20Entrepreneurship/Mumbais%20Dabbawalas-An%20Entrepreneurial%20Success%20Story-Leadership%20and%20Entrepreneurship.htm

Digital City

Information Communication and Culture Minister Datuk Seri Dr Rais Yatim has announced the development of the Digital City to prepare Malaysia as a supplier of digital services by 2015. He said the project, to be developed on a 5.66-hectare site in Angkasapuri, had recently been approved by the Cabinet and awaiting discussions with the Economic Planning Unit (EPU). The plans are to have the best media facilities and radio and television broadcasts in the country. He dubbed the project as the most sophisticated information and communications technology (ICT) project which would work towards realising Malaysia’s goal of becoming the best digital services provider in the region.

So what is a digital city, really? Let us look at what Wikipedia has to say.

The term Digital Community or Digital City (Smart Community, information city and e-city are also used) refers to a connected community that combines broadband communications infrastructure; flexible, service-oriented computing infrastructure based on open industry standards; and innovative services to meet the needs of governments and their employees, citizens and businesses.

While wireless infrastructure is a key element of Digital City infrastructure, it is only a first step. The Digital City may require hard-wired broadband infrastructure, and it is much more than just the network. A Digital City provides interoperable, Internet-based government services that enable ubiquitous connectivity to transform key government processes, both internally across departments and employees and externally to citizens and businesses. Digital City services are accessible through wireless mobile devices and are enabled by services oriented enterprise architecture including Web services, the Extensible Markup Language (XML), and mobilized software applications.

Interesting concept indeed. Wikipedia seems to define it more from the perspective of service delivery via G2G (Government to Government), G2B (Government to Business) and G2C (Government to Citizen). Its’ objective is more focused towards meeting the needs of governments and their employees, citizens and businesses.

Let us look at other views of Digital City.

According to Giovanni and Juliano (2007), there are different levels of urbanization for digital cities which are classified from both technological and social aspects. The six levels are described as follows, in ascending order:

1. Cities with Basic Access

This is the lower level in the development of a digital city. Under this condition, a telecommunications services infrastructure is available, though limited in access points and bandwidth. There is no Internet

Service Provider (ISP) and the connections are achieved through calls made from conurbation areas or long distance calls at low transmission rates, which stands as a barrier to the access to the informational society.

2. Cities with Telecenters

At this level, ISPs and telecenters for public access to the Internet are available. These services also provide minimum accessibility resources, such as appropriate facilities for wheel-chair users. However, the number of telecenters is limited and band restrictions are found either in access – dial-up connections are the most commonly used – or backbone.

3. Cities with e-Services

The cities already have total public access coverage, i.e., telecenters are found all around its area and can be easily reached by the population. Bandwidth restrictions are still found in terms of access and backbone, although minimum accessibility, usability, and intelligibility resources are available. This leads to a decrease in access barriers for people with low literacy level or with some kind of disability. The ICT access brings to the population a few public and private services in a virtual environment.

4. Pre-integrated Digital Cities

In this stage, there is total coverage and unlimited bandwidth for public access. In addition, the city can already be considered as a digital city, as defined in this paper. The public services are integrated into a single virtual environment, which comprises an e-government platform that integrates all spheres and powers. Both telecenters and public services provide a reasonable set of accessibility, usability, and intelligibility resources. This aspect poses greater challenges to the idealizers of this initiative, mainly in the development of technologies and applications that may arouse the interest of a culturally heterogeneous population bearing different literacy and ICT mastery levels. This kind of city provides a few private services in a virtual environment.

5. Integrated Digital Cities

It is characterized by a high level of digitalization, with global coverage either for public and individual access. Instead of a portal for each service or application, in this kind of city, services are integrated, namely the public ones. Moreover, meaningful quantities and diversity of accessibility, usability, and intelligibility resources are available. A wide range of private services in virtual environment are also provided. Intra-urban communities are integrated. It allows the effective use of ICT by the population as well as cultural benefits and active citizenship, including a new public space.

6. Fully Developed Digital Cities

In addition to all the improvements found in the other levels, in this level the cities include all digital resources allowed by the current social, economic, political, and technological arrangements. In this stage, the digital city reflects what is available in its real counterpart; obviously within a context of immateriality, allowing going further in a few features of the cyber world. The new basis for communication broadens its scope of action, counting on interconnected communities and cities in an extra-urban sphere. Both public and private services, now fully integrated, create a virtual space overlapping the real, material city. This effectively characterizes a new concept of urban coexistence. The new ICT are then a part of the buildings that give shape to the city: silicon chips and software are literally mixed to bricks, steel and concrete.

Now that is really an interesting concept for a digital city. One can only imagine the potential services that can be provided within a fully developed digital city and the various benefits that entails.

Will we be able to see our cities evolve into fully developed digital cities one day?

The Government CIO 50: Vision, Influence, And Results

The top IT execs in federal, state, and local government are using new technologies and hands-on project management to drive change in the public sector.


By John Foley,  InformationWeek 
March 3, 2011
URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=229300142 

What makes for a top CIO in government? There’s no one-size-fits-all answer, but technology vision, clout among peers in other agencies, and an ability to show tangible, measurable results are qualities common to the Government CIO 50, InformationWeek’s second recognition of leading CIOs in federal, state, and local government.


The public-sector IT execs on our list often do those things with one hand tied behind their backs. Their budgets, especially at the state and local levels, tend to be flat or declining. Antiquated systems devour their limited resources. And entrenched processes and bureaucracies can stymie their best IT transformation ambitions.


The Government CIO 50 are finding ways to plow through such obstacles in their pursuit of higher returns. One of the CIOs on our list, Roger Baker of Veterans Affairs, uses metrics-driven reviews to assess IT initiatives at the agency, making adjustments where needed and pulling the plug on others. At the General Services Administration, CIO Casey Coleman introduced Gmail and Google Apps, saving the agency an estimated 50% on e-mail costs over the next four years.


Some of the Government CIO 50, such as Federal CIO Vivek Kundra and Federal CTO Aneesh Chopra, are known for their far-reaching policy influence. Others have lower public profiles, but are heavy hitters in their own right. Al Tarasiuk, the former CIO of the CIA, was recently named CIO of the U.S. Intelligence Community, where he’s developing standards and an IT architecture for information sharing across the 17 agencies and organizations that comprise the coalition.


Our list includes IT leaders who are driving change in local and state government, such as New York City IT commissioner Carole Post, who is managing the consolidation of the Big Apple’s data centers and IT infrastructure, while introducing new desktop tools and cloud services for city employees.


Government agencies have long been a step behind the private sector in technology adoption -- Kundra calls it as the “tech gap” in government. Many of the CIOs on our list are taking steps to change that by deploying a newer generation of tools, including smartphones, software as a service, VoIP, and the latest Web and collaboration software.


For years, government CIOs have taken on big, complex IT projects that all too often buckle under their own weight. The Gov 50 are shifting away from long-term, monolithic IT projects to faster, nimbler ones. FBI CIO Chad Fulgham, for example, is applying agile development to hustle the agency’s delayed Sentinel case-management system to the finish line.


In federal government, the expectations on agency CIOs keep piling up: the Open Government Directive, the Federal Data Center Consolidation Initiative, cloud computing mandates, TechStat project reviews, the shift to continuous monitoring for cybersecurity. What more could possibly be required of them? In December, Kundra introduced a 25-point IT reform plan to be carried out over the next 18 months. The CIOs on our list aren’t just first-class leaders; they must be great managers, able to juggle priorities and meet deadlines.

Lahirnya Sebuah Projek IT - mulanya tugas seorang pengurus projek

“Assalamualaikum Boss.” Jo menyapa sambil menarik kerusi di hadapan Azman dan terus duduk. “Terima kasih banyak-banyak Boss di atas kenaikan pangkat saya ini. Saya tak sangka tuan memilih saya untuk jawatan ini.” 

“Waalaikumussalam. Tahniah Jo. Bukan saya yang naikkan pangkat awak. Itu rezeki awak. Saya ni hanya menyediakan laporan prestasi awak tetapi yang memberi rezeki ialah Allah. Prestasi awak yang cemerlang dan konsisten selama ini telah membuahkan hasil. Sekarang awak telah dinaikkan pangkat. Saya harap awak boleh melaksanakan tugas dalam jawatan baru ini sebagai PM yang baik.”

Azman bangun sambil menghulurkan tangan kanannya kepada Jo untuk berjabat tangan. “Baguslah sekarang saya ada seorang lagi PM untuk membantu saya. Ringanlah sedikit tugas saya.” ujar Azman tersenyum bangga sambil merenung mata Jo yang bersinar-sinar kegembiraan. Jo faham siapa yang Azman maksudkan dengan PM. Syukri dan Rosni dipanggil dengan nama PM, iaitu gelaran ringkas untuk Project Manager.

“Aku sekarang dah jadi PM. Cayalah! Tak jadi Perdana Menteri pun orang panggil aku PM. Oh, bangganya aku!” bisik hati Jo sendirian sambil mukanya melakar senyum lebar.

“Kena pada masanya Jo. Semalam saya dapat arahan daripada Dato’ untuk  melaksanakan satu sistem baru. Saya dah tenggelam punca nak pilih pegawai mana untuk menguruskan projek ini kerana kedua-dua PM kita sedang sibuk menyiapkan projek masing-masing. Tinggal lagi dua bulan sahaja dan semua projek perlu disiapkan dalam tahun ini juga. Saya rasa awaklah yang paling sesuai untuk menjadi PM bagi projek ini.”

“Projek apa tuan?” Jo terpinga-pinga bertanya kepada Azman.

“Projek ni ada kaitan dengan masalah kutipan hasil jabatan. Kita yang perlu cadangkan skop dan sistem untuk projek ini supaya masalah tersebut dapat diselesaikan” Azman menjawab tenang.

Gementar Jo dibuatnya. Kegembiraan yang baru dirasakan sebentar tadi telah lenyap dalam sekelip mata. Jo tidak pernah memegang projek sistem IT sebelum ini. Dia bukan pegawai pembangunan aplikasi tetapi pegawai operasi. Dia hanya pandai buat kerja penyelenggaraan mesin.  Apabila komputer menghadapi masalah dialah doktor yang mencari punca penyakit dan memberi ubat kepada masalah tersebut. Memang Jo lah pakar dan orang yang diharapkan oleh rakan-rakannya untuk menyelesaikan masalah operasi mereka.

Mengimbas kembali sepanjang tiga tahun dia bertugas di Unit Operasi, Jo tidak pernah membina aplikasi. Namun setelah dinaikkan  pangkat Jo ditugaskan untuk menjadi PM kepada projek aplikasi. “Mampukah aku buat kerja ni? Kalau jadi PM untuk Operasi tak apalah. Tapi aku tiada pengalaman dalam aplikasi. Aku tak tahu macam mana nak jadi pengurus projek. Yang paling lemah sekali aku tak tahu macam mana nak berurusan dengan pelanggan.” keluh Jo sendirian sambil mengesat peluh dingin didahinya.

“Projek ini sangat penting untuk Dato’ sebab dia mahu lihat projek ini siap sebelum bersara. Kita diberi masa 6 bulan sahaja. Kita perlu bekerja keras dan buktikan bahawa projek IT boleh siap cepat. Jo, jangan bimbang kalau tak pernah buat kerja ni. Saya akan bimbing awak, InsyaAllah. Mula sekali kau kena buat kertas kerja untuk dibentang kepada Dato’. Saya beri awak masa 2 minggu, boleh? Jumpa saya kalau ada apa-apa masalah.” ujar Azman.


Begitulah sebuah kisah dimana seorang pengurus projek menerima tugasan baru. Idea sesuatu projek IT boleh tercetus apabila terdapat arahan dari pemegang kepentingan(stakeholder), permintaan pengguna atau cadangan dari Unit IT; samada untuk menjadikan sesuatu proses lebih efisyen, memperkenalkan servis baru, menyelesaikan masalah yang tidak boleh diselesaikan secara manual atau semata-mata untuk memperbaiki proses kerja dalam organisasi.

Arahan mungkin datang daripada peringkat atasan ataupun diketengahkan oleh pengguna atau dicadangkan oleh Unit IT:

• .     Dari peringkat pengurusan atasan ke peringkat bawahan
• .    Dari peringkat bawahan ke peringkat pengurusan atasan
• .     Dari Unit IT kepada peringkat pengurusan atasan

Dari Peringkat Atasan ke Bawahan

Idea projek boleh tercetus apabila menerima arahan dari pengurusan atasan atau keputusan yang dibuat di peringkat lembaga pengarah atau mesyuarat pengurusan. Sebagai contoh, Ketua Jabatan atau Ketua Pegawai Eksekutif memberi arahan kepada Unit IT untuk melaksanakan sesuatu sistem IT. Lanjutan itu, pegawai di Unit IT akan  mengambil tindakan susulan untuk mengkaji keperluan dan cuba memahami dengan lebih mendalam keperluan dan harapan pihak berkenaan.

Dari Peringkat Bawahan ke Peringkat Atasan

Pengguna yang menghadapi sesuatu masalah dalam operasinya akan membuat permohonan untuk mengujudkan sesuatu sistem IT dengan harapan sistem dapat membawa jalan penyelesaian. Permintaan mungkin dibuat terus kepada Unit IT atau diketengahkan dalam mesyuarat untuk tindakan Unit IT.

Dari Unit IT ke Peringkat Atasan

Unit IT mungkin membuat cadangan pelaksanaan sesuatu sistem berdasarkan kajian terhadap keperluan sesuatu unit atau organisasi. Dalam situasi ini, kajian rapi perlu dijalankan bagi mendapat kepastian dan sokongan pengguna dan juga menyakinkan pihak pengurusan atasan.

Mengenalpasti keperluan

Sekiranya anda ialah pegawai atau individu yang ditugaskan untuk melaksanakan tugas tersebut maka anda perlu bersikap profesional dalam mengenalpasti keperluan, tanpa mengira dari peringkat mana arahan diterima. Tindakan pertama yang perlu diambil ialah mengenalpasti apakah keperluan utama projek.

Cadangan projek dikonsepsikan dengan cara menentukan matlamat, objektif projek, skop keperluan, siapa pemegang kepentingan, siapa pengguna utama dan output yang perlu dihasilkan (pengeluaran). Setelah aspek tersebut ditentukan, maka barulah dapat ditentukan skop projek dan dibuat anggaran mengenai kos dan tempoh masa yang diperlukan untuk menyiapkan projek. Maklumat ini hendaklah didokumentasikan dalam dokumen yang dikenali sebagai kertas projek, kertas konsep, atau Pelan Projek.

Proses ini adalah mirip proses membina sebuah rumah, dimana tuan punya rumah perlu terlebih dahulu menceritakan impian rumah yang ingin dimilik kepada arkitek, tentang rekabentuk dan kapasiti rumah tersebut; khususnya keluasan, jumlah bilik, jumlah tingkat, bilangan penghuni dan bajet yang diperuntukan. Setelah proses tersebut selesai barulah arkitek dapat menyediakan lukisan ilustrasi bangunan dan membuat anggaran keatas kos dan masa yang diperlukan untuk membina rumah tersebut. Susulan itu, barulah pelan struktur binaan dapat dihasilkan lengkap dengan deskripsi struktur, kemasan dalam dan kemasan luar serta anggaran kos pembinaan.

Pentakrifan Projek

Pentakrifan Projek ialah proses untuk mengkaji, menganalisa dan menkonsepsikan projek yang dicadangkan. Definisi atau takrif projek perlu ditetapkan di permulaan projek bagi mendapat maklumat asas tentang projek yang bakal dilaksanakan. Berdasarkan maklumat ini, kajian keperluan dan perancangan secara terperinci akan menyusul.

Pada kebiasaannya, arahan disampaikan oleh pihak atasan dengan idea yang samar-samar. Mereka mungkin mempunyai sesuatu impian atau visi tetapi kurang pasti tentang apakah yang perlu dilakukan. Oleh itu, ianya perlu difahami dan diperhalusi oleh pegawai yang menerima tugas tersebut.

Apabila jabatan atau syarikat menghadapi sesuatu kemelut atau isu maka ketua jabatan atau ketua eksekutif akan meminta pegawainya mencari penyelesaian. Jika Unit IT diarah untuk mencadangkan penyelesaian maka itu bermakna Unit IT diberi tanggungjawabkan untuk mengkaji dan membuat sesuatu cadangan projek.  Maka adalah menjadi tugas pegawai untuk mengambil langkah untuk memulakan aktiviti pentakrifan projek.

Bagaimana membuat pentakrifan?

Berikut adalah 6 langkah yang perlu diikuti:

1.     Kenalpasti masalah yang perlu diselesaikan – Apakah latarbelakang situasi semasa? Apakah masalah atau isu yang sedang dihadapi yang membawa kepada cadangan projek.

2.    Tetapkan matlamat, objektif dan skop projek –

a.  Matlamat - Apakah harapan yang diidamkan/dibayangkan?

b.  Objektif - Apakah usaha-usaha yang perlu dilakukan untuk mencapai Matlamat?

c.   Skop - Apakah hasil yang diharapkan daripada projek ini atau matlamat masa depan?

3.    Senaraikan semua hasil pengeluaran atau output projek - Apakah  output yang perlu dihasilkan untuk mencapai matlamat projek?

4.    Kenalpasti fungsi-fungsi yang akan mengeluarkan output tersebut.

5.    Tentukan anda jelas yang manakah fungsi “Perlu” berbanding fungsi “Mahu” - Apakah perkara-perkara atau fungsi-fungsi yang “wajib” ada, berbanding yang “harus” ada.

Hanya setelah proses mengenalpasti keperluan ini selesai, maka langkah seterusnya ialah untuk menyusun dan mengolah semua maklumat ini dalam satu kertas kerja atau Pelan Projek.

Apa itu Projek? - pengenalan asas kepada Projek

Terdapat beberapa definisi atau takrif kepada perkataan “Projek”. Salah satu definisi yang agak menarik ialah yang dibuat oleh Project Management Institute atau ringkasnya PMI. PMI ialah antara organisasi profesional yang terulung di dunia dalam bidang pengurusan projek. Ianya dianggotai oleh para Pengurus Projek Profesional yang pada masa ini mempunyai keahlian melebihi setengah juta daripada lebih 170 negara diseluruh dunia. Ianya mempunyai ibu pejabat di Amerika Syarikat dan merupakan badan yang sangat berpengaruh dalam mempelopori kaedah dan piawaian dalam bidang pengurusan projek.

Menurut definisi PMI dalam Project Management Book of Knowledge PMBOK@Guide :

"A Project is a temporary endeavour undertaken to create a unique product or service”

Bermaksud:

Sesuatu projek adalah satu usaha sementara yang dilaksanakan untuk mencipta satu produk atau perkhidmatan yang unik.

Menurut definisi ini projek merupakan suatu usaha sementara kerana ianya terikat kepada suatu tarikh permulaan dan penamat. Segala aktiviti yang dijalankan bertujuan untuk menghasilkan sesuatu hasil kerja atau deliverable seperti barangan atau perkhidmatan.

Selain itu, terdapat pula definisi projek yang lebih ringkas daripada Kamus Webster iaitu:

“Project is a planned undertaking”

Bermaksud: 

Projek adalah tugasan yang terancang.

Ringkasnya, dalam bahasa yang mudah difahami; projek adalah suatu tugasan atau usaha yang dirancang untuk menghasilkan sesuatu produk atau perkhidmatan yang diinginkan.

Sesuatu tugasan dianggap sebagai suatu projek jika mempunyai tiga komponen berikut:

•  keperluan spesifik yang perlu dipenuhi – objektif, ekspektasi dan produk/perkhidmatan yang perlu dihasilkan,
•  mempunyai tempoh pelaksanaan tertentu – tarikh mula dan tarikh siap ditetapkan, dan
• Bajet - sumber kewangan untuk menanggung kos sumber manusia, pembelian peralatan, bahan, servis, dan semua kos yang perlu dibelanjakan untuk menyiapkan projek.

        

Komponen Projek

Contoh projek ialah:

•         membina bangunan rumah, sekolah, jambatan atau pejabat
•         projek pembuatan seperti pengeluaran kereta atau barangan
•         pembangunan sofwer untuk Sistem Perakam Keluar Masuk Pejabat
•         penyediaan Pelan Pemulihan Malapetaka (Disaster Recovery Plan)

Kadangkala kita keliru antara projek dengan tugasan yang dilakukan setiap hari. Tugasan harian seperti melayan pelanggan, menjawab surat-surat yang diterima, menjilidkan surat dalam fail, membuat penyelenggaraan sistem dan lain-lain kerja berulang adalah aktiviti-aktiviti yang berjalan secara rutin setiap hari. Walaupun aktiviti tersebut perlu dilakukan untuk mencapai sesuatu tujuan, namun ianya tidak terikat dengan tarikh mula dan tarikh siap, malah tidak memerlukan sejumlah bajet yang diperuntukan khas untuk menyiapkan tugasan tersebut.         

               

Contoh aktiviti bukan projek ialah:

•         Membuat salinan backup sistem setiap hari
•         Membersihkan bangunan pejabat setiap minggu
•         Menyusun buku di perpustakaan
•         Merekodkan dan memfailkan surat-surat kedalam fail

Projek seumpama makhluk hidup yang mempunyai kitaran hayat, bermula dari peringkat kelahiran, kemudian terus ke peringkat perancangan dan memuncak dengan peringkat pelaksanaan sehingga akhirnya peringkat penutup.  Peringkat atau fasa-fasa yang berturutan ini dikenali sebagai Kitaran Hayat Projek atau Project Lifecycle.

Kitaran hayat projek

                            

Sumber: Clifford F. Gray & Erik W. Larson. (2006). Project Management the Managerial Process. (3rd ed.) McGraw Hill.

Auditors: $43M wasted on failed K Basin project

A failed project planned to treat Hanford's K Basin radioactive sludge cost $43 million without producing any results, according to an audit by the Department of Energy's Office of Inspector General.

The audit released Tuesday blamed problems on a rush to do the work to meet legal deadlines without first figuring out if the project's technology could be safely used and would work.

The project was canceled in 2007, but not before $43 million was spent over three years on engineering and equipment.

Four years later, DOE has a new strategy for cleanup of the sludge, but the work still is in the design phase, and the audit concluded it was too soon to evaluate the new plan's effectiveness.

However, the projected cost to taxpayers has significantly increased, the audit found.

Previous DOE contractor Fluor Hanford estimated it would cost $104 million to retrieve the sludge from the K Basins, process it, package it and ship it to the Waste Isolation Pilot Plant in New Mexico for disposal.
Now CH2M Hill Plateau Remediation Co. estimates it will cost almost $175 million to move the sludge from the K Basins, which are 400 yards from the Columbia River, to another facility. That estimate does not include the cost to store the sludge at the interim facility, nor to treat and package it for disposal, according to the audit.

The audit did recognize that "this project addresses a complicated, one-of-a-kind waste with uniquely challenging nuclear chemistry, and that managing a project of this magnitude and complexity ... is no easy matter."

At the end of the Cold War, fuel irradiated to produce plutonium for the nation's nuclear weapons program was left unprocessed in water cooling basins attached to the K East and K West reactors. The fuel corroded and formed a radioactive sludge at the bottom of the pools.

The last of the fuel was removed in 2004 and the sludge is being held in underwater containers at the K West Basin.

The year the fuel was removed, Fluor subcontracted with British Nuclear Group America to design and make a modular system called the Contractor's Stabilization and Packaging System to retrieve the sludge, treat it and grout it in 55-gallon drums, according to the audit.

The audit found DOE did not manage the project well, nor did it ensure that Fluor and its subcontractor adequately managed the project.

Instead of using one of five mature technologies outlined in a Pacific Northwest National Laboratory study, British Nuclear chose to heat the sludge to oxidize the uranium to allow it to be shipped and disposed.
The oxidized sludge then was to be grouted and packaged using a commercially available system selected by DOE and contractor officials that had been used in Europe to process low-activity radioactive waste, the audit said. However, the Hanford sludge was much more radioactive and required remote handling to protect workers.

The complex treatment equipment for the system was expected to require a long time to purchase and manufacture. To meet the project schedule, DOE agreed to let Fluor begin to purchase equipment before the design was completed or a preliminary safety analysis had been approved, the audit said.
With money already being spent, British Nuclear commissioned an independent study in 2005 to identify areas of concern. The panel performing the study said it was concerned about the chemistry of the sludge and the use of high temperature and pressure to oxidize the uranium because the process had not been demonstrated on a small scale.

Months later, a laboratory scale test was performed by Pacific Northwest National Laboratory. It found in 2007 that the treatment adversely affected the chemical and physical properties of the sludge. But by that time the system had been constructed.

The project was dropped in 2007 when DOE concluded the system posed risks to workers during normal operations and could pose a risk to the public in an accident. Fixes to the system would be too expensive, DOE decided.

The audit said DOE should have required an analysis of potential solutions for packaging the waste, rather than settling on the European commercial system. Once it had selected the system, it should have performed a feasibility study and done laboratory testing sooner, the audit found.

Fluor Hanford said in a statement Tuesday that it diligently worked with DOE and other parties to ensure it met the project's objectives as efficiently and effectively as possible and ensured worker safety.

Fluor said that as it analyzed the chemical and radioactive makeup of the sludge, regulatory requirements and disposal options changed.

The audit also questioned whether a $1 million subcontract payment made to British Nuclear was appropriate given the failure of the project and if it was approved by DOE.

Although British Nuclear was interested in purchasing the commercial portion of the system, it was turned over to DOE and remains unused, the audit said. DOE spent about $5 million on that equipment.

DOE agreed with recommendations for management improvement in the audit, and that it look at recovering the $1 million plus interest.

The DOE Office of Environmental Management has taken steps to improve management across the DOE complex in recent years, it told the DOE Office of Inspector General. The audit acknowledged that many process improvement initiatives are under way.

"These reforms, once fully implemented, should increase the likelihood of successful project execution," the audit said.



Read more: http://www.thenewstribune.com/2011/02/23/v-lite/1555869/auditors-find-failed-project-wasted.html#ixzz1FQGFeTBN