專案組準則——從我”到“我們”(轉)
開始專案
任何新專案小組的最重要的任務是建立自已的行動目的、工作過程、以及工作進展的標準。一旦根據目的產生出下述準則和憲章,就應該將它們記在活動掛圖上,每次開會掛出來作參考。
擬定出專案組行為憲章
- 基本規則。針對是否可接受的個人和集體的行為制定出意見一致的基本規則。
- 作決定。確定如何作決定,是透過取得一致意見,還是以大多數人同意為準,或乾脆沒有規定!討論是否可以有或應該有小組不按慣例過程行事的例外。
- 交流。要認識傾聽別人說話和建設性意見的價值,每天努力進行建設性的交流!
- 作用和參與。討論如何選擇領導,其實就是如何領導專案組的工作過程。每個人和整個組都有責任提倡平等參與。- 價值。承認並接愛每個組員的獨見。
擬定出工作目標憲章
- 建立起專案組之所以有必要存在的原因
- 將能在專案組與他人合作的人召集起來,確定是否每個人都具備有效地參與專案組工作的知識、技術和影響
- 專案組應該討論誰是顧客。如果有許多顧客,作出哪些顧客有最大的優先權的決定,或者至少決定如何平衡他們的需求。
擬定出工作進展的標準
討論商定表明專案組工作進展的滿意的訊號(確定訊號即可以是客觀的也可以是主觀的)
- 討論商定表明專案組成功或失敗的標準和結果的型別。
- 估計完成專案的日期
保持動量
許多專案組開端良好,可是以失敗告終。真正的挑戰是使專案組一直集中於專案的目標,而不是組員的歷史和他們相互間的關係。
商定要使用的改進模型標準的步驟。使用自已團體的改進過程的標準步驟或從很多已發表的選擇中挑選。- 資料。收集有關的資料來分析現時的情況。確定已知什麼,需要了解什麼,但知道什麼時候應該停止。作為一個組,要會說在某個時候自已的工作已做得很好,完全可以進入下一步- 制定計劃。使用團體的標準改進模型來規定計劃的總結構。估計每個步驟和整個專案的時間。有必要時檢查和修改計劃。
使用以資料和知識證實了的方法
- 以資料為基礎的方法使用如行執行圖、帕雷多圖之類的工具,它們都反映出數所歷史上的模式。這些工具避免討論中感情用事,使府論過程不斷推進。
- 以知識為基礎的方法這。如親合圖、相互關係有向圖、都有助於產生和分析意見,以致於反映出其中重要的資訊。它們也有助於使意見得到統一,這對於專案組來說是理想的能源掌握專案組的功力- 利用促進者。促進者的作用是檢查和幫助組員,使他們的相互關係保持積極活躍。在張望進工作關係不的同進,促進者也可以幫助專案組將注意國始終集中在工作的目標上的- 處理衝實。衝突隨專案組的發展而產生,是交流更為敞開時的自然過程。整個組可以學習解決衝突的方法,利用促進者幫助改進工作關係。- 認定一致意見。處理相同意見往往也就是處理不同意見。經常檢驗意見是否一致,當一致意見的要點出現時,將它們記下。- 鼓勵平等參與。每個組必須有責任始終如一地參與所有的討論。同樣,整個組應該不停地努力“撤回”佔優勢的組員,引發文靜的組員說話。
結束專案
大多數的專案小組和所有的專案最終總是要結束。他們往往不是以不滿意而千終就是根本沒有“正式”結束。結束前,專案組應該複審以下清單:
我們對昭原來的目標和顧客的要求檢查了工作的結果。
我們找出了還要做的工作
我們規定了對隨時間流逝而出現的變化進行檢查的任務
我們作了檔案記錄以及根據需要培養了有關人員學習新工作過程
我們將變化通知了所有受影響的人
我們複審了專案小組的成時,以便找出需要改進的地方
我們以共進午餐、在業務通訊上發表文章、向公司作專門報告等形式慶祝了專案小組的共同努力的成果。我們為自已的貢獻和成果,為自已的新能力,以及為與同事確定的新關係感到自豪
召開有效的會議
籌備:
決定會議的目的
制定會議計劃(參加者、什麼內容、地點、時間、人數)
認定會議主持人
準備並分發議事日程
佈置會議場地
開始
準時開始
介紹會議主持人
讓組員互相介紹自已
找個自願計時員
找個自願記錄員
複審、更改、排列議事日程
制定時間限度
複審前次會議產生出的活動專案
會議規矩
先舉手,得到認可後才發言
發言應簡要對題
鎮靜地證明自己的論點
保持思路開闊
不帶偏見地傾聽別人的發言
要理解別人的發言內容
有人發言時避免私下同別人說話
尊重他人的觀點
避免做個人的事
帶著做對公司有益有事的準備來參加會議
高高興興地參加會議
結束
制定活動專案(參加者什麼內容、時間、方法)
同小組一起總結會議
約定下個會議的日期和時間
評論會議
準時結束
打掃會議場地[@more@]
任何新專案小組的最重要的任務是建立自已的行動目的、工作過程、以及工作進展的標準。一旦根據目的產生出下述準則和憲章,就應該將它們記在活動掛圖上,每次開會掛出來作參考。
擬定出專案組行為憲章
- 基本規則。針對是否可接受的個人和集體的行為制定出意見一致的基本規則。
- 作決定。確定如何作決定,是透過取得一致意見,還是以大多數人同意為準,或乾脆沒有規定!討論是否可以有或應該有小組不按慣例過程行事的例外。
- 交流。要認識傾聽別人說話和建設性意見的價值,每天努力進行建設性的交流!
- 作用和參與。討論如何選擇領導,其實就是如何領導專案組的工作過程。每個人和整個組都有責任提倡平等參與。- 價值。承認並接愛每個組員的獨見。
擬定出工作目標憲章
- 建立起專案組之所以有必要存在的原因
- 將能在專案組與他人合作的人召集起來,確定是否每個人都具備有效地參與專案組工作的知識、技術和影響
- 專案組應該討論誰是顧客。如果有許多顧客,作出哪些顧客有最大的優先權的決定,或者至少決定如何平衡他們的需求。
擬定出工作進展的標準
討論商定表明專案組工作進展的滿意的訊號(確定訊號即可以是客觀的也可以是主觀的)
- 討論商定表明專案組成功或失敗的標準和結果的型別。
- 估計完成專案的日期
保持動量
許多專案組開端良好,可是以失敗告終。真正的挑戰是使專案組一直集中於專案的目標,而不是組員的歷史和他們相互間的關係。
商定要使用的改進模型標準的步驟。使用自已團體的改進過程的標準步驟或從很多已發表的選擇中挑選。- 資料。收集有關的資料來分析現時的情況。確定已知什麼,需要了解什麼,但知道什麼時候應該停止。作為一個組,要會說在某個時候自已的工作已做得很好,完全可以進入下一步- 制定計劃。使用團體的標準改進模型來規定計劃的總結構。估計每個步驟和整個專案的時間。有必要時檢查和修改計劃。
使用以資料和知識證實了的方法
- 以資料為基礎的方法使用如行執行圖、帕雷多圖之類的工具,它們都反映出數所歷史上的模式。這些工具避免討論中感情用事,使府論過程不斷推進。
- 以知識為基礎的方法這。如親合圖、相互關係有向圖、都有助於產生和分析意見,以致於反映出其中重要的資訊。它們也有助於使意見得到統一,這對於專案組來說是理想的能源掌握專案組的功力- 利用促進者。促進者的作用是檢查和幫助組員,使他們的相互關係保持積極活躍。在張望進工作關係不的同進,促進者也可以幫助專案組將注意國始終集中在工作的目標上的- 處理衝實。衝突隨專案組的發展而產生,是交流更為敞開時的自然過程。整個組可以學習解決衝突的方法,利用促進者幫助改進工作關係。- 認定一致意見。處理相同意見往往也就是處理不同意見。經常檢驗意見是否一致,當一致意見的要點出現時,將它們記下。- 鼓勵平等參與。每個組必須有責任始終如一地參與所有的討論。同樣,整個組應該不停地努力“撤回”佔優勢的組員,引發文靜的組員說話。
結束專案
大多數的專案小組和所有的專案最終總是要結束。他們往往不是以不滿意而千終就是根本沒有“正式”結束。結束前,專案組應該複審以下清單:
我們對昭原來的目標和顧客的要求檢查了工作的結果。
我們找出了還要做的工作
我們規定了對隨時間流逝而出現的變化進行檢查的任務
我們作了檔案記錄以及根據需要培養了有關人員學習新工作過程
我們將變化通知了所有受影響的人
我們複審了專案小組的成時,以便找出需要改進的地方
我們以共進午餐、在業務通訊上發表文章、向公司作專門報告等形式慶祝了專案小組的共同努力的成果。我們為自已的貢獻和成果,為自已的新能力,以及為與同事確定的新關係感到自豪
召開有效的會議
籌備:
決定會議的目的
制定會議計劃(參加者、什麼內容、地點、時間、人數)
認定會議主持人
準備並分發議事日程
佈置會議場地
開始
準時開始
介紹會議主持人
讓組員互相介紹自已
找個自願計時員
找個自願記錄員
複審、更改、排列議事日程
制定時間限度
複審前次會議產生出的活動專案
會議規矩
先舉手,得到認可後才發言
發言應簡要對題
鎮靜地證明自己的論點
保持思路開闊
不帶偏見地傾聽別人的發言
要理解別人的發言內容
有人發言時避免私下同別人說話
尊重他人的觀點
避免做個人的事
帶著做對公司有益有事的準備來參加會議
高高興興地參加會議
結束
制定活動專案(參加者什麼內容、時間、方法)
同小組一起總結會議
約定下個會議的日期和時間
評論會議
準時結束
打掃會議場地[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-959116/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案管理為我們贏得什麼(轉)專案管理
- 從28萬個開源專案中,我們能夠學到一些什麼?
- Unity V3 初步使用 —— 為我的.NET專案從簡單三層架構轉到IOC做準備Unity架構
- 從react轉職到vue開發的專案準備ReactVue
- 從入門到放棄,我們為何從 Blazor 回到 VueBlazorVue
- 專案管理之我見 (轉)專案管理
- 為什麼我們從Webpack切換到Vite - ReplitWebVite
- 為什麼我們從RabbitMQ切換到apache kafka?MQApacheKafka
- 我們能從Pokémon GO中學到什麼Go
- 面試官!讓我們聊聊正則面試
- 我們為什麼要從 HTTPRunner 轉向 MeterSphereHTTP
- [譯] 我們能從 Redux 原始碼中學到什麼?Redux原始碼
- 我們從雲端計算中領悟到的10件事
- 如何優化我們的程式碼(vue專案)優化Vue
- 我們的創業專案是如何夭折的創業
- 專案團隊組建的原則(轉)
- 專案組織規劃的原則(轉)
- 為什麼我們從來不去感謝開源專案維護者?
- 🎉我是如何從零到成為 Apache 頂級專案的 CommitterApacheMIT
- 搞笑圖組:我是我們村唯一一個搞IT的
- 從 PHP 到 Go:我們是如何將 API 速度提升 8 倍PHPGoAPI
- 【肥朝】從JDK中,我們能學到哪些設計模式?JDK設計模式
- 從資料收集到資訊挖掘,我們該看重什麼?
- 我們能從庫克身上學到的幾條領導理念
- [譯] 為什麼我們從來不去感謝開源專案維護者
- 我們一起學PMP—專案管理的要素專案管理
- 我們是如何將一個專案做爛的
- “銀色情人節”——我們的開源專案
- 關於我們的思考——“專案開發”及讀《人月神話》有感 (轉)
- 面試大廠,我是這樣準備專案的面試
- 我做IT專案的專案經理的經歷(轉)
- [譯] 從 Cron 到 Airflow 的遷移中我們學到了什麼AI
- 從 ABAP Netweaver 到 ABAP Platform,我們一直在努力Platform
- 應用實戰:從Redis到Aerospike,我們踩了這些坑RedisROS
- 我們正在錯誤的組織程式碼!
- 專案外包軟體專案管理之我見(轉)專案管理
- 專案管理辦公室職能之我見(轉)專案管理
- 同學們,我轉前端了,我有點捨不得Laravel前端Laravel