Translate

Kasım Şen - (Mütehayyil)

management etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
management etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

29 Temmuz 2025

HISTORY OF PMO’S

 


HISTORY OF PMO’S


1.   INTRODUCTION

Project Management Offices (PMOs) have become structural units that play a critical role in helping modern organizations achieve their strategic goals. The transformation these institutional structures have undergone throughout their approximately century-long history reflects not only the development of the project management discipline but also the fundamental changes in organizational management understanding. This study examines the historical development of PMOs periodically, analyzing the driving forces of this evolutionary process and potential future trends.

PMOs have appeared in many different structures to date. First, I would like to share the definition made by PMI (Project Management Institute) for PMO. PMI defines PMO in the 6th edition of the Project Management Body of Knowledge (PMBOK - PMI) as "An organizational structure that standardizes project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques. The responsibilities of a PMO can range from providing project management support functions to direct management of one or more projects." (PMBOK Guide [PMI], 2017). This definition summarizes all definitions given to PMO so far.

IPMA (International Project Management Association) defines PMO as "Part of a permanent organization. Its roles are typically to provide support, establish standards and guidelines for managers of different projects and programs, collect project management data from projects, consolidate them, and report to a management body. It should ensure that projects are aligned with the organization's strategy and vision. This is usually achieved through business case management." (IPMA Competence Baseline, 2015).

2.   PERIODS OF PMO EVOLUTION

We can analyze the evolution of PMOs by dividing it into the following main periods:

  1. 1930s - Birth of the Concept: First documentation centers
  2. 1940-50s - Military Origins: Systematic project management approaches
  3. 1960-80s - Corporate Adaptation: Expansion to the civilian sector
  4. 1990s - Professionalization: Development of standards
  5. 2000s - Strategic Partnership: Integration with business strategy
  6. 2010s - Agility: Adaptation with Agile methodologies
  7. 2020s - Digital Transformation: AI-supported smart PMOs

2.1.             First PMO Examples

According to some claims, PMO usage dates back to the beginning of 1805 in Great Britain within the framework of monitoring and managing the government's agricultural strategy. The project itself was a national tax plan designed to refine and implement taxes, promote agriculture, and encourage efficiency through import and export of goods. The Project Office was a team to execute such a plan. In short, its function was to handle delivery when no other operational structure had the capacity. Subsequently, it was noted that this concept was adopted in the United States in some government-initiated projects (for example, Hoover Dam construction, from 1931 to 1936) to ensure excellent control of their management, as well as for greater transparency to the public and authorities.

Government audit and accountability documents mentioning Project Office in the United States can be traced back to as early as 1905. The permanent themes of US project offices focus on cost control. The 1900-1910 period was the peak of the Progressive Era, a social and political reform movement against corruption. As a result of this corruption, the US government focused on transparency and published numerous senate investigations, congressional documents, and accountability audits related to Project Offices. Most of the time, the project office is considered a group of actors managing an initiative, controlling materials, equipment, and human resources. The published projects appear to be related to water supply, irrigation, and agriculture.

2.2.             1930s - Birth of the Concept: First documentation centers

According to the accepted approach, the history of PMOs dates back to the 1930s. The roots of the PMO concept are based on institutional responses to increasing project complexity in the post-industrial revolution period. Although the term "Project Management Office" was first used in a written publication in 1939, it is known that the foundations of this concept date back to the early 1930s.

During this period, PMOs functioned primarily as documentation centers. Organizations needed a central structure to overcome the difficulties they faced in coordinating their large-scale projects, and PMOs emerged to meet this need. The use of Project Office as an organ to control and monitor projects by the US Air Force was first seen in the United States in the 1930s. Generally, PMO adoption during this period was limited to some government plans and programs. PMOs shaped project management from military roots to modern strategy centers. They evolved from Apollo missions to mega projects, from control to innovation drivers.

1939 appears to be the earliest example of the publication of the Project Management Office term (US Housing Authority 1939). The Policy and Procedure Bulletin was written by the US Housing Authority and relates to public housing often referred to as 'projects'. The Project Management Office term focuses on the management of housing shelter on behalf of the state.

2.3.             1940-50s - Military Origins: Systematic project management approaches

The PMO (Project Management Office) concept emerged during World War II in the 1940s with the Manhattan Project. This highly classified initiative demonstrated the need for structured project management to oversee the development of the atomic bomb. World War II and the post-war period marked a critical turning point in the development of the PMO concept. US military institutions established structures called System Program Offices (SPO) to overcome the managerial challenges they faced in developing complex weapon systems.

The PMO concept as known today is based on the 1950s, specifically within the scope of missile system development projects carried out by the United States army. In the 1950s, the US Government continued to publish PMO accountability articles related to agricultural research, defense, government housing, geology, highway design, water management, major engineering efforts, various federal projects and programs. The war between bureaucratic organizations with time, quality, cost constraints and the innovative nature of science and engineering was emphasized as early as the period when these project management techniques were applied. The reason behind PMO implementation was mainly to have cost control and a standard planning approach that allows budget estimates.

These structures that emerged during the US army's development of complex missile systems in the 1950s carried the basic characteristics of modern PMOs. Each weapon system was supervised by System Program Offices (SPO) where multiple sub-projects were brought together. These offices coordinated not only project systems but also all related sub-projects. Military and aviation giants like NASA and the US Department of Defense demanded rigorous project oversight to execute complex and high-risk projects. The first PMOs emerged to ensure success and brought structure, governance, and precision to critical mission projects that shaped history. In the 1950s, the Polaris Missile Program formalized PMO practices by emphasizing coordination and integration in managing the development of submarine-launched ballistic missiles. The development of the Boeing 707 also marked a significant advancement in aviation PMO practices, ensuring the jet passenger aircraft met performance, safety, and profitability targets. The B707 was put into service by Pan Am in 1958.

This military-originated development transformed PMOs from being merely documentation centers into units responsible for strategic management of project portfolios. While the US Department of Defense developed the Program Evaluation and Review Technique (PERT) in the late 1950s, private sector companies adopted the Critical Path Method (CPM). These methodologies laid the foundations for structured project planning and execution. During this period, industries recognized the need for a central structure to oversee projects, leading to the formation of the early conceptual framework of PMO. However, PMOs were still rarely seen and were mainly found in government agencies and large-scale engineering firms.

2.4.             1960-80s - Corporate Adaptation: Expansion to the civilian sector

In the 1960s, many American organizations (government and non-profit) had a PMO, but there was no clear indication of their functions, purpose, or forms. From agriculture and taxation to housing, civil infrastructure, military procurement, scientific exploration (space, deep sea, and polar), education, numerous government agencies and profit-making organizations indicate they had PMOs. NASA's Apollo Program in the 1960s relied on rigorous PMO practices to manage the complexity of landing a human on the moon, marking a defining moment in project management history. In subsequent years, the Space Shuttle Program consolidated the role of PMOs in managing comprehensive and multifaceted projects, emphasizing the importance of continuous improvement and risk management. Large-scale construction projects and engineering initiatives became the first civilian adaptation areas of the PMO concept. Projects in these sectors required complexity levels and multidisciplinary approaches similar to military projects.

The series of PMO articles published in the 1970s is the first example of organizational research specific to PMOs. The 1970s was the period when organizational researchers began to observe what was happening inside PMOs. As mentioned earlier, costs have been an important factor in PMO literature both from a functional perspective and as a matter of perception. Researching project costs in the first cost estimation phase was the subject of Davis's (1976) research on a US Army PMO. The main problems with estimates were found to be unforeseen high-level changes, inflation, incorrect cost estimation, technical problems, and lack of information. He concludes that PMO would benefit from learning to cope with uncertainty and improving estimation capability.

In the 1980s, numerous PMO literature transformations occur. PMOs are now included in discussions related to software development. However, PMO is neither defined nor explained. There seems to be an emerging theme in 1980s PMO literature that PMO selects the tools, processes, and methodologies that should be used by project managers.

2.5.             1990s - Professionalization: Development of standards

This is the period from the 1980s when PMO was expanded to other sectors such as construction, IT, etc., until the 1990s when it began to gain popularity. In fact, in the 1990s, PMO became a kind of organizational innovation that strengthened its position day by day within large international structures. One of the first corporate PMOs (Center of Excellence) was established by IBM in 1996. Industry leaders like Microsoft also established PMOs to facilitate and standardize project execution. At the same time, the Project Management Institute (PMI) played a key role in formalizing best practices and shaped the modern PMO as a strategic force in the business world. The International Space Station (ISS) project in the 1990s showcased the role of PMO in facilitating international cooperation and managing a complex, long-term project with contributions from multiple countries.

2.6.             2000s - Strategic Partnership and Agility

Starting from the 2000s, various organizations and institutes showed interest in PMO by conducting various studies aimed at promoting PMO and exploring its aspects. Recently, the organization of the first PMO Symposium by PMI in 2009, the creation of the first professional community dedicated to PMO "PMO Global Alliance" in 2014, and the organization of the first PMO Conference in London in 2015 are important milestones. The 2000s was the period when PMOs moved upward in the organizational hierarchy and assumed a strategic partnership role. PMOs evolved from merely coordinating projects to becoming strategic partners that align projects with organizational goals.

During this period, PMOs focused not only on delivering projects on time and within budget but also on measuring and optimizing the value they provide to the organization. Organizational change management became one of the core competency areas of PMOs. PMOs began to manage the effects of projects on organizational culture and processes. The 2010s represent the adaptation process of PMOs with the widespread adoption of agile methodologies. Organizations began developing hybrid models instead of completely traditional or completely agile approaches.

3.   CONCLUSION

The approximately century-long evolution process of PMOs presents a development story that reflects fundamental changes in organizational management paradigms. These structures, which started as simple documentation centers in the 1930s, have today become technology-supported, agile, and value-focused units that play a critical role in helping organizations achieve their strategic goals.

This evolution process should be understood not only as parallel to the development of the project management discipline but also as an adaptation process to increasing organizational complexity, technological innovations, and paradigmatic changes in the business world.

In the future, PMOs are expected to become even more sophisticated structures that integrate artificial intelligence, sustainability, and ecosystem approaches. To be successful in this process, organizations should design their PMOs as structures that are open to continuous evolution, learning, and adapting.

The ongoing nature of PMO evolution shows that these institutional structures will continue to maintain their positions as critical providers of organizational success in the future. However, this success is directly related to the capacity to adapt to the constantly changing business environment and the focus on creating strategic value.

 

 

 

References:

(1): PMO Typologies and Functions: A Systematic Review
May 2020European Scientific Journal 16(13):180
https://www.researchgate.net/publication/341788265_PMO_Typologies_and_Functions_A_Systematic_Review

(2) Giraudo, L. & Monaldi, E. (2015). PMO evolution: from the origin to the future. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute.
https://www.pmi.org/learning/library/pmo-evolution-9645

(3) Eric John Darling Stephen Jonathan Whitty, (2016),"The project management office: it's just not what it used to be",
International Journal of Managing Projects in Business, Vol. 9 Iss 2 pp. -
http://dx.doi.org/10.1108/IJMPB-08-2015-0083

(4): The Evolution of the PMO: A Historical Overview
PMO Global Institute -Medium Article (May 29, 2023)
https://medium.com/@pmoglobalinstitute/the-evolution-of-the-pmo-a-historical-overview-c92cb609139e

(5): The evolution of the PMO
Practicus Article -- 08 Feb 2021
https://www.practicus.com/blog/evolution-pmo

(6) PMO evolution
Conference Paper PMO, Strategy 11 May 2015
Giraudo, Luca | Monaldi, Emmanuele
https://www.pmi.org/learning/library/pmo-evolution-9645

(7) Evolution of Project Management Offices (PMOs): An Overview
Insights By Jamie Riddle
https://aimconsulting.com/insights/project-management-offices-pmos-evolution-overview/

(8) EVOLUTION OF THE PROJECT MANAGEMENT OFFICE (PMO)
From Administrative to Strategic: Building the Next Gen PMOs
Siddharth Sharma, Vice President, International Consulting
https://www.nttdata.com/global/en/insights/focus/2024/evolution-of-the-project-management-office

(9) What is the Role of a Project Management Office?
Benoît Boitard
https://www.sciforma.com/blog/what-is-the-role-of-a-project-management-office/

 


26 Aralık 2024

Time Management: 3-5-8 Method

 


Time Management: 3-5-8 Method

I would like to share the time management method that I used for a long time. Task prioritation is very important for time management. It is very difficult to track the a lot of task at that same time. I have to prioritize the my tasks which ones I have to manage. There are a lot of time management methods that you can see in business literature. However, I experienced some difficulties in using them. ⏰

That's why I generated a new method.

👉 The players knows the sergeant major game (3-5-8). It is played within 3 players.

However, here I would like to explain the 3-5-8 method that I used for time management and task tracking. So that:

🟥 3 Tasks Group (Group-3): These tasks that are most urgent and need to be tracked or done. I think that a person can deal with a maximum of 3 tasks at the same time. This is important for in order to focus his concentration and pay attention. More than 3 tasks are unrealistic. You can say the maximum 3 tasks or issues at once. There should always be 3 tasks. If there are fewer than 3 taks, a task can be transfered from 5 tasks group which is defined below.


🟨 5 Tasks Group (Group-5): These tasks are that have less priority than the group-3 taks. These tasks can go up to group-3 when the task where is in Group-3, is completed. They are important, but they are tasks for which you cannot take quick action at that moment. There should always be 5 tasks. If there are fewer than 5 taks, a task can be transfered from 8 tasks group which is defined below.

🟦 8 Tasks Group (Group-8): These are the most less priority tasks. After a while, a few of them may go up to a Group-5 or become outdated. There can be a maximum of 8 task or can be fewer, but there should be no more than 8 tasks.

✳️ Due to these conditions, an employee can manage the 3+5+8=16 jobs in total. No more is not meaningfull. If you are interested in more work, there is a problem. Managers have to delegate the tasks in this case. ✳️

I can recommend this method. I hope you will take advantage of it too.

hashtagtime hashtagmanagement hashtagmethod hashtagtimemanagement

19 Nisan 2020

Proje Yöneticisinin Dokunduğu Fil-4



Proje Yöneticisinin Dokunduğu Fil-4

"Proje Yöneticisi ve Dokunduğu Fil(Proje)"  yazı dizimize "Yılan" konusu ile devam ediyorum. Bu yazımızda proje ekibinde yılan gibi davranış sergileyenleri ve projelerde güvenliği ele alacağız. Yazı dizimizin konusunu oluşturan "Körler ve Fil" şiirinde John Godfrey Saxe  şöyle yazmıştı:

Üçüncüsü hayvana yaklaştı
Ve mutlulukla tuttu
Elleri içinde hortumunu
Böylece cesaretlendi ve konuştu:
“Anladım” dedi aynen
“Fil daha çok bir yılan gibi”

Yılan, elbette tehlikeli bir yaratıktır. Ancak herkes yılanların ne yapacağını bilir! Yılan zehirler, ısırır ve hatta boğabilir. Bu yılandan beklenen bir davranıştır. Bir kimse yılanı eline alıp, onun kendisine zarar vermeyeceğini düşünemez. Sirklerde yılanlarla gösteri yapanlar ya da Hindistan'da yılan oynatanlar riske girmemek için yılanların zehirlerini yok ederler. Çünkü kimse yılanın zehirlemeyeceğini garanti edemez. Bu girizgahtan sonra fazla oyalamadan sorumu sorayım:

"Proje ekiplerindeki HERKES en az sizin kadar projeyi sahiplenir mi?"

Soru basit ama bu soruya beklemeden, düşünmeden "evet" cevabını veriyorsanız; ya çok fazla iyimsersiniz ya da gerçekten safsınız, demektir.

Proje ekipleri oluşturulurken başta duyulan heyecan ve şevk uzun süre kalıcı olamayabilir. Bir proje yöneticisinin görevi elbette bu heyecanı ve şevki en üst düzeyde tutabilmektir. Tamam, ancak herkes bu kadar iyi niyetli midir? Proje ekiplerindeki yılan gibi davranış sergileyenleri ne yapacağız Gerçekten çok itici ve tiksindirici bir durum bu. Proje ekiplerinde yılanların var olduğunu düşünmek, inanmak ve birilerini bu şekilde etiketlemek, yaftalamak ne kadar zor! Hiç kimsenin buna cesaret edebileceğini düşünemiyorum ancak gerçekten proje ekiplerinde yılanlar olabilir.  Fazla iyi niyetli olmaya, kendimizi inandırmaya, kandırmaya çalışmayalım.

Bu gerçeği kabullenerek, yeniden değerlendirelim. Siz, proje ekibinizdeki herkesten, projenize yeterli dikkatin ve önemin verilmesini beklersiniz ancak diğer tarafta sizin proje(ler)iniz başkaları için var olan işlerinin üstüne eklenmiş ekstra işler olarak düşünülebilir. Onların da sizin kadar projenizi sahiplenmesi mümkün değildir. Hatta sizin projenizin ortaya çıkaracağı iş ürünleri veya hizmetler; diğer kişilerin çalışma biçimiyle veya kariyer hedefleriyle çatışabilir. Geçmişte birçok otomasyon projelerinden rahatsız olan, işini kaybedeceğini düşünen çalışanlar, projelere engeller çıkarmışlar.

Elbette herkes kötü niyetli değildir. Bazen proje ekiplerindeki kişiler, iyi niyetli olarak rollerine uygun olan bazı konulara daha fazla önem verilmesini, daha dikkatli olunmasını isterler. Hatta projeyi o yöne doğru çekiştirirler. Sanki o konudaki çalışmaların yapılmasını, projede başarının sağlanması için yeterli ve tek koşul olarak düşünürler. Herkesin de böyle düşünmesini beklerler. Bir süre sonra her bir roldeki çalışan, projeyi kendilerinin ilgi alanlarına doğru çekmeye çalışırlar. Proje ana hedefinden çıkıp, sadece baskın birilerinin ilgi alanındaki çalışmaları gerçekleştirmeye odaklanılır. Proje ekiplerindeki kişiler bunu bazen bilmeyerek, bazen de kendi çıkarları doğrultusunda bilerek yaparlar. Proje yöneticisinin, projenin hangi yöne doğru çekiştirildiğinin farkına varıp, uyanık davranması gerekmektedir.

Proje ekiplerindeki yılanların en tehlikeli oldukları bir diğer konu ise bilgi güvenliğidir. Bazı çalışanlar, projelerdeki kritik bilgileri başkalarıyla paylaşabilirler. Bunun için firma bünyesinde ya da en azından proje seviyesinde yeterli bilgi güvenlik altyapısı kurulmalıdır. Bilgi güvenliği olarak  sadece teknik bilgilerin paylaşılması düşünülmemelidir. Projenin o aşamadaki durumu, proje ekiplerinde kimlerin yer aldığı, müşteri bilgisi, projede yaşanılan aksaklıklar, proje bütçesi, takvimi, paydaşları gibi bilgilerin de paylaşılmaması önemlidir. Rakip firmaların proje hakkında elde edeceği ufak bir bilgi kırıntısı bile projeyi ve firmayı zor durumda bırakabilecektir. Bu nedenle, proje ekiplerindeki yılanların güvenlik açıklarından sızma girişimlerine engel olunmalı, gerekli güvenlik tedbirleri devreye alınmalıdır. Aksi halde en küçük ve göz ardı edilen bir yerden sızıntı olabilecektir.

Proje yöneticileri her zaman dikkatli olmalı, bilinçli veya bilinçsiz şekilde tartışmalara girmemelidir. Bazen bu tür tartışmalar ne projeye ne de kendisine fayda sağlayacaktır. Aksine projeler sekteye uğrayacaktır. Fazla iyi niyet ve saflıktan uzak durup, gerçekçi olmakta fayda vardır.

26 Şubat 2020

Proje Yöneticisinin Dokunduğu Fil-3




Proje Yöneticisinin Dokunduğu Fil-3

"Proje Yöneticisi ve Dokunduğu Fil(Proje)"  yazı dizimize "Mızrak" konusu ile devam ediyorum.  Önceki yazılarımızda (Yazı-1 , Yazı-2 ) giriş yapmış ve projelerde karşılaşılan engeller ve aşılması gereken duvarları ele almıştık. Bu yazımızda projelerdeki savaşçıları ve projelerin bir savaş olup olmadığını değerlendireceğiz.  Yazı dizimizin konusunu oluşturan "Körler ve Fil" şiirinde John Godfrey Saxe  şöyle yazmıştı:

İkincisi uzun dişini elledi
Çığlıkla “Hey! Burada ne var?
“Çok yuvarlak, düzgün ve sivri
Çok açık ve net
Bu harika bir özellik
Daha çok bir mızrak gibi”

Bir olguya dikkat çekmek, önemini arttırmak, yüceltmek veya ilgi duyulmasını sağlamak için kullanılan yöntemlerden en önemlisi "metaforları" kullanmaktır. Yapılacak benzetmeler, o konuda söylenecek bir çok sözün yerini alabilecektir.  Bu nedenle bazı proje yöneticileri, projelerinde "savaş" ve "savaşçı" metaforunu kullanmayı severler. Onlara göre projeler bir savaş meydanıdır, proje ekibinin her bir elemanı da korkusuz, gözü pek savaşçılardır. 

Proje yöneticilerinin veya bazen proje sponsorlarının motivasyonu arttırmak için başvurduğu bu yöntem bir süre sonra metaforların karmaşasına dönebilir. Projeler savaş meydanı, proje yöneticilerini komutan ve proje ekibi de savaşçılar olarak gösterilmek istenirse; doğal olarak karşıya "düşman", "kutsal toprak/alan" ve "taarruz, taktik, siper" gibi metaforları yerleştirmek gerekecektir. Savaşın tüm argümanlarının "proje" olgusunun içine yedirilmesi istenecektir.  Savaşın nitelikleri konusunda Sun Tzu'nun Savaş Sanatı  ve  Carl von Clausewitz  tarafından yazılan Savaş Üzerine kitaplarında bu metaforlara yeterince yer verilmiştir. Sun Tzu savaşlarda akılcılığı ön plana çıkarıp, kan dökmeden savaşı kazanmanın yollarını bulmanın önemine değinmiştir, taktik ve strateji olarak ılıman bir anlayışı benimsemiştir. Clausewitz  ise belki de Avrupalı olmanın verdiği bir hırsla, savaşları ölüm ve öldürme üzerine konumlandırmıştır. Ona göre savaş, kan dökerek düşmanı yok etmektir ve zaferler ancak bu yolla kazanılır.

Projeler savaş meydanı olarak görülürse, proje planları katılaşır, değiştirilmesi zorlaşır. Proje ekibinin her biri, kendisini emir alan ve/veya emir veren savaşçılar olarak düşünür. Projede sunulacak çözüm "önerileri", sanki birer emir olarak algılanır. Esneklik ortadan kalkar ve verilen emir harfiyen uygulanmaya çalışılır. Proje ekipleri işlerini ancak emir aldıkları zaman gerçekleştirirler. Proje yöneticileri de tıpkı bir komutan gibi, ekibini bir yerden bir yere harekata yöneltmeye çalışırlar. Gereksinimleri, tasarımları veya iş planlarını sorgulamak asla mümkün değildir. Birileri karar vermiştir, ekibe sadece uygulamak düşer. Sorgulamak asla düşünülemez!

Belki bazı proje yöneticileri için komutan gibi emirler verip, yapılmasını istemek tercih sebebidir. Öyle ya! Ekibine "bunu yapın!" dediği zaman itiraz edilmeden yapılması işlerini kolaylaştıracaktır diye düşünebilir. Ancak bu sakıncalı bir metafordur. Projeler birer savaş değildir. Proje yöneticileri hiçbir zaman emir veren komutanlar değildirler. Geçmişte okuduğum bir yazıda projeler satranç oyununa benzetiliyordu. Aklıma ilk gelen "piyonlar kimler?" demek olmuştu. Proje ekibinde "at", "fil", "kale" gibi roller üstlenenler varsa; demek ki, ortada kolayca gözden çıkarılabilecek "piyonlar" da olmalıydı. Ekibin bir kısmını piyon gibi gören bir proje yöneticisi olamazdı, olmamalıydı. Hangi çalışan, kendisinin bir projede piyon gibi değersiz görülmesini kabul edebilirdi.

Günümüzdeki projelerde emirleri yerine getiren askerler yerine itaat etmeyen, çözümlere itiraz eden, sorgulayan, eleştiren, daha iyi bir çözümü olduğunu iddia eden askerlere ihtiyaç vardır. Bu kişilerle bir projede birlikte çalışmak bir proje yöneticisi için katlanılması zor ve istenilmeyen durumdur. Ancak  bu tür "kötü?" askerler de proje ekiplerinde olmalıdır. Elindeki mızrak ile sadece savaşmayı düşleyen "iyi" askerler yerine mızrağın neden elinde olduğunu sorgulayan "kötü" askerler de gereklidir.

Projeler, savaş alanı olarak görülürse karşımızda saldıracağımız bir düşman gerekecektir. Bu düşmanlar, müşterilerimiz midir? Ya da son kullanıcılar mıdır? Projenin başka herhangi bir paydaşı düşmanımız mıdır? Böyle bir şey düşünülebilir mi? Asla. Belki rekabet içinde olduğumuz başka firmalarla mücadele etmemiz beklenebilir ancak bunları da hiç bir zaman yok edilmesi gereken düşmanlar olarak ele almamızı gerektirmez. Öyleyse, ortada bir düşman yoksa, savaş da yoktur. Proje ekibinin mücadeleci olması elbette gereklidir ancak hiç birinin öldürücü silahlarını kuşanmış savaşçılar olmasına gerek yoktur.

Projelerde de elbette "strateji", "taktik" ve "harekat" gibi kavramlar vardır. Bu konuyu ileride uzun  bir yazı dizisi olarak ele alacağız. Ancak projelerdeki strateji, taktik, taarruz ve harekat gibi kavramlar askeri alandakilerle aynı değildir. Savaş stratejileri belki proje planları kadar esnek olmayabilir. Taarruz edecek ordu da sadece mızraklarını havaya kaldırmış askerler değildir. Metaforlar her yerde aynı şeyleri karşılamayabilir. Metafor kullanımında dikkatli olmak gerekir.

Son olarak; projelerin bir savaş alanı, projeyi bir mızrak olarak olarak gören "körler" elbet bir gün proje ekibindekilerle de savaşmaya başlayacaklardır. Proje yöneticisi kendisini emirler veren bir komutan olarak görmeyi bırakıp; itaat etmeyen, çözümlere itiraz eden, sorgulayan, eleştiren, daha iyi bir çözümü olduğunu iddia eden ekip üyelerine katlanabilen liderler olmalıdırlar!

02 Şubat 2020

Proje Yöneticisinin Dokunduğu Fil-2



Proje Yöneticisinin Dokunduğu Fil-2

Önceki yazımızda başladığımız "Proje Yöneticisi ve Dokunduğu Fil(Proje)" konusunda yeni bir yazı ile devam ediyorum. Bu yazımızın ana konusu projelerde karşılaşılan engeller ve aşılması gereken duvarlardır.  Yazı dizimizin konusunu oluşturan "Körler ve Fil" şiirinde John Godfrey Saxe  şöyle yazmıştı:

Birincisi file yaklaştı
Ve rastlantı sonucu yaslanınca
Onun güçlü ve geniş gövdesine karşı
Bağırmaya başladı:
“Aman Tanrım! Fakat bu fil
Tıpkı bir duvar gibi.”

Projenin başında ekipler oluşturulurken herkesin hemen işe koyulacağı düşünülür. Ancak henüz hazır olmayanlar vardır.   Henüz ne projeyi, ne de projeden beklenenleri (misyon ve vizyon) tam olarak anlayamamıştır, belki de anlamamak isterler. Sürekli yakınma, ayak sürüme, inatlaşma ve zorluk çıkarma halindedirler. Proje yöneticisi için asıl serüven başlamıştır. Ekip içindeki uyumu sağlamak adına bu kişilerin ekipten çıkarılması, en kolay ve ilk akla gelen yöntemdir. Onların ortaya koyacakları engeller ve zorluklar ileride ekip içinde huzursuzluk yaratacaktır ve projenin tamamlanmasına sebep olacaktır. Hangi proje yöneticisi böyle bir durumu ister!

Elbette hemen "Duvar" ören ekip üyelerinin bu davranışlarını kötümser bir bakış açısıyla değerlendirmemek gerekir. Aslında bir kısmının tepkilerinin temelinde, projenin başında hızlanmak adına atlanan, önemsiz gibi görünen hususların dikkate alınmaması yatmaktadır. Projeye hızlı bir başlangıç yapmak, tabiri caizse gaza basmak ve bir an evvel bir şeyleri ortaya çıkarmak her proje yöneticisinin hayalidir. Çünkü daha alınacak çok yol vardır ve bir şeyleri hızlıca halletmek ve diğer işlere başlamak ne de güzel olur.. Ama zaman içinde duvar(lar)a toslanılır.. Proje ekibindekiler çeşitli gerekçeler nedeniyle duvarlarını örmeye başlamışlardır. Her geçen zaman içinde bu duvarlara birer birer tuğlalar (mazeretler, sorunlar, kaprisler, zorluklar) örülür.

Proje yöneticisinin her bir duvarı yıkmak, üstünden atlamak veya duvarlar arasında delikler açmak için yeterince zamanı, gücü ve enerjisi olamayabilir. Öyle ya! Ekip içindekilerin ördükleri duvarların yükseklikleri, kalınlıkları ve malzemeleri farklı farklı olacaktır. Hepsinin üstesinden gelmeye çalışırken, projenin asıl işlerine odaklanmakta zorlanacaktır. Ayrıca bir duvar yıkılırken başka bir ekip üyesi başka bir duvar daha örmeye başlamış olabilir. Elbette bu durumda olanlar sadece proje yöneticisi değildir . Projede henüz heyecanını yitirmemiş, hızlıca bir şeyler yapmaya çalışan diğer çalışanlar da bu duvarlarla karşılaşacaktır.

Projede örülen duvarlarla yaşamak mümkün değildir. Duvarları yıkmak da mümkün olamadığına göre en kolay çözüm duvarların örülmesini baştan önlemektir. Bunun için anahtar soru şudur:"Ne İstiyorsun?" Projede duvar örenlere karşı uygulanacak yöntem; proje kapsamında ne yapmak istediklerini sormaktır.

Proje sponsorunun projeden beklentisi elbette projenin zamanında tamamlanıp, proje kapsamındaki hak edişin veya ödemenin yapılması olacaktır. Bundan başka bir beklentisinin olması mümkün değildir. Proje yöneticisinin beklentisi ise verilen kaynakları kullanarak, proje bütçesi ve zamanı içinde çalışmaları tamamlamak ve gereksinimleri karşılamaktır. Bunda da bir gariplik yoktur. Ancak ya diğer ekip üyeleri?!

Diğer proje ekibindekilerin de projeden tek beklentileri; "Verilen kaynakları kullanarak, proje bütçesi ve zamanı içinde çalışmaları tamamlamak ve gereksinimleri karşılamak mıdır?". Bazıları için belki geçerli olabilir ancak çoğunun  böyle bir beklentisi, derdi ve amacı yoktur! Evet, proje yöneticileri açısından zor bir durum olsa da, diğer ekip üyelerinin onlar kadar projenin riskleri, hususlarıyla ilgisi yoktur, olamayacaktır.. 

Pekala, ne yapmalı?!

Proje ekibindekilere projenin başında "Bu projede ne yapmak istiyorsunuz?" sorusu ile projedeki işleri kapsamında "kendi projelerini"  yaratmalarını sağlamak gerekmektedir. Asıl proje kapsamında tamamlanması gereken işlerin dışına çıkmamak koşulu ile; örneğin bir yazılım geliştirici açısından "kendisinin en iyi yazılım mimarisini oluşturma" projesini yaratmasını sağlamak gerekir. Aynı şekilde bir test sorumlusu açısından "kendisinin en iyi sistem performansını sınama" projesini; analistin "şu alandaki kavramlara hakim olma, deneyim edinme" projesini; kalite sorumlusunun "şu şu standartları projede uygulayabilme ve süreçleri oluşturabilme" projesini yaratmasını sağlamaktır.

Proje ekipleri, proje içinde kendi projelerini yarattıkları sürece duvar örmeyi bırakacaklardır. Duvar örmek için harcayacakları zamanı, enerjiyi ve gücü kendi projelerine ayıracaklardır. Böylece asıl projedeki engeller de ortadan kalkacaktır.

Son olarak; projede duvar ören ekip üyelerine olumsuz yaklaşmadan, projeden ne istediklerini ortaya çıkarmak ve proje kapsamında kendi projelerini yaratmaları sağlanmalıdır!