Expert Judgment

Concerning My PMI-ACP Exam Experiences

Posted in Agile, Project Management by dnzrn on September 15, 2011

Today I attended the PMI-Agile Exam. Since it is the first day of the examination in the whole world, it is my privilege to write about this experience that I may call the first encounter of mankind with PMI-ACP.

As most of you may be aware of there has been discussions about the examination contents, in many Agile, Scrum, Lean and PMP mail lists and LinkedIn Groups. Some people think the examination would be an abomination and PMI’s structural approach to Project Management may bruise the spirit of Agile. Others see PMI-ACP as a noble attempt to gather many Agile Methodologies and define a broad Agile Practitioner Body Of Knowledge  (APBOK (?) ), and finally put a formal definition to what Agile is. There is one think in common for all. Nobody knew what the exam would be like. Until today…

Ladies and Gentlemen, my fellow PMP’s and Agile comrades, I present you my experiences and suggestions regarding the exam:

Smart Questions

Most of the questions were prepared smartly. You should read carefully. Make sure you understand what the question really asks.

Unclear Concepts Handled Well

Some Agile concepts have conflicting definitions in the reference books. Questions related to these kinds of concepts had guiding choices as answers. Read all the choices before you select the answer. Some might be “more correct” !

Very Important Points

  • Characteristics of Stories
  • Roles in Scrum & XP
  • Scrum Processes (Sprint Planning, Daily Scrum, Sprint Review, Retrospectives)
  • Estimation (Roles, Game, Different Levels of Estimation)
  • Agile Risk Management
  • Adopting New Agile Principles
  • Velocity, Burndown, EVM
Completion Takes 1,5 Ideal Hours

The duration of the exam is 3 hours + 15 minutes of surveys. However question texts are not long, not boring, easily understandable, so it takes approximately 1,5 ideal hours to complete, and control marked questions.

Reference Books

Most of the books were used in preparing questions. Read Cohn’s book, “User Stories Applied” cover to cover. Warden & Shore’s book, “Art of Agile Development” is important. Adkyns’ “Coaching Agile Teams” is where most of the soft skills related questions come from.  At least read the chapter summaries and comparison of Agile and PMBOK processes from “Project Manager’s Bridge to Agility“.

It was really hard to read and understand Highsmith’s “Creating Innovative Products“. I was affraid of the eccentric process definitions and Complex Adaptive System references in the book. Fortunately for me, there were not many questions from Highsmith.

Shocking Surprise at the End !!!

As experienced exam takers, we expect the Pass/Fail result at the end of the exam session. Instead I got a note stating that the exam result will be available in December (!) because it is a pilot exam. This raises the concerns that PMI not having confidence in its ability to  ask accurate questions.

Last notes… Don’t sweat it. Exam is well prepared. (Well done PMI Agile COP). Please don’t ask me further about the questions, because of my obvious information disclosure obligations. Trust in your own knowledge and experience!
I wish you all the best of  luck !

Epic Breakdown Structure & Types of User Stories

Posted in Professional, Project Management by dnzrn on May 25, 2011

“There have been great societies that did not use the wheel, but there have been no societies that did not tell stories.”

—Ursula K. LeGuin

As we are well aware, work to be done is represented by/based on Stories, in Agile Projects. Recently my team was asked to develop a WBS for an Agile project, by using a specific open source project management/issue tracking tool, for demonstrative purposes. While working on this assignment the team quickly figured out that “work” is already represented by stories, so defining a WBS may be wasted effort.

It is obvious that WBS is a key element of Project Scope Planning and a valuable practice for the team to be aware of all the things that are in the project. However, Agile approach to Project Management accepts that initial scope definitions are generally inaccurate, so recommends defining the scope at a low level of detail.

After a swift brainstorming session the team reached consensus about how to form a WBS, by utilizing the stories. Behold, the EBS (Epic Breakdown Structure)

EBS is simply the hierarchical representation of a group of Stories, which will be covered by the Project. It may not be a new concept but was enough to ignite the creativity within the team. Thus the team configured the project management/issue tracking tool to support the EBS.

In this model, Stories are described in greater detail (when needed) by Business Rules and Requirements.

Only one problem left to be solved. How do we address and display the work that is not related with a Story, such as Project Planning, Documentation, Building Infrastructure (e.g. development environment)? The answer is, we don’t.  If a work item is present yet there is no Story defined for that purpose, just define the Story. And a really important point: Stories are not always business focused.

There are many types of Stories, described in the Agile literature. Here are a few:

Business Story

Business focused. Almost always written by the business. Sometimes written by the analysts.

Ex: “Student selects courses she wishes to take, from the list of all courses offered in that semester”

Non Functional (Performance) Stories

Not related to the functionality of the system, but describes the performance attributes of the system, such as, Scalability, Availability, Reliability, Maintainability, Usability…

Ex: “Registration pages use the same font and background color scheme as the other pages of the Student Affairs Information System.”

Ex: “The Student Affairs Information System is up and running 99.9% during the registration time period defined in the Academic Calendar.”

Documentation Stories
Even Agile projects need documentation and keeping documentation requires effort.

Ex: “The user manual of registration program is written in both English and Turkish, describing the registration procedure and providing screenshots.”

Defect/Bug Stories

Stories defining how/what to fix some buggy functionality which were delivered in an earlier iteration.

Ex: “Warning message displayed is translated to Turkish from Mandarin Chinese when Advisor approves Student’s Course List.”

Spike Stories / Technology Debt 

There are times when the team is not familiar with a new technology or approach which may be used in upcoming iterations. Or we simply think that spending effort on a utilization of a tool/technique will save time and effort in the future. So we carry out our own personal R&D for a bit of time. This should be defined by a Spike Story, aka Technology Debt.

Ex: “Voice operated semantic search utility of Mikrokom Corp. is examined.”

Plannning / Estimating Stories

The team spends time when planning the project. Define this time by a Planning Story.

Ex: “The planning game takes place.”

Meeting Stories

Many governmental organizations never miss the opportunity to socialize, so they organize meetings… lots and lots of meetings…

Just write a story for upcoming meetings.

Ex: “Progress and risk review meeting is organized.”

Architecture / Infrastructure Stories

All projects need infrastructure support to some extent. Show the effort spent in establishing the infrastructure as an Infrastructure Story.

Ex: “Redmine the Issue Tracking Tool is deployed and user authentication mechanisms for the software support team members are developed.”

PMI Agile Certification (PMI-ACP) Pilot Programme is Up !

Posted in Professional, Project Management by dnzrn on May 23, 2011

Greetings,

I am pleased to announce that I just have applied to the PMI-ACP Pilot Programme.

For application use the following address:

https://certification.pmi.org/

In order to apply you should claim that you have the minimum eligibility requirements:

  • graduate of (at least) a high school
  • 2000+  hours of Project Management Experience in last 5 years or to have PMP
  • 1500+ hours of work experience in an Agile Project Team in last 2 years
  • 21 contact hours of Agile Project Management Training
  • Pass the exam
The application form consists of 3 major parts
Your Contact Information
Agile Training Background
For each training:
  • Start Date / End Date
  • Title
  • Institution
  • Contact Hours
Agile Project Experiences
For each project:
  • Title
  • Start Date / End Date
  • Project Role
  • Primary Industry
  • Organization Information
  • # Hours of Agile Project Experience
  • Description of the Role (Which Agile practices you’ve performed, which Agile tools you have used, …)
This is the link to the certification home page:
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
This is the link to the certification handbook:
http://www.pmi.org/Certification/~/media/PDF/Certifications/PMI-ACP_Handbook.ashx
I wish all pioneers applying this pilot program, best of luck.
Don’t forget to get prepared for the exam, which will be available in September 2011
Exam topics:
http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx

[TR] Proje Yönetim Ofisi

Posted in Professional, Project Management by dnzrn on March 17, 2011

Yapısal bir Proje Yönetimi yaklaşımının kurumlara kazandırılması kolay bir iş değil. Özellikle de kemikleşmiş bir iş kültürüne sahip olanlara…

İşleri Projeler biçiminde yönetme yaklaşımının (Management by Projects) pek çok kazanımı var. Bu kültürün organizasyonda verimli şekilde işlemesini sağlamak için, kabul görmüş bir örgüt birimi olan Proje Yönetim Ofisi’nin kullanımı önerilir. Bir örgütte Proje Yönetim Ofisi (PYO) kurulurken dikkat edilmesi gereken bazı noktalar var:

  • Çalışanlara bu yapının fazladan bürokratik bir engel değil,  işlerini kolaylaştırmak üzere kurulmuş olduğunun açıklanması,
  • Yönetimsel destek. Bu basit bir görevlendirme yazısı olabileceği gibi, örgütün yöneticisinin PYO’nun da yöneticisi olarak belirtilmesine kadar gidebilir.
  • PYO nun kapsamının çok net belirlenmesi,
  • PYO nun görev alanının Projeler ile sınırlanması, Operasyonların sorumluluğunun PYO üzerine bırakılmaması.

ODTÜ Bilgi İşlem Dairesinde yaptığım PYO yapısını konu alan bir sunum:

http://prezi.com/ncqcoimul5uc/odtu-pyo/

[TR] Makale Gözden Geçirme Yazısı: “P.Y. – 21. Yüzyılda Çılgınlığa Karşı Metodolojiler”

Posted in Project Management by dnzrn on May 3, 2010

Proje Yönetimi: 21. Yüzyılda Çılgınlığa Karşı Metodolojiler

– Makale Gözden Geçirme Yazısı –


Deniz İREN, PMP

Orta Doğu Teknik Üniversitesi,

Bilgi İşlem Daire Başkanlığı

www.deniziren.com | diren@metu.edu.tr

Birkaç gün önce, bir arkadaşımın yönlendirmesi üzerine, 2000 senesinde yazılmış bir makaleyi inceledim. Makale, 2000 senesinde yapılan bir söyleşinin (Software Methods and Tools 2000), konuk konuşmacısının yaptığı açıklamaları konu almakta. İlginç olan konuşmanın konusu. Önlerindeki 10 sene boyunca Yazılım Proje Yönetimi alanında yaşanacak değişiklikleri öngörmüşler. Ben de tam 10 sene sonra (2010) bu makaleyi okuma ve öngörülerin ne kadar gerçek olduğunu değerlendirebilme fırsatı yakaladım.

Makalenin yazarları, Amerika’daki Capital One Bankası’ının Finans Departmanı’nda çalışan iki arkadaş; George Kelly Flanagin ve Susan R. Jacobs. Makale, yazarların yaptığı bir dizi öngörünün sıralanması ve açıklanması biçiminde organize edilmiş.  Bu öngörüler şu şekilde;

“Yazılım profesyonellerinin sertifikalandırılması büyüyen bir trend ve büyümeye devam edecek.”

Makalenin yazıldığı senelerde, Microsoft’un sadece üç sertifikası vardı ve bunlar da epeyce yeniydi. MCSE, MCSD ve MCDA sertifikaları yeni yeni çıkıyordu. 2000’lerin başlarında bu sertifikalar çok zor ediniliyordu ve çok değerliydi. Yazarların tahminleri, bu tür sertifikaların sayısının ve çeşitliliğinin artacağı ve sertifikasyon işinin büyük bir pazar olacağı yönünde idi. Haklı olduklarını bugünkü duruma bakarak görebiliyoruz. Microsoft’un şu anda 17 adet sertifikasyonu var. Ne var ki artık bu sertifikaları edinmek zor sayılmaz ve bunlara sektördeki kuruluşlar tarafından eskisi kadar değer de verilmiyor.

Yazarlar, sertifikasyonların detaylanmasında bir risk görmüşler. Öngörülerine göre, sertifika sahibi profesyoneller daha detaylı işler ile ilgilenecekler ancak kendi alanlarının uzmanları oldukları için bir çok projede kendi uzmanlık alanlarında “misafir” olarak görev yapacaklar. Yani bir “Sertifikalı İş Analisti” sıfatına sahip bir kişi, bir projede iş analizini yaptıktan sonra o projenin analiz fazının geçilmesi üzerine, başka projeye transfer edilecek ve yapmış olduğu işin ilk proje üzerindeki etkilerini izleyememiş olacak. Bu da son kullanıcılara karşı direk sorumluluğu olmayan (olmamış) kişilerin, yazılım geliştirme projelerinde, mimari sürecinin bir aşamasında kullanılmasına sebep olacak. Bugün itibariyle, sertifika sahiplerinin organizasyonlarda, yazılım geliştirme süreçlerinin ilgili aşamalarında görevlendirilmesine dair bir eğilim söz konusu. Ancak bu durumun yapılan işin kalitesi üzerindeki etkisinin ne olduğunun araştırıldığına henüz rastlamadım. İleriki bir araştırmanın konusu olarak not alıyorum.

“Yazılım her geçen gün daha büyük bir gereklilik oldukça, yazılım profesyonelleri, yazılım şirketlerine kayacaklar.”

Yazarların öngörülerine göre, diğer şirketlerin BT birimlerinde çalışan yazılım geliştiriciler, yazılım şirketlerine kayma eğilimi gösterecekler. Bu da nitelikle BT personelinin yazılım geliştirme şirketleri haricinde şirketlerde bulunulmasını zorlaştıracak. Özellikle yazılım geliştirme kökenli Yazılım Proje Yöneticileri, en zor bulunur personel olacak.

Baktığımızda, bu öngörünün büyük oranda doğru olduğunu görüyoruz. Sektörde, yazılım geliştirme projeleri genellikle, büyük yazılım şirketleri tarafından sahiplenilip, alt yükleniciler vasıtasıyla yürütülüp, tamamlanıyor. Yazılım Proje Yöneticileri bu süreçte hem yazılımı geliştiren alt yüklenicilerde, hem de alt yüklenicilerin işini denetleyen asıl proje sahibi organizasyonlarda bulunabiliyorlar. Ne var ki, bir numaralı iş alanı BT olmayan organizasyonlarda, yazılım projelerinin kurum içi veya alt yükleniciler vasıtasıyla yönetilmesi yazılım geliştirme kökenli olmayan personel tarafından da gerçekleştirilebiliyor.

“Yazılım ihtiyacı olan şirketlerin çoğu dış kaynaklı yazılım geliştirme yapacaklar.”

Öngörüye göre, kalifiye BT personelinin yazılım şirketlerine geçmesi sonucu, diğer şirketler çareyi yazılım projelerini geliştirirken dış kaynak kullanılmasında bulacaklar.

Günümüzde yazılım geliştirme projelerinin dış kaynak kullanımı ile yürütülmesi çok rastlanan bir durum. Tabii ki bunun sebepleri arasında yazılım şirketlerinin yetkinliklerinin, kurum içi BT birimlerinden daha yüksek olması da var. Ancak tek sebep bu değil. Dış kaynak kullanımı pek çok operasyon ve kalite maliyetlerinden de kurtulmayı ve yazılım geliştirmeyi optimize etmeyi sağlamakta.

Öngörülene göre ana faaliyet alanı BT olmayan organizasyonlarda kalmayı seçen proje yöneticileri, yazılım geliştirme projelerinin büyük kısmının 3. parti organizasyonlar tarafından yürütüleceğini tecrübe edecekler. Dana önce bahsettiğim sebeplerden bunu da gerçekleşmiş bir öngörü olarak değerlendiriyorum.

“3. dünya ülkelerinde yazılım eğitiminin artması, dış kaynak kullanımını uluslararası boyuta taşıyacak.”

Makale, Amerika, Kanada, Avustralya ve Batı Avrupa ülkelrindeki nitelikli BT iş gücünün azlığına dikkat çekmiş ve bu açığın kapatılması için Hindistan gibi gelişmekte olan ülkelerden işgücü transfer edileceğini öngörmüş. Yazarlar üç farklı uluslararası dış kaynak kullanım modelinden bahsetmişler. Bunlardan ilki, gereksinimlerin ve iş analizinin yerinde yapılmasını takiben, işin yapılacağı ülkeye transfer edilmesi ve işin burada yürütülmesi. Ne var ki yapılacak işin doğası gereği her tür proje bu şekilde transfer edilebilir olmuyor. Diğer bir yurtdışı dış kaynak kullanımı modeli ise, ucuz iş gücünün bulunduğu ülkede bir şirket birimi oluşturmak. Bunun da en büyük dezavantajı, yabancı ülkelerin kuralları, kanunları ve kültürlerine hakim olmamanın getireceği riskler. Makalede belirtilen üçüncü ve son dış kaynak kullanım modeli ise iş gücünün 3. Dünya ülkelerinden taşınarak, gelişmiş ülkelere taşınması.

Baktığımızda, bu öngörünün de büyük oranda gerçeğe döndüğünü görebiliriz. Amerika ve Avrupa’da konumlanmış olan pek çok büyük yazılım şirketinin, Hindistan, Çin ve Brezilya’da ofisleri var veya en azından çeşitli projeleri yürütürken bu ülkelerdeki yazılım çiftliklerinden faydalanıyorlar.

“Var olan servislerin kullanımı ile yazılım geliştirme yoğunluğu artarken, yazılımı sıfırdan geliştirme yoğunluğu düşecek.”

On sene önce yapılmış olan bu tahmin aslında, Hizmet Odaklı Mimari (SOA) nın bir habercisi adeta. Günümüzde pek çok yazılım çözümünün geliştirilmesinde bu yaklaşım uygulanıyor.

“İnternet, yazılım geliştirme ve proje yönetimini kökten değiştirecek.”

Yazarlar, 2000’lerin ilk on senesinde, özellikle internet tabanlı ürünlerin geliştirilmesinde, yazılım projeleri büyüdükçe, projedeki satıcı ve geliştirici paydaşların sayısının artacağını öngörmüşler. Projenin yaşam süresi boyunca bu paydaşların etkinliklerini hatta varlıklarını dahi kaybetmelerinin söz konusu olabileceğinden bahsedilmiş. Yazarlar, yoğun alt yüklenici yönetimi gerektiren projelerde, bir proje yöneticisinin sahip olması gereken en önemli özelliğin seri ve doğru düşünme ve karar verebilme olduğunu belirtmişler. Gerçekten de günümüzde yazılım yoğun sistemlerin geliştirildiği büyük projelerde çok sayıda alt yüklenici kullanılıyor. Gün geçtikçe organizasyonlar BT’nin kaldıraç etkisinden faydalanmak için yeni fırsatları araştırıyorlar. İş gereksinimleri karmaşıklaştıkça, sistemler de karmaşıklaşıyor. Doğal olarak bu yazılım geliştirme sürecinin de karmaşıklaşmasına, çok sayıda uzmanlık alanının ve işgücünün bir arada kullanılmasına ihtiyaç duyulmasına sebep oluyor. Bu da makale yazarlarının doğru çıkan öngörülerinden.

Makalede, çok sayıda alt yüklenici kullanılmasının bir riskinden daha bahsedilmiş. Bu risk, her alt yüklenici kendi iteratif veya çevik süreci ile iş geliştirirken, farklı alt yükleniciler tarafından geliştirilen ve farklı zamanlarda hazır olan iş ürünü parçalarının bir araya getirilerek, işlevsel bir bütünlük içinde test edilmesinin zorlaşması. Basitçe açıklamak gerekirse, alt yüklenici sayısı arttıkça, bu alt yüklenicilerin üretim döngülerinin birbirleri ile senkronizasyonunun sağlanması daha karmaşık bir süreç halini almakta. Bu da yazılım parçalarının bir araya getirilerek, alfa işlev bütünlüğünün ancak üretim fazının sonlarında oluşmasına sebep olmakta. Bu projenin sahibi olan organizasyon için test aşamasını –dolayısıyla kaliteyi- ilgilendiren büyük bir risk oluşturuyor.

New Responsibilities and Opportunities

Posted in Project Management by dnzrn on April 25, 2010

Life has an odd way to shape us into what we become. I haven’t been able to update my blog, because of a series events and developments in last couple of months. But now, I’m back. More focused than ever, motivated and enabled with new responsibilities.

Last month, I was elected as board of administration member of PYD (Proje Yönetim Derneği, EN:Project Management Association). The new administration team shares my vision and highly motivated as I am. We are going to make a series of accomplishments that will deliver quick and observable value to the association.

New benefits arise along with this new responsibility. I am now in real close contact with a lot of marvellous, experts and professionals throughout a variety of business sectors. Once I establish the member directory, I will try and introduce them one by one, here, in my blog.

Let me remind myself, my blogging goals, once again! Write frequently, write short, write when necessary and only if new value is delivered !

Until my next post, take care…

View of Risk

Posted in Project Management by dnzrn on May 2, 2009

A ship in harbor is safe – but that is not what ships are for.  

-John A. Shedd, Salt from My Attic

 

Can one dare not taking risks? Its all about the viewpoint. 

Recently in a software project, a major stakeholder who is a long standing customer, helped us identify a risk. He reported us that his accounting data has exceeded the limitations of  Microsoft SQL Server 2005 Express, which is 4GB. We have estimated that a large scale accountant office would need 10MB of database space per year, per customer. So, we estimated, unless one accountant is keeping track of  40 customers’ data of last 10 years in the same database, they would be able to use the Express Edition, which is free. 

So we quickly analyzed the risk, and found out that the root cause of exceeding limits problem was high data storage need of that particular stakeholder (which is one of the largest construction companies in Turkey). Looking at this risk, I saw an opportunity. An opportunity to be able to sell a more convenient edition of MS SQL Server, which would have resulted in 1000$ profit per customer with similar special needs. So, happily I let my manager know the issue. His voice was ice cold and I couldn’t get a body language reading, because we were speaking on the phone. Later that day, the manager ordered a major change in the design of the software product, in order to satisfy the specific need of customers with high data storage need. We were ordered to carry out the design change, even though I let the manager know of my objections to his decision.

My manager has seen a threat, where I saw an opportunity. We walked down the “safer” road. Thus, it resulted in 2 staff-months of rework, $8.000 cost, plus the cost of opportunity to sell MS SQL 2005. To be fair, I must admit that we might have ended up with a significant loss if we didn’t alter the design and our estimations turned out inaccurate. (I guess, we’ll never know)

Its all about the viewpoint.

 

Certified now

Posted in Project Management by dnzrn on May 1, 2009

That’s one small step for man, one giant leap for mankind.

-Neil Armstrong

I’ve passed the PMI’s PMP certification exam last monday. Well, it may be a small step for mankind, but it is definitely a giant leap for me. 

With this opportunity, I will go ahead and post some useful links about Project Management. 

PMI: Project Management Institute. Leading association for Project Management Profession. 

PMBOK: A term defining the body of knowledge related with the Project Maangement. Basically a framework of what Project Management is about. PMBOK Guide is the official resource of PMBOK, issued by PMI. (Now 4th edition is available)

Rita Mulchany: A successful Project Management Trainer, and a Certified PMP. Without her, I wouldn’t have passed the exam on my first try. I strongly recommend her products, especially the software: PMFastTrack. 

Ankara PYD (Ankara Project Management Association): the Project Management Association of Ankara, Turkiye. (Site language is Turkish)

Project Reference: A truly wonderful resource for project management. Created by John Musser, an Instructor of Columbia University.

Controlling Chaos: A series of (very useful) podcasts, about Project Management, created by Dina, a PMP Certified senior Project Manager.