Harika bir proje brief’i, proje başlamadan önce herkesi aynı sayfaya getirir; ne inşa ediliyor, neden önemli, kimler dahil ve başarı nasıl ölçülecek. Trupeer ile ücretsiz bir proje brief şablonuyla başlayarak, bunu marka kimliğiniz ile özelleştirerek ve brief’i paydaşların 3 dakikada izleyebileceği kısa bir video özetine dönüştürerek proje brief’leri yazmaya ayırdığınız saatleri tasarruf edebilirsiniz.

Proje brief şablonu nedir ve ne zaman yazılır?

Proje brief’i, plan henüz yokken projenin en başında yazılan kısa belgedir; projenin ne için olduğunu, şimdi neden önemli olduğunu, kimleri etkilediğini, başarının nasıl göründüğünü ve onu kısıtlayan unsurları söyler.

İnsanların çalışmayı yetkilendirmek için imzaladığı şeydir ve altı ay sonra herkesin karşı çıktığı referans noktası haline gelir. Bilerek kısadır; genellikle bir veya iki sayfadır; çünkü en az bilginin olduğu anda yazılır.

Bir şablon size bölümleri verir: Arka plan, hedefler, kapsam, teslimatlar, zaman çizelgesi, bütçe, paydaşlar, başarı kriterleri. Bulacağınız her sürüm kabaca bunları sunar ve bunlarda yanlış olan hiçbir şey yoktur.

Brief’lerle ilgili sorun neredeyse hiç bölümler değildir. Sorun, bu bölümlerin içine ne konduğudur.

Çoğu brief bir problemi değil, bir çözümü belirtir

Her teslimat ekibinin, ajansın ve mühendislik grubunun brief’lerle ilgili yaptığı şikâyet şudur; her sektörde aynı şekilde dile getirilir: bize çözüme göre brief verildi.

"Müşteri portalı oluşturun." "Yeni bir intranet oluşturun." "Mobil uygulama teslim edin." "Onboarding akışını yeniden tasarlayın." Bunların her biri inşa edilecek bir şeydir; sanki bir gereklilikmiş gibi gelir. Oysa brief’in hiç dile getirmediği bir soruya verilen bir cevaptır.

Bu, makul bir nedenle olur. Projeyi kim görevlendiriyorsa genellikle bunu haftalardır düşünmüştür ve bir sonuca varmıştır. Sonucu yazmak netlik gibi gelir; problemi yazmak ise belirsizlik gibi gelir.

Bedeli şudur: En ucuz çözümler, kimse bakmadan elenir. Brief portal diyorsa proje de portal projesidir ve paranın %5’iyle problemin %80’ini çözecek seçenek hiç değerlendirilmez; çünkü kimse hiçbir şeyi değerlendirmeye çağrılmamıştır.

Bir problem belirten brief yanıtları davet eder. Bir çözüm belirten brief ise tahminleri davet eder.

Bu şablon Trupeer’da nasıl özelleştirilir

Adım 1: Şablonlar Bölümünü Açın

Ana navigasyondan Şablonlar bölümüne gidin.

Adım 2: Bir Şablon Seçin ve Açın

Açmak istediğiniz herhangi bir şablonun üzerine tıklayın.

Adım 3: Şablon Görünümünü Genişletin

Gerekirse, tam düzeni ve ayrıntıları net görmek için şablon görünümünü genişletin.

Adım 4: Şablonu Düzenleyin

Seçili şablonda değişiklik yapmaya başlamak için Düzenle’ye tıklayın.

Düzenleyici içinde şunları yapabilirsiniz:

• Yeni bölümler ekleyin

• Biçimlendirme kurallarını tanımlayın veya güncelleyin

• Bir logo ekleyin ve konumunu ile ilgili ayarları düzenleyin

Adım 5: Özelleştirilmiş Şablonunuzu Kaydedin

Gerekli tüm değişiklikleri yaptıktan sonra, güncellenmiş şablonu kendi şablonunuz olarak saklamak için Kaydet’e tıklayın.

Adım 6: Şablonu Önizleyin ve İnce Ayar Yapın

Özelleştirilmiş şablonunuzun nasıl göründüğünü görmek istediğinizde Önizleme’yi açın.

Önizleme ekranından, gerekirse doğrudan ayarlamalar yapmaya devam edebilir; böylece şablonun tam olarak istediğiniz gibi göründüğünden emin olursunuz.

Bir proje brief şablonuyla şunları yapabilirsiniz:

• Yazmaya ayırdığınız saatlerden tasarruf edin: Kanıtlanmış bir brief yapısıyla boş sayfayı atlayın.

• Paydaşları hızlıca hizalayın: Tek sayfalık brief’ler onayları ve hizalamayı daha hızlı hale getirir.

• Markanıza uygun kalın: Trupeer’ın marka kitini kullanarak logonuzu, yazı tiplerinizi ve renklerinizi uygulayın - ajans ve müşteri brief’leri için ideal.

• Etkiyle sunun: Brief’i bir video özetine dönüştürün - satış enablement ve paydaş sunumları için harika.

• Tüm projelerde standardize edin: Her girişim için aynı brief formatını kullanın.

• Küresel ekiplere ulaşın: Brief’leri tek tıkla 65+ dile çevirin.

Her proje brief’i için üç yanıt testi

İki dakika ve çalıştırmaya değer tek brief testi budur.

Brief’i okuyun ve onu gerçekten tatmin edecek üç farklı şeyi adlandırın.

Aynı şeyin üç varyasyonu değil. Üç farklı yaklaşım: bir şey inşa edin, bir süreci değiştirin, bir şey satın alın, bir adımı kaldırın, farklı iletişim kurun, daha az yapın.

Üçünü adlandırabiliyorsanız, brief bir problemi anlatır ve önünüzde gerçek bir karar vardır.

Sadece birini adlandırabiliyorsanız, brief bir çözümü anlatır. Bu otomatik olarak yanlış değildir; çünkü bazen karar gerçekten iyi nedenlerle alınmıştır ve bu durumda dürüst olan, bunu söylemek ve belgeyi brief yerine bir teknik şartname olarak adlandırmaktır. Dürüst olmayan şey, önceden verilmiş bir sonucu açık bir soru gibi sunup sonra kimsenin buna itiraz etmemesine şaşırmaktır.

Bu testi, brief dolaşıma çıkmadan önce ve onu yazmaya dahil olmayan biriyle birlikte çalıştırın. Brief’i yazan kişi her zaman üçünü adlandırabilir; çünkü neyi reddettiğini bilir. Kimse başka biri adlandıramaz; çünkü brief’in içinde bu yoktur.

Teslimat yerine problemi nasıl yazarsınız

Dört alışkanlık ve hiçbiri, çözümü yazmaktan daha uzun sürmez.

Bir gözlem ve bir sayı ile başlayın. "Müşteriler siparişlerini kontrol etmekte zorlanıyor" demeyin; "Müşteriler geçen ay siparişlerinin nerede olduğunu sormak için altı bin yedi yüz kez bize ulaştı" deyin. Sayı iki şey yapar: problemin gerçek olduğunu ortaya koyar ve bir çözümün değerini ölçer.

Şu anda ne olduğuna dair bilgi verin. Problemin şu an nasıl ele alındığı, kötü şekilde de olsa; insanların icat ettiği geçici çözüm dahil. Mevcut durum açıklaması, birinin daha ucuz bir yanıt önermesini mümkün kılar.

Kısıtları gereksinimlerden ayırın. Bütçe bir kısıttır. Son tarih bir kısıttır. Mevcut depo sistemiyle entegre olmalı olması bir kısıttır. "Giriş yapılması gerekir" ise bir gereksinimdir; kısıt gibi gizlenmiştir ve genellikle çözümün birinin zihnindeki tasvirinden gelir.

Başarıyı teslimatın varlığı olarak değil, sayıdaki bir değişim olarak tanımlayın. Altı ay içinde bu temasları yarıya indirmek bir başarı kriteridir. Portalı yayına almak bir kilometre taşıdır.

Gerçekten bir çözüm aklınızda varsa, bunu brief’in kendisi gibi değil; açıkça etiketlenmiş bir bölümde, bir aday olarak belirtin.

Ücretsiz proje brief şablonu: kopyalanacak yapı

Buradan kopyalayın. Bir veya iki sayfa ve genişletmeye direnin.

Başlık. Proje adı, sponsor, yazar, tarih, sürüm ve talep edilen karar.

Problem. Bir sayı içeren bir gözlem; ne sıklıkta gerçekleştiği ve maliyeti. İki veya üç cümle.

Şu an nasıl ele alınıyor. Mevcut süreç; geçici çözüm dahil ve neden yeterli olmadığı.

Şimdi neden. Bu çeyrekte bunu yapmaya değer kılan değişiklik ne.

Kimler etkileniyor. Dahil olan kişiler veya müşteriler ve kabaca kaç kişi.

Başarı kriterleri. Hangi sayının, ne kadar ve ne zamana kadar değişmesi gerekiyor. Sonuçlar olarak ifade edilen bir veya iki madde.

Kısıtlar. Bütçe, son tarih, değiştirilemeyen sistemler, düzenleyici veya sözleşmesel yükümlülükler, müsait olmayan kişiler. Gerçekten sabit olan her şey ve aslında bir tercih olmayan hiçbir şey.

Kapsam dışı. Bu projenin ele almayacağı şeyler; tartışmalı olabilecek kadar spesifik şekilde adlandırın.

Varsayılan yaklaşımlar, varsa. Çözümler zaten değerlendirilmişse, bunları brief olarak değil aday olarak açıkça etiketleyin ve her birinin listede olma nedeniyle birlikte yazın.

Talep edilen karar ve kim tarafından. Ne istiyorsunuz ve kim bunu onaylıyor.

Buraya kadar kopyalayın. Brief iki sayfayı aşarsa genellikle neden arka plandır; bu da kimsenin okumayacağı bir ek bölümüne aittir ve sorun değildir.

Kimsenin kayıt olmadığı bir portalı inşa eden perakendeci

Ashfold Group, yaklaşık doksan mağazası olan ve güçlü bir çevrimiçi işi bulunan uzman bir perakendecidir.

Brief iki sayfaydı, iyi yazılmıştı ve zorluk çekmeden onaylandı. Şunu diyordu: müşterilerin sipariş durumunu görüntülemek, faturaları indirmek ve talepleri iletmek için giriş yapabildiği bir müşteri self-servis portalı oluşturun. Bütçe üç yüz kırk bin İngiliz sterlini. Dokuz ay.

Zamanında teslim edildi ve bütçeye yakın şekilde; üç yüz yetmiş bir binle.

Yayına alındıktan altı ay sonra, yaklaşık kırk altı bin aktif müşteriye karşı üç bin yüz kayıtlı hesap vardı; yani yüzde yedi’nin altında. Hizmet merkezine gelen temas hacmi değişmedi.

Uygulama sonrası değerlendirme şu basit soruyu sordu: bu, hangi problemi çözmek için inşa edilmişti? Kimse brief’te bunu işaret edemedi; çünkü brief bir çözümü tarif etmişti.

Bu yüzden biri gidip problemi buldu. Hizmet merkezi ayda yaklaşık on bir bin temas yönetiyordu. Beş yüz kişilik bir örnek, yüzde altmış birinin benim siparişimi nereden kontrol edebilirim’in bir versiyonu olduğunu gösterdi; bu da ayda yaklaşık altı bin yedi yüz temas demek.

Bu müşterilerin yüzde seksen dördü, takip bağlantısı içeren bir sevk e-postasını zaten almıştı. Ya bunu görmemişlerdi ya da bağlantı on dört gün sonra süresi dolduktan sonra geri dönmüşlerdi.

Baskın problem, dolayısıyla müşterilerin kontrol edebilecek bir yolunun olmaması değildi. Zaten sahip oldukları yolun çalışmamasıydı.

Daha ucuz üç yaklaşım hiç değerlendirilmemişti; çünkü brief hiçbirini davet etmemişti. Takip bağlantısının geçerlilik süresini uzatmak. Teslimata kadar bağlantıyı bir takvime göre yeniden göndermek. Zaten var olan hesap alanına sipariş durumunu eklemek; sonradan yaklaşık on sekiz bin sterlin olduğu tahmin edildi.

Portal, gerçek bir probleme karşı meşru bir çözümdü. En büyük problem değildi ve kayıt gerektiriyordu; müşterilerin yüzde doksan üçü bunu hiç yapmadı.

Takip projesi için brief farklı yazıldı. Müşteriler ayda altı bin yedi yüz kez siparişlerinin nerede olduğunu sormak için bize ulaşıyor. Bunların yüzde seksen dördü zaten bir takip bağlantısı almış durumda. Altı ay içinde bu temasları yarıya indirin. Kısıtlar: taşıyıcı entegrasyonunda değişiklik yok, yüz elli bin sterlin ve müşterilerin kayıt yaptırmasını gerektirmeden çalışmalı.

Üç ekip üç farklı yanıt önerdi. Seçilen çözüm altmış iki bin sterline mal oldu ve beş ay içinde bu temasları yüzde elli sekiz azalttı.

İki brief arasındaki fark şudur: ikinci brief üç şekilde yanıtlanabilirdi. Birincisi tek şekilde yanıtlanabilirdi ve o yol zaten seçilmişti.

Her proje brief’inin ihtiyaç duyduğu temel unsurlar

En fazla ağırlık taşıyan iki satır mevcut durum ve kısıtlardır ve ikisi de genellikle incedir. Mevcut durum, birinin ucuz yanıtı önermesine olanak verir. Tercihlerden dürüstçe ayrılmış kısıtlar ise bir brief’in kazara teknik şartnameye dönüşmesini engeller.

Beş adımda proje brief’i nasıl yazılır

Bir. Problemi bir sayı ile yazın. Bir sayı elde edemiyorsanız, bir öğleden sonra bir sayı bulmaya ayırın. Sayısız bir brief bir tercihtir.

İki. Mevcut durumu tanımlayın, insanların bugün bunun etrafından nasıl dolaştığı dahil.

Üç. Başarıyı o sayıdaki bir değişim olarak belirleyin, bir tarih ile birlikte.

Dört. Kısıtları listeleyin ve her birini sorgulayın. Her madde için şunu sorun: bunu kim sabitledi ve değişirse ne olur? Kabaca üçte biri genellikle değişebilir ve değişen her kısıt, mümkün yanıt aralığını genişletir.

Beş. Üç yanıt testini yazmayan biriyle çalıştırın. Başarısız olursa ya brief’i açın ya da belgeyi dürüstçe yeniden adlandırın.

Sonra dolaşıma çıkarın ve geri gelen yanıtların, en az düşündüğünüzden birini içermesini bekleyin. Hiçbiri sizi şaşırtmıyorsa, brief büyük olasılıkla bir teknik şartnamedir.

Kısıtlar ve gereksinim gibi nasıl gizlice içeri sızdırılır

Burası, çoğu brief’in sessizce teknik şartnameye dönüştüğü yerdir ve bu, kimsenin niyet etmeden olur.

Gerçek bir kısıt, projenin kontrolü dışında bir şeydir. Bütçe budur. Düzenleyici son tarih sabittir. Depo sistemi bu yıl değiştirilmiyor. Ekipte dört kişi var.

Kısıt gibi giydirilmiş bir tercih, kulağa aynı gelir. Mobil uygulama olmalı. Bir gösterge paneli gerekiyor. Kullanıcıların giriş yapması gerekir. Bunların her biri birinin çözümün zihnindeki tasviridir ve kısıtlar bölümüne girdikten sonra, aşağı akışta herkes tarafından değiştirilemez kabul edilir.

Test şudur: her madde için, bunu kimin kararlaştırdığını ve değişirse ne olacağını sorun. Gerçek bir kısıt, proje dışında bir sahibi olan ve ihlal edilirse bir sonucu bulunan şeydir. Bir tercih ise ne sahibine ne de genellikle ihlal edilirse bir sonuca sahiptir; ayrıca onu yazan kişi, doğrudan sorulursa çoğu zaman sevinçle bırakır.

Bu konuşmayı brief dolaşıma çıkmadan önce yapın. Yirmi dakika sürer ve tüm proje boyunca en yüksek değerli yirmi dakika olma eğilimindedir; çünkü kaldırılan her kısıt, mümkün yanıt ekler.

Proje brief’i, iş gerekçesi (business case) ya da proje planı mı?

Bir projeye başlangıçta, sırayla ve farklı görevlerle üç belge.

Brief, problemi, kısıtları ve başarı kriterlerini belirtir. İlk yazılır, kısadır ve araştırmayı ya da teslimatı yetkilendirir.

İş gerekçesi (business case) harcamayı gerekçelendirir. Maliyet ve faydaları olan seçenekleri içerir ve bir finans fonksiyonu ya da yatırım kurulu tarafından onaylanır. Uzayan ve sayılarla dolan bir brief genellikle yanlış adla anılan bir iş gerekçesidir.

Proje planı, seçilen yaklaşımın nasıl teslim edileceğini kapsar: kapsam, takvim, kaynaklar, bağımlılıklar ve risk. IT proje planı şablonumuz bu katmanı kapsar.

Sıra önemlidir. Brief, sonra seçenekler, sonra iş gerekçesi, sonra plan. Brief’ten önce plan yazmak; kimsenin kabul ettiğinden daha sık olur ve bu, yaklaşım problemin ifade edilmesinden önce seçilmiş demektir.

Plan var olduğunda, brief açıkça geçersiz kılınmalı ve mutabık kalınan kapsamın tek kaynağı plan olurken dosyada ikinci bir kaynak olarak bırakılmamalıdır. Otorite iddia eden iki belge, kapsam anlaşmazlıklarını çözülemez hale getirmenin yoludur.

Proje brief’i varyantları: yaratıcı, tasarım, yazılım ve inşaat

Yapı türler boyunca aynı kalır; vurgu değişir.

Yaratıcı ve pazarlama brief’leri hedef kitleyi ve mesajı gerektirir; ayrıca bir müşteri, aklında bir formatla gelirken en çok çözüm-brief’lemeye yatkındır. Buradaki problem genellikle yapmak istediğiniz bir şeyden ziyade değiştirmek istediğiniz bir davranıştır.

Tasarım brief’leri kullanıcıyı, kullanım bağlamını ve mevcut sistemin kısıtlarını gerektirir. Bu kategorideki neredeyse her brief, üç yanıt testinden fayda görür; çünkü bir tasarım brief’i bir düzeni belirtiyorsa tasarım ortadan kalkmış olur.

Yazılım proje brief’leri her şeyden önce problemi ve mevcut geçici çözümü gerektirir ve özelliklerden tamamen uzak durmalıdır. Özellikler kapsam dahil olduğunda bir gereksinim dokümanı yazıyorsunuz demektir; bunu da lean PRD şablonumuz kapsar.

İnşaat ve tasarım brief’leri gerçekten kısıt olan unsurları taşır: saha, planlama, düzenleme, bütçe. Burada kısıtlar bölümü riskten ziyade içeriğin kendisidir.

Satın alma ağırlıklı projeler brief’in, teknik şartname yerine bir çıktı olarak neyin satın alındığını belirtmesini gerektirir; çünkü teknik şartname olgunluğu kararı daha sonra gelir ve satın alma yönetim planı şablonumuz bunu kapsar.

Word veya Excel’de proje brief şablonu alabilir miyim?

Word veya Google Docs. Brief bir metindir; bir veya iki sayfadır ve onaydan önce yorum alır. İçinde bir elektronik tablo isteyen hiçbir şey yoktur.

Excel, ancak çok sayıda proje yürütüyorsanız ve bir kayıt istiyorsanız yer bulur: proje, sponsor, tek satırda problem, başarı kriteri, bütçeye ilişkin kısıt, durum ve onay tarihi. Bu kayıt, aksi halde kimsenin görmediği deseni yakalamak için gerçekten faydalıdır; yani projelerinizin ne kadarında başarı kriteri bir sayı yerine bir teslimat olarak ifade edilmiştir.

Onaylanan sürüm için PDF; imza onayında dışa aktarılır. Brief, sonraki anlaşmazlıklar için referans noktası olduğu için onaylanan sürümü bir tarihle dondurmak, çoğu dokümanda olduğundan burada daha önemlidir.

PowerPoint zayıf bir taşıyıcıdır. Slaytlar olarak sunulan bir brief, bu sayfada anlatılan aynı nedenle, problem ifadesini kaybetme ve çözümü tutma eğilimindedir.

Problemi anlatmak yerine nasıl gösterebilirsiniz

İyi bir brief’in en zor kısmı, onu deneyimlemeyen kişilere problemin gerçek hissettirilmesidir. Bir sayı yardımcı olur. Bir paragraf nadiren yardımcı olur.

Neredeyse kimsenin kullanmadığı ucuz bir alternatif var: problemin gerçekleştiğini kaydedin.

Bir hizmet temsilcisinin where-is-my-order (sipariş nerede) çağrısını ele aldığı iki dakika ya da üç tarayıcı sekmesi ve bir elektronik tabloyla bozuk bir adımın etrafından dolaşan birinin çalışması, bir sayfalık açıklamadan daha fazlasını iletir ve tartışması çok zordur. Bunu brief’e ekleyin.

Trupeer AI bunu kolaylaştırır; çünkü bir ekran kaydı hem bir video hem de mevcut sürecin yazılı bir anlatımı haline gelir; brief’in mevcut durum bölümü tam olarak bunun ihtiyacını duyar. Ayrıca, aylar sonra brief’in ifadesine güvenmek yerine ekiplerin yaklaşımlar arasında karar verirken geri dönüp bakabileceği bir şey de sağlar.

Kaydedin. Markalayın. Çevirin. Trupeer’layın.

Aynı kayıt, proje işe yarayıp yaramadığını ölçtüğünüzde sonrasında “öncesi durum” olarak da faydalıdır. İçerik, tutarlı bir markalama ile bilgi bankanızda yaşar ve kurulum talimatları doküman şablonu kurulum kılavuzunda bulunur.

Sık Sorulan Sorular

Word’de ücretsiz bir proje brief şablonu var mı?

Yukarıdaki yapı doğrudan Word veya Google Docs’a yapıştırılır. Kilitli bir indirme yoktur ve bir form yoktur. İlk yazmanız gereken iki bölüm, sayısıyla birlikte problem ve kısıtlardır; çünkü diğer her şey onlardan türetilir ve şablonların en zayıf kaldığı iki alan genellikle bunlardır.

Excel’de ücretsiz bir proje brief şablonu var mı?

Excel, tek bir brief’ten ziyade portföy genelinde brief’lerin bir kaydı için uygundur. Proje, sponsor, problemi tek satırda, başarı kriteri, bütçe kısıtı, durum ve onay tarihi için sütunlar. Bu kaydı başarı kriterleri teslimat olarak ifade edilmiş şekilde taramak, ölçülebilir bir çıktısı olmayan projeleri hızlıca bulmanın pratik bir yoludur.

PDF olarak bir proje brief örneğini nerede bulabilirim?

Yayınlanmış örnekler kolay bulunur; kamu sektörü kurumları ve sağlık kuruluşları dahil ve bölüm sırası açısından okumaya değerdir. Yayınlanmış brief’lerin büyük bir kısmının çözüm brief’i olduğunu ve bu sayfanın konusunun okumasız bir şekilde pekiştirilmiş bir alışkanlık olduğunu düşündüğünüz için onları eleştirel okuyun.

Bir proje brief’i ne kadar uzun olmalı?

Bir veya iki sayfa. Daha uzun brief’ler genellikle ek bölümde olması gereken arka planı taşır ya da iş gerekçesini içine almıştır. Eğer brief bir sponsor tarafından beş dakikada okunamıyorsa, taranarak okunur ve önce taranan bölüm problem ifadesidir.

Proje brief’ini kim yazmalı?

Sponsor ya da problemi sahiplenen kişi; ayrıca dolaşıma çıkmadan önce teslimat tarafında birinden okuma alın. İkinci okuyucu, çözüm-brief’lemeyi yakalayan kişidir; çünkü aksi halde dokuz ay boyunca yanlış cevabı inşa etmeye harcayacak olan kişi onlardır.

Proje brief’i ile yaratıcı brief arasındaki fark nedir?

Büyük ölçüde yapıdan ziyade alan (domain) farkıdır. Yaratıcı brief, hedef kitleyi, mesajı, tonu ve kanalı ekler ve genellikle bir müşteri tarafından bir ajans için yazılır. İkisi de çözüm-brief’lemeden aynı şekilde etkilenir ve üç yanıt testi, herhangi bir değişiklik yapılmadan ikisi için de geçerlidir.

Proje brief’i ne zaman onaylanmalı?

Herhangi bir planlama ya da tahmin başlamadan önce ve özellikle kimse bir yaklaşıma taahhüt etmeden önce. Yaklaşım seçildikten sonra imzalanan bir brief bir formalitedir ve kapsam daha sonra tartışıldığında yardımcı olmaz; çünkü herkes belgeyi değil yaklaşımı hatırlayacaktır.

Proje planı oluştuğunda brief’e ne olur?

Açıkça geçersiz kılınmalı ve plan, mutabık kalınan kapsamın tek kaynağı haline gelerek bunun böyle olduğu belirtilmelidir. Brief’i ikinci bir otorite olarak canlı bırakmak, kapsam anlaşmazlıklarını çözülemez hale getirir; çünkü iki taraf da bir belgeyi gösterebilir. Brief’i, hangi problemin çözüldüğünün kaydı olarak saklayın; kapanışta gerçekten faydalıdır.