END 418 Proje Yönetimi Bahar Proje Yürütme Süreçleri - Yrd. Doç. Dr. Bülent Gümüş

END 418 Proje Yönetimi Bahar 2016

- Proje Yürütme Süreçleri -

Projenin Sınırı ve Proje Yönetim Süreç Grupları

Proje Yürütme (İcra) Süreç Grubu

Projenin Yürütülmesinin Yönlendirilmesi ve

Yönetilmesi

Kalite Kontrolleri

Proje Ekibinin Oluşturulması

Proje Ekibinin Geliştirilmesi

Proje Ekibinin Geliştirilmesi

Proje Ekibinin Geliştirilmesi

Motivasyon

Proje Ekibinin Geliştirilmesi

Motivasyon

Proje Ekibinin Geliştirilmesi

Motivasyon

Proje Ekibinin Yönetilmesi

Proje Ekibinin Yönetilmesi

Bilgilerin Dağıtılması

Olay günlükleri (Issue Logs) Tutulur.

Paydaş Beklentilerinin Yönetilmesi

Paydaş Beklentilerinin Yönetilmesi

Tedariklerin Yürütülmesi/Gerçekleştirilmesi

END 418

Proje Yönetimi

Proje İzleme (Monitoring) ve

Kontrol Süreçleri

İzleme ve Kontrol Süreçleri

Proje İzleme

• Proje İzleme: Proje yöneticisinin veya diğer paydaşların,

projenin performansı ile ilgili bilmek istedikleri bilgilerin

.

• Proje izleme, proje kontrolü değildir! Ama, etkin kontrol için bilgi (izleme sayesinde elde edilen) elzemdir!

• Kontrol – İzlemeden elde edilen bilgi ile gerçekleşen

performansı planlanana yaklaştırmak

• Planla – İzle – Kontrol

Proje İzlemenin Amaçları

• Birincil amaç proje kontrolüdür!

– Karar vericilere zamanında bilgi verilmesi ile etkin proje kontrolüne destek vermek

• İkincil amaçları:

– Proje teftişi (Audit)

– Alınan dersler (Lessons learned)

Tahmin edip izleyebileceğiniz şeyler…

• Maliyet

• İşin büyüklüğü

• Kalite

• Takvim

• Güvenilirlik (Reliability)

• İnsan kaynakları

• vb.

Plan – İzle – Kontrol Süreci

• Etkin izleme ve kontrol, iyi bir planlama ile başlar

– Kritik alanlar nelerdir?

• İzlemeye değecek kadar önemli olan neler var?

– İlerleme nasıl ve ne zaman ölçülebilir?

• Bazıları devamlı bazıları ise sadece kilometre taşlarında ölçülebilir.

– Bilgileri kim toplayacak ve kime sunacak?

• Projelerde, plan-izle-kontrol döngüsü proje

İzleme Sisteminin Tasarımı

• 1. Kontrol edilecek anahtar faktörlerle başla

– Tabii ki performans, bütçe ve zaman izlenecek. Ama bunların hangi yönleri ve nasıl izlenecek ve kontrol edilecek?

– Pareto analizi: proje başarısının büyük bir kısmını göreceli az miktardaki aktiviteler belirlerler

– İzlenecek kalemleri belirlemede proje planı kullanılır (ör., takvim ve riskler)

• 2. Ölçme sistemini geliştir

– Aktiviteleri değil, sonuçları ölç – Girdileri değil, çıktıları ölç

– Takımın ne kadar çalıştığı değil, ne kadar başardığını ölç

İzleme Sisteminin Tasarımı (devam)

• 3. Veri Toplaması:

– Ne zaman toplanacak? Belirli olaylarda mı, periyodik olarak mı?

– Özel formlara gerek var mı?

– Verileri 5 kategoriye ayırabiliriz:

 Frekans sayısı (Frequency counts): belirli periyotlarda kaç kere gerçekleştiği; şikayet sayısı, kazasız gün sayısı, vb.

 Ham sayı (Raw numbers): tarih, maliyet, yüzde, vb.

 Nitel reyting (Subjective ratings): sayısal reyting veya kırmızı-sarı-yeşil değerlendirmesi

 Gösterge (Indicators): Esas ölçülmek istenen ölçülemediği durumlarda

İzleme Sisteminin Tasarımı (devam)

• 4. Toplanan Verinin Raporlanması: Veriden bilgi çıkartmak için anlamlandırılması gerekir:

– Raporların zamanında hazırlanmalı – Veriler analiz edilmeli:

• Eğilimler: Daha iyiye veya kötüye gidiyor?

• Karşılaştırmalar: İsterlerle, geçiş performansla veya standartlarla karşılaştırmalar

• İstatistiksel analizler

• Sebepler ve düzeltmeler

– Raporlar sadece email veya posta ile gönderilmez, bazen toplantılarda yüz-yüze konuşulur.

İzleme Sisteminin Davranışsal Yönleri

• Etkin izleme (kötü/iyi) sürprizleri azaltır, böylelikle güven ve morali artırır

• Raporlamalarda tam tarafsızlık sağlanamayabilir ancak dürüst olmamak kabul edilemez!

• “Elçinin kellesini almak” ilerde büyük sorunlara

sebep olabilir!

Proje İzleme - Problem Belirtileri

Takvimin 3 ay

gerisindeymişiz ama kimse bilmiyordu!

Fark etmemiz niye bu kadar zaman aldı?

Ocak

İzleme Örneği

• Standart (Tarihsel veri): C++ ile yazılım geliştirmede:

– Kodlama safhasında günde 25 satır kod yazmanız lazım, – Yazılan kodun testinde 1000 satırda en fazla 3 hatanızın

olması lazım

• Gerçekleşen:

– Günde 40 satır kod – 1000 satırda 0.5 hata

İyimser Yorum

Bu farkı açıklayan sağlam sebepleriniz var mı?

Niye daha iyiyiz?

– Süreç mi değişti?

– Çalışanlar daha mı iyi?

– Kullanılan araçlar mı daha iyi?

Artık çok daha verimli çalışıyoruz!

Kötümser Yorum

Gerçekten ne oldu?

– Testlerin hepsi yapıldı mı?

– Testlerin kapsamı yeterli miydi?

– Teslimattan sonra müşteriden ne kadar şikayet aldık?

Testimiz o kadar iyi değil, belki çok acele

ettik

İzleme ve Ölçümün Püf Noktaları

• Toplanan bilginin nasıl yorumlanacağını belirtiniz!

• Bilginin nerede, nasıl ve kimin tarafından kullanacağını belirtiniz!

• Ölçmenin ölçüleni etkileyeceğini unutmayın!

– Ölçmenin yaratacağı olumlu ve olumsuz etkileri hesaba katın!

• İzlemenin maliyetli olduğunu unutmayın ve sadece bu maliyete değecek olanları izleyin!

A Less Common Measure That May be Very Effective

Metric: Productivity

Measure 3: Number of customer complaints

Use: Reward those who produce the code that is responsible for the fewest customer complaints

Result: Developers may pay particular care to the customer’s need, resulting in future sales and business success

Good and Not So Good Measures

Goal: Produce software more efficiently Metric: Efficiency

Measure 1: tests completed per week

Result: easy tests done first; corners cut in testing; hard problems ignored or deferred

Measure 2: rework

Result: process and methods are improved to reduce rework, resulting in more efficient software development

What Should We Measure?

Process Metrics

 Effectiveness of the process

 How well are we

Product Project

Process determines

success of determines

quality of

root causes root causes

Product Metrics

 Performance and quality

 How well is

Project Metrics

 The state of the project

 How are we doing

Product Project Process

Attributes

What

Resources

Quality

Time Are We On

Schedule?

Expenses vs. Budget?

How Fast can we Manufacture?

What Is our Cycle Time?

Post-release Defects?

What will it Cost?

What is our Productivity?

Customer In-process Defects?

Performance Meets Perfor- mance

Goals?

Meets Mgt. Goals?

Does it Work?

What Attributes Can We Measure?

• We want attributes that relate to our goals

– time, resources, performance, quality etc.

• The following type of matrix can help:

Selecting Metrics

• Goal/Question/Metric

• Mapping to the Process

• Tying to Risks

Selecting Metrics: The Goal-Question-Metric Paradigm

GOAL

(deciding what do we want to accomplish)

QUESTIONS

(determining what we want to know – questions

the answers tell us whether we are meeting the goals or help us understand how to meet them)

METRICS

(selecting measurements that answer the questions)

Steps of the GQM Paradigm

1 Determine your goals -- and prioritize them

– Don’t select too many

– Make sure they are your real goals

2 For each goal, determine what questions would help you understand whether you are achieving the goal or how to achieve it

Steps of the GQM Paradigm

3 For each question, determine if it can be answered by measurement

– If so, determine what can be measured – And what it would cost to measure

– And the side effects of the measurement

4 Select the measures that best match your goals/questions and that have the best payoff

Forms of Payoff for Metrics i.e., Which Measures to Use

• Low cost of collection and storage

• Minimal impact of collection (morale, disruption, etc.)

• High information communicated

• One metric answers multiple questions

• One metric supports multiple goals

Look for Questions and Measures That Do Dual Duty

Goal 1 Goal 2

Q1 Q2 Q3 Q4 Q5

M1 M2 M3 M4 M5 M6 M7

Other Attributes of a Good Set of Measures

• Completeness - addresses all issues of concern

• Value is high relative to cost of collection, storage and analysis

• There is an organizational framework for understanding the importance of metrics

– I.E., People do not sabotage the metrics collection effort – And people do not draw wrong conclusions

• All parts of the organization benefit

Example: GQM Approach

• Goal:

• Question 1:

• Question 2:

• Question 3:

Note that no single question is sufficient. Each addresses different things that one would like to know regarding the

Possible Measures for Question 2

How many defects are in the software when we release it?

• Number of defects in product

-- this is impossible to know

• Number of known defects at release

• Number of defects detected after release

Analyzing Defect Data

Total Defects

Known at Release

Known after 12 Months Total Defects in Product Life

Tie Metrics to the Process -- Measures for Every Phase

Phase Metric

Requiremen

ts Test

Plannin

g Design Integration

Coding

Staffing

X

X X X

Requirements Stability X

X X

X

X Design Complexity

X Code Complexity

Risk: “Running out of memory space”

Possible Measures:

– Predicted memory space used (update each week or month, depending on risk)

– Size of code produced by compiler – Level of experience of average staff

Tie Metrics to Risks

• Any risk may result in measures for monitoring

• Choice depends on anticipated causes of risk

Another Example of a Risk Measure

Risk: “Not meeting schedule”

Cause: Not enough experienced staff Possible Measures:

• Staffing level

• Unplanned turnover

Recommended Metrics

• Problem Reports

• Customer Satisfaction

• Requirements Stability

• Rate Charts

• Resource Use

• Defects

• Rework

• Earned Value (next module)

Proje Kontrolü

KONTROL: Gerçekleşen ile planlanan arasındaki farkın azaltılması

– Plan – Uygula – İzle – Kontrol döngüsünün son aşaması – Proje izlemeden elde edilen bilgilerin kullanımı ile projenin

planlara uygun yürütülmesi

• Performans

• Bütçe

Performans

• Teknik problemler çıkabilir

• Kalite ile ilgili problemler olabilir

• Müşteri değişiklikler isteyebilir

• Teknolojide değişiklik ve yenilikler olabilir

• Takım içi problemler çıkabilir

• Piyasada değişiklikler olabilir

Maliyet

• Sorunlarla uğraşmak için ekstra kaynağa ihtiyaç vardır

• Kapsam büyüyebilir

• İhale teklifiniz çok düşük olabilir

• Durum raporlama ile ilgili problemler olabilir

• Bütçe yetersiz olabilir

• Girdi fiyatları değişebilir

Zaman

• Sorunları çözmek zaman alır

• Planlama aşamasındaki tahminlerin çok iyimser olabilir

• Aktivite sıralamaları (öncüllük ilişkileri) doğru tahmin edilememiş olabilir

• Kaynaklar zamanında bulunamayabilir

• Aktiviteler zamanında bitmeyebilir

• Müşteri değişiklikler

• Kanun, mevzuat veya standartlar değişebilir

Proje Kontrol Süreci

1. Önemli başarım alanlarını (key performance areas) belirleyin 2. Standartları belirleyin (Set standards)

3. Performansı ölçün

4. Ölçüm sonuçlarını inceleyin (Standart ile karşılaştırın) 5. Düzeltici müdahaleler yapın

İzleme ve Kontrol Süreçleri

Kazanılan Değer Yönetimi

Earned Value Management

• Amaç: Toplam proje performansını objektif olarak ölçebilmek!

• Kazanılan değer: İşin gerçekte ne kadarının bittiği = Bitme Yüzdesi * Planlanan Değer

• Kazanılan Değer Yönetimi: Toplam proje

performansını hem takvim hem de bütçe boyutunda

analiz edebilen bir proje yönetim tekniği.

Kazanılan Değer Yönetimi

• Kazanılan değer hesaplaması:

– 50-50 kuralı: İş başladı %50; iş bitti %100. En çok kullanılan kural!

– % 0 - %100 kuralı: İş başladı %0; iş bitti %100. Proje hep biraz geriden gidiyor, ta ki proje bitene kadar.

– Kritik girdi kullanımı kuralı (Critical input use rule): Girdinin

kullanım yüzdesine göre. Ancak, makine kullanılıyor ise ve makine işin başında alındığında, ilerleme yansıtılmamış oluyor.

– Oran kuralı (The proportionality rule): Gerçekleşen zaman veya maliyetin planlanan zaman veya maliyete bölünmesi ile bulunur.

Ancak, bu durumda kazanılan değer bağımsız olarak tahmin edilmiyor.

Kazanılan Değer Yönetimi

Kazanılan Değer Yönetimi

• Planlanan İşin Bütçelenen Maliyeti (PİBM) - BCWS (Budgeted Cost of Work Scheduled)

– Plan: Takvime göre ne kadar işin bitmesi planlanmıştı?

• Yapılan İşin Gerçeklesen Maliyeti (YİGM) ACWP (Actual Cost of Work Performed)

– Gerçekleşen: Ne kadar harcandı?

• Yapılan İşin Bütçelenen Maliyeti (YİBM)

BCWP (Budgeted Cost of Work Performed)

– Kazanılan Değer: Gerçekte yapılan iş için ne kadar harcanması planlanmıştı?

Kazanılan Değer Yönetimi

• “Bu güne kadar”, “current, to date - CTD” değerler güncel değerlerdir.

• “Tamamlandığında Bütçe”, “budget at completion - BAC”

değeri proje bitimi için planlanan/bütçelenen değerdir

• “Tamamlanma Tahmini”,“estimate at completion - EAC”

değerleri proje bitimi için şu anda yaptığınız tahmin değerleridir

EVM Birimi

• Bütçe (Budget) ve iş (work) parasal olarak (ör. TL) ölçülebileceği gibi efor (ör: adam-saat, adam-ay, vb.) olarak da ölçülebilir.

• Efor cinsinden ölçmek bazı durumlarda kullanımı kolay olabilir (işgücü yoğun projeler)

• Ancak, parasal olarak ölçtüğümüzde, genel gider ve

işgücü harici maliyetleri de hesabımıza dahil ederiz.

Kazanılan Değer Yönetimi

5 10 15 20 25 30 35 40

Total Plan Actual Estimate

BCWS

ACWP_EAC ACWP_CTD

BCWS_BAC

Kazanılan Değer Yönetimi

• Gerçekleşen maliyeti bütçe ile karşılaştırdığımızda,

planladığımızdan az yada fazla harcadığımızı söyleyebiliriz.

• Ancak, şunlara cevap veremeyiz:

… Takvimin gerisinde miyiz ilerisinde mi?

… Proje bütçe bittiğinde bitebilecek mi?

… Proje verilen süre bittiğinde bitebilecek mi?

• Kazanılmış değer, harcadığımız para ile ne kadarlık iş bitirdiğimizi (kazandığımızı) gösterir.

Kazanılmış Değer Yönetimi

• Kazanılan Değer Yönetimi ile şu soruları cevaplayabiliriz:

– İşlerimiz takvime uygun mu yapıyoruz?

– Bütçeyi aştık mı?

– Proje sonunda bütçeyi aşacak mıyız, altında mı kalacağız?

– Proje bitim tarihine ilişkin gerçekçi tahminimiz ne?

– Bütçe veya proje son tarihini tutturabilmemiz için ne yapmamız lazım?

Takvim hakkında ne söylenebilir?

SV - Schedule Variance / Takvim Sapması

SV = BCWP - BCWS

SPI - Schedule Performance Index / Takvim Başarım Göstergesi SPI = BCWP / BCWS

1’den küçük değer takvimde geri olduğumuzu gösterir Eksi değer takvimde geri olduğumuzu gösterir

Takvim hakkında ne söylenebilir?

0.7 0.9 1.1 1.3 1.5

Takvimden İleri Takvimden

Geri

Bütçe hakkında ne söylenebilir?

CV - Cost Variance / Bütçe Sapması

CV = BCWP - ACWP

CPI - Cost Performance Index / Bütçe Başarım Göstergesi CPI = BCWP / ACWP

Eksi değer bütçenin aşıldığını gösterir

CPI: Bütçenin altında veya aşılmış

0.7 0.9 1.1 1.3 1.5

Bütçe İçinde

Bütçe Aşımı

Proje Sonu Hakkında Ne Söylenebilir?

• Bugünkü bilgiler ışığında projenin son maliyetinin tahmini (EAC – Estimate Cost at Completion)

– Bugüne kadarki performans sürecek mi, artacak mı, azalacak mı?

• Estimated Cost to Complete (ETC) =

(BAC – BCWP)/CPI

• Estimate Cost at Completion (EAC) =

Proje Sonu Hakkında Ne Söylenebilir?

• Independently Estimated Cost At Completion (IEAC): Bugüne kadarki performansa dayalı tahmin

IEAC = BAC / CPI

Proje Sonu Hakkında Ne Söylenebilir?

• VAC - Variance at Completion

VAC = BAC - IEAC veya

VAC = BAC - EAC

Negatif: bütçeyi açığı

Proje Sonu Hakkında Ne Söylenebilir?

ISAC - Independent Schedule at Completion

– Yeni veriler ışığında projenin yeni takvim tahmini

ISAC = SCHED / SPI SVAC - Variance at Completion

SVAC = SCHED - ISAC

Örnek:

• Bugün 1500 TL’ye bitmesi gereken bir iş paketi vardı. Ancak, iş paketi 2/3 bitmiş durumda ve bu iş paketi için şu ana kadar 1350 TL harcanmış. Bu durum için CPI ve SPI’yı

hesaplayınız.

 CPI = BCWP/ACWP

= $1000/$1350 = .74

 SPI = BCWP/BCWS

= $1000/$1500 = .67

 CSI = CPI X SPI

Örnek ^(devam)

• Bu iş paketi için ETC ve EAC değerlerini de hesaplayınız.

 ETC = (BAC – BCWP)/CPI = $(1500 – 1000)/.74 = $676

 EAC = ACWP + ETC

Örnek 2:

• 10 günlük bir proje ve bugün 7. gün

Activity Predecessor Duration (Days)

Budget ($)

Actual Cost(s)

% Complete

a - 3 600 680 100

b a 2 300 270 100

c a 5 800 80

d b 4 400 25

Örnek 2: PERT AON Diagram

Örnek 2: 50-50 kuralına göre bütçe planı

Örnek 2: 7. gündeki durum

Örnek 2: EVM Grafiği

MSP Bütçe Görünümü

Texas Instruments’da EVM

EVM Ödev:

• Projeye 10 ay için 5 full-time çalışan ve 1000 adam-

günlük efor planlanmıştır. 4. ay bittiğinde 340 adam-

günlük iş planlandığı ancak 370 adam-günlük bir efor

harcanarak 320 adam-günlük iş bitirildiği belirlenmiştir.

EVM Ödev:

• Şu an bütçedeki fark nedir (Cost Variance – CV)?

• Şu anki verimlilik nedir (Cost Performance Index - CPI)?

• Takvimdeki sapma ne kadardır (Schedule Variance – SV)?

• Takvim takip başarısı ne kadardır (Schedule Performance Index – SPI)?

• Projenin bitimindeki toplam maliyet (Estimate at Completion) ve bitime kadarki maliyet tahmininiz (Estimate to Completion) nedir?

– Bugüne kadar beklenmedik gelişmeler oldu ancak bundan sonra planlandığı gibi işlerin yürüyeceğini kabul edin.

– Bugüne kadarki gerçekleşen performansın böylece devam edeceğini kabul edin.

END 418

Proje Yönetimi

Proje Kapanış Süreçleri

Kapanış Süreçleri Grubu

Her şeyin bir sonu vardır…

• Proje sonlandırmanın projenin teknik başarısına veya başarısızlığına bir etkisi yoktur

• Ancak, müşterinin, üst yönetimin ve proje ekibinin proje hakkındaki düşünceleri ve sonraki projelerin başarıları etkilenir.

• Diğer aktiviteler gibi proje sonlandırmayı da planlamamız

gerekir

Projeler ne zaman sonlandırılır?

• Proje başarıyla bittiği zaman veya

• Projenin o anki durumuna bakılarak, firma

projeyi bitirmek için zaman ve bütçe ayırmak

istemiyorsa

Proje sonlandırmanın başlıca sebepleri

1. Düşük teknik veya ticari başarı olasılığı

2. Düşük karlılık/geri kazanım oranı(ROI)/piyasa potansiyeli 3. Zarar uğratacak kadar bütçe aşımı

4. Rekabet faktörlerinde veya piyasa/müşteri ihtiyaçlarında değişiklik

5. Çözülemeyen teknik problemler

6. Başka projelerin daha önemli olması 7. Takvimdeki gecikmeler

END 418

Proje Yönetimi

THE END