Terbukti, Taktik Praktis Untuk Manajemen Rilis TI Agile – Sebuah Studi Kasus

Ringkasan:

Artikel ini adalah yang pertama dalam rangkaian lima yang akan menjelaskan bagaimana organisasi TI menyampaikan proses manajemen rilis yang melampaui harapan manajemennya dan memberikan landasan untuk kesuksesan yang berkelanjutan. Serial ini termasuk:

1. Bagaimana kita sampai di sini – KONTEKS

2. Langkah-langkah solusi pertama – DEFINISI DAN TRIAGE

3. Perencanaan Intake and Release – SOLUSI INTI

4. Kontrol Perubahan Produksi – PENGENDALIAN KUALITAS FINAL

5. Metrik dan Wawasan – PELAJARAN YANG DIPEROLEH

Ringkasan:

Banyak organisasi Teknologi Informasi menggelepar ketika mereka ditugaskan untuk memahami, mengatur, dan menerapkan banyak perubahan pada sistem dan perangkat lunak aplikasi yang melayani klien dan pelanggan akhir mereka selama beberapa tahun. Artikel ini menjelaskan pada tingkat tinggi kerangka kerja dan proses rasa praktis dan umum yang berhasil menaklukkan masalah untuk satu perusahaan dan tim TI. Seberapa sukseskah kerangka ini? Terus terang, metrik TI adalah elemen yang berbahaya dan tidak jelas untuk dibahas secara ilmiah. Tetapi organisasi ini mencapai hal-hal berikut:

– Dalam satu tahun, ia meningkatkan peringkat kepuasan kliennya dari 2,5 menjadi 4,0 pada skala 5 poin.

– Dalam satu tahun, ia mengirimkan 85% lebih banyak permintaan perubahan dan proyek ke dalam produksi daripada dalam 12 bulan sebelumnya.

– Organisasi melampaui target peregangannya sendiri untuk throughput dan mengubah waktu siklus permintaan sebesar 40%.

– Mencapai hasil ini tanpa menambah jumlah pegawai dan tidak ada pengeluaran untuk "perkakas" TI.

– Itu meningkatkan anggaran biaya TI sebesar 3,2% untuk menutupi biaya konsultan tunggal untuk instantiate kerangka kerja dan proses untuk manajemen rilis lincah.

Apa saus rahasia untuk membuat pencapaian ini mungkin? Jawabannya mengharuskan kita mempertimbangkan dengan seksama konteks untuk organisasi ini.

Konteks:

Perusahaan dan departemen TI dapat dicirikan sebagai berikut:

Perusahaan

– Industri – telekomunikasi – satu segmen dari Regional Bell Operating Company yang sangat besar

– Produk Utama – layanan pesan suara dan fitur tambahan

– Basis konsumen – 4 juta akun konsumen dengan perkiraan pertumbuhan 25%

– Jumlah total pegawai perusahaan – sekitar 500 orang

– Operasi utama – call center 24X7 dari 300+ orang yang menjual dan melayani konsumen pada produk dan fitur voicemail

– Hasil Finansial – Batas Laba Line-of-Business Tinggi dalam struktur perusahaan yang sangat besar

– Semua orang bekerja di gedung yang sama

Organisasi TI

– Staf TI – sekitar 60 – kebanyakan dengan 2-10 tahun sejarah organisasi

– Berfungsi secara fungsional – Operasi, Manajemen dan Analisis Proyek, Pengembangan Sistem, QA dan Help Desk, Manajemen Konfigurasi

– Aplikasi – 7 subsistem rumah tangga utama yang melayani operasi langsung perusahaan

– Fungsi SDM / Keuangan / Perusahaan dilayani oleh orang tua dan proses perusahaan, dengan antarmuka

– Teknologi – bahasa terkini, sistem operasi, dan infrastruktur teknis (perangkat keras, jaringan, DBMS)

– Perbaikan yang baru saja dipasang:

– Perangkat manajemen, staf, dan proses Konfigurasi Perangkat Lunak

– Masalah utama yang dirasakan – tidak ada kontrol efektif dari perubahan yang diserahkan ke produksi

– Semua orang bekerja di lantai yang sama

Kekuatan

– Pendapatan yang kuat dan terus bertambah

– Manajemen Perusahaan – umumnya sangat berpengalaman dalam manajemen call center dan proses peningkatan produk

– Manajemen TI – 80% memiliki lebih dari 4 tahun dalam organisasi ini dan sangat sedikit perubahan, hanya 2 tingkat manajemen TI

– Proses IT yang matang dan sukses termasuk:

– Manajemen proyek

– Pengujian Jaminan Kualitas

– Beberapa manajer TI yang kuat mendukung Pengelolaan Rilis yang lebih baik

– Ko-lokasi TI dan klien langsung – manajer fungsi bisnis

Kelemahan

– Manajer perusahaan menegosiasikan kesepakatan pribadi untuk mendapatkan permintaan perubahan dan proyek yang dipasang "sebelumnya"

– Tidak ada clearinghouse pusat untuk mengadili permintaan departemen untuk perubahan TI

– Tidak ada sistem pelacakan untuk memperhitungkan semua permintaan perubahan dan proyek yang diminta dan dikirim

– Sekitar 325 permintaan / proyek diyakini sedang dimainkan

– Proses pengambilan dan kontrol / pelacak serampangan untuk permintaan perubahan "kecil"

– Programer dapat secara mandiri menerapkan perubahan aplikasi ke produksi

– Tidak ada titik kontak / komunikasi antara organisasi TI untuk setiap permintaan perubahan kecil

– Status saat ini dan tanggal implementasi target dari permintaan perubahan tunggal sulit untuk mendapatkan / pin down

– Perubahan operasi TI benar-benar independen dari kontrol perubahan organisasi dan dipandang sebagai gangguan

Peluang

– Kesempatan baru untuk mengkonsolidasikan dan berbagi informasi tentang segala sesuatu di piring IT di satu tempat

– Kesempatan untuk memanfaatkan pengetahuan dan kematangan staf TI yang ada

– Kesempatan untuk mengurangi sifat awal / berhenti kerja TI karena masukan yang bersaing dan penuh semangat dari manajer perusahaan

– Kesempatan untuk memasukkan perubahan infrastruktur TI dari Operasi secara terencana

Ancaman

– Pengembang perangkat lunak menginginkan toolware baru – bukan proses manajemen yang lebih banyak

– Manajer bisnis perusahaan menikmati panggilan tembakan langsung dengan sumber daya pemrograman

– Ketegangan antara manajer TI pada apa yang merupakan jalur terbaik untuk peningkatan organisasi

– IT telah gagal pada upaya pertamanya tahun sebelumnya di proses Perubahan Kontrol dan Manajemen Rilis

– Konsultan jarang menambahkan nilai

Kesimpulan / Transisi

CIO, yang menghadapi situasi ini, setuju untuk mengizinkan Manajer Manajemen Proyek dan Analisis untuk mengontrak sumber daya untuk menerapkan Manajemen Rilis (Versi 2). CIO percaya bahwa dia dapat memberikan hasil yang lebih baik kepada konstituensinya dengan menerapkan perubahan dalam serangkaian peningkatan paket aplikasi yang dipahami dengan baik pada interval reguler. Dia juga ingin membawa kembali kepada rekan-rekannya rencana yang dapat mereka pahami dan gunakan untuk mempengaruhi secara langsung urutan implementasi untuk perubahan mereka. Manajer PM menahan saya sebagai Manajer Rilis dengan mandat untuk melembagakan proses dan kontrol yang diperlukan, dan melibatkan semua staf TI dan Wakil Presiden di departemen bisnis sesuai kebutuhan untuk sukses.

Sisanya, kata mereka, adalah sejarah "gesit". Untuk mempelajari apa yang benar-benar dibutuhkan, kisah kami berlanjut dengan DEFINISI dan LINGKARAN berikutnya.