用制度規範專案管理(轉)
開發一本專案管理指南來確保全公司範圍內的流程可重複性、可靠性和由此帶來的附加利益。
大多數公司都希望在不扼殺創新的前提下遵守流程。從公司自己的觀點看來,一本專案管理指南(以下簡稱指南)描述瞭如何根據業務標準和必要流程來設立、實施和控制一個專案,然後在專案不同的階段如何應用指南。設計這些方法的目的是保證最大限度的遵守流程並且不過分強調細節的規則。
2001年夏,美國佛羅里達州環境保護部(DEP)面臨了企業應用軟體的一次主要升級,此次升級設有激進的目標和固定時間的資金支援,他們決定用一種更為正式的方法來管理專案。
在顧問的幫助下,DEP開始著手於一項專案管理改進計劃以期在資訊服務局(BIS)內部建立和實施專案管理的最佳實踐。全面的計劃包括用以監控的專案管理培訓、建立專案管理辦公室和開發一本108頁的指南。透過這項計劃,BIS提高了專案交付物的符合程度,改進了與內部業務客戶的工作關係。
以下是有助於建立專案管理指南的十項建議。
1.把開發專案管理指南的工作作為一個專案來管理。
專案管理指南是一項獨特的交付物,有它自己的開發歷時和預算。這個專案要有贊助人、專案經理、已分配資源、實施計劃和變更處理流程。要開發一份工作說明書和專案計劃來定義流程以用於建立指南、交付物、交付日期和所需的角色和職責。
開發這本指南不需要一個很大的團隊。實際上,一個人可以承擔管理開發指南的職責,領導一個由相關的主題專家(SME)組成的虛擬團隊來提供輸入和評估。在DEP-BIS,一名關鍵的指南開發人員與由八九名專家組成的虛擬團隊一起工作。
2.清楚地定義這本指南的目的和範圍。
你是否需要一本指南來保持專案的符合性、共享資訊或者建立最低的行為標準?這本指南只適用於某個部門?事業部?還是整個公司?適用於軟體專案還是商業或建築專案?
對指南首輪開發的範圍應該儘可能的限制,僅覆蓋一到兩個關聯密切的部門。以後的開發應逐漸擴充套件範圍。在DEP-BIS,起初,指南的範圍關注在BIS的應用開發和地理資訊系統部門。此後,儘管還沒有將其他的DEP業務部門需求合併到指南里的近期計劃,他們也要求把指南應用於他們的專案。
3.邀請公司最優秀的人選參與開發。
你的主題專家通常是在第一線管理著專案的人。你需要他們提供資訊以使指南可用且可信。
要讓這些專家更快地接受、使用和推銷這本指南,這樣他們就會有主人翁意識。在DEP-BIS,參與了開發工作的專案主管會鼓勵別人接受指南。
4.充分利用公司的最佳實踐。
透過記錄已有的最佳實踐,你可以很容易的向其他專案經理推銷這本指南,因為你有證據證明在公司裡這些方法可行。首先要識別專案符合指南描述的類別。然後,訪問專案的成員以確定那些有效和無效的流程和技術。獲取這些專案的專案計劃以確認專案管理活動、所需資源和交付物。評估包括狀態報告和工作說明書在內的專案交付物以更好的理解產出的結構和所包含的細節層次。
DEP-BIS的一項最佳實踐是客戶提交和跟蹤系統變更請求的方法。儘管BIS內不同的部門處理變更請求的方式有所不同,但他們還是坐到一起為指南定義統一且不乏靈活的流程。
5.應用業界的最佳實踐。
商業世界總是充滿創意。在你的計劃裡融入一些新的策略,特別是那些在其他地方被驗證為有效的策略。如果不進行這種傳播,公司的那些實踐會變得陳舊、遲滯和過時。但是要認清公司的侷限。在DEP-BIS,SOW很少用於應用開發部門之外的組織,所以SOW的結構和使用規則被適當地按照指南的要求稽核和修訂。
如果你們公司沒有可觀的培訓經費並且不能容忍突變的學習曲線,那就不要使用不熟悉的方法和技術來開發指南。相比較而言,採納那些已被有效使用的方法。
6.保持最初版本簡潔明瞭。
即使指南的範圍很小,你還是很容易在最初版本里過多的拘泥於細節。集中精力做那些必須完成的活動、任務和交付物。指南應該全面地指明專案管理流程的範圍,但是詳細的“如何做”技術資訊應被指向其他參考資料、單獨開發的參考指南或併入後期版本。
使指南緊扣主題有助於儘快地釋出最初版本。專案經理可以更容易地理解本指南併為他們獨特的專案適當修訂指南。一旦公司在這方面取得更多的經驗,基於使用本指南的專案反饋就可以作為額外的細節加入到指南里。
7.按照詳細的層次開發指南。
首先識別你想要包括的過程域和資訊類別(參見附文《專案管理指南規程》)。一旦架構定義完成,就要在描述活動之前澄清流程並取得批准。
每一層次驅動下一層次並使其定型,在每一層次設立檢查點有利於專家和其他評審者為下一層次提供有價值的輸入和反饋。幾名經驗豐富的專案經理應該在他們的下一專案階段使用最初版本。這種方法提供了增量式的接受和批准,並將費時的返工減至最少。在DEP-BIS,指南的最初版本提及了專案管理檢查表和服務水平協定,然後更加詳細的檢查表和特定的標準在隨後的版本里加入。
8.迅速地部署指南。
要限定開發指南工作的時間。每輪開發工作不應占用一到兩名專職人員超過一到三個月的時間。儘管首輪開發距結束還很遠,此指南將成為實現計劃的良好開端。Standish Group在研究了諸多資訊科技專案後給出建議:每輪開發時間持續較短(三個月或更少)的專案更有可能成功。
DEP-BIS的首輪開發時限時三個月。2001年6月首次公開發布,接下來又有兩輪開發。目前,DEP-BIS正在將指南轉移到內聯網上,以減少列印版本的控制並提供實時更新和更廣泛的便利性。
9.將指南推廣到全公司。
建立了指南後,你應該向公司推銷其實用價值,指導人們使用指南會帶來價值。確認那些在公司裡有影響力的人,從他們那裡獲取接受,然後請求他們協助推廣指南。特別是當指南使用了公司不熟悉的新技術時,確認培訓的需求並提供必要的培訓。
最後,激勵人們使用指南的動機或者出臺一些使用指南的政策。在DEP-BIS,如果一名員工完成了專案管理培訓並在當前專案中成功地應用了指南的新需求,那麼在他/她的姓名牌上就會貼上一個標籤以示成就。
10.建立改進流程。
在已經使用指南的專案裡收集反饋和經驗教訓。建立一種持續改進的機制後,隨著時間推移,指南會向前發展以引入公司的最佳實踐。經過第一年的幾輪開發後,指南會逐漸穩定下來,然後每年評審指南並更新當前的新內容。
DEP-BIS目前使用一種比較非正式的流程:問題和變更請求透過電子郵件發給專案管理辦公室以收錄於一份問題清單裡。在每兩星期舉行一次的會議上,BIS管理層決定那些必要的變更。
建立一本專案管理指南會引入創新和流程之間的均衡併為如何成為一名成功的專案經理提供指導。
《專案管理指南規程》
目的說明。描述此項流程和步驟的必要性。同時還包括專案管理交付物的目標。
輸入。羅列出此項流程和步驟的所有輸入。如果不被人熟知,此項應補充簡要的解釋,包括出處及其重要性。
人員角色。指明專案管理流程應涵蓋的人員角色。不同頭銜的人可能承擔同一角色,而某個人可能扮演不同的角色。
交付物總結。羅列主要的交付物及其元件,它們會包括在活動/任務和工具章節。
活動/任務和工具。透過一兩項確定的交付物來描述標準的活動。使用清楚的質量流程工具和角色與職責定義將活動分解為特定的任務。
專案監控和報告標準。描述應用於專案中的所有標準。質量保證審計要使用檢查表來評估是否符合標準。以下文件的標準要完備:工作說明書及其定義文件、專案計劃、預審檢查表和風險評估檔案。
對普遍的問題的回答。回答那些反覆提出的問題以幫助專案克服最普遍的缺陷。
圖表。詳細的圖表有助於闡明流程。
參考文獻。羅列所有有用的書籍、網站和出版物。此項要包含全文出版參考資訊和相關標準,如ISO9000、SEI-CMM和PMBOK等。
附錄。此項包含指南里未提及但對流程比較重要的深入詳細話題。附錄可以闡述如何開發SOW、專案評估技術和專案監控工具等。
作者簡介:Neal S. Gray系美國馬薩諸塞州波士頓市的軟體開發和商業諮詢公司基恩公司的高階主任顧問。他曾主持過超過250場美國國內外的研討會,涉及領域包括專案管理、評估、風險管理和專案管理資質等。Judy N. Meadows系基恩公司的高階主任顧問。她是該公司培訓中心的成員,負責用於諮詢公司提供軟體服務的方案開發。
原文:
By The Book
By Neal S. Gray, PMP and Judy N. Meadows
Develop a project management guidebook to ensure a repeatable and reliable process – and the fringe benefits that come with it – across your organization.
Most organization want consistency without stifling creativity. Using an organization’s own terms, a project management guidebook describes how to set up, implement and control a project according to business standards, including the required processes and how they apply at different project stages. The procedures are designed to assure the highest degree of consistency – without enforcing overly detailed rules.
Faced with a major upgrade to an enterprise suite of software applications that had aggressive targets and time-boxed funding in summer 2001, the Department of Environmental Protection (DEP) for the State of Florida, USA, determined that it needed a more formal approach to managing projects.
With the assistance of a consultant, the DEP embarked on a project management improvement program for establishing and implementing best practices for project management within its Bureau of Information Service (BIS). The overall program included project management training with mentoring, the creation of a project management office and development of a 108-page guidebook. As a result, BIS has seen improved project delivery consistency and better working relationships with internal business customers.
Here are 10 tips to help you get started on creating your organization’s project management guidebook.
1.Guidebook development is a project. Manage it.
The guidebook is a unique deliverable, often with its own time frame and budget. This project must have a sponsor, project manager, assigned resources, a plan of attack and a process to deal with change. Develop a statement of work (SOW) and a project plan to define the process that will be used to create the guide, the deliverables and their due dates, and required roles and responsibilities.
Development does not require a large team. In fact, one person could take responsibility of managing and developing the guide supported by a part-time team of subject matter experts (SMEs), who provide input and review. At DEP-BIS, one person was the key developer of the guide working with a part-time group of eight to nine SMEs.
2.Clearly define the purpose and scope of the guidebook.
Do you need guidebook for consistency across projects, to educate on best practices, to share information or to create a minimum standard of action? Is it for a single department or division, or is it for the entire company? Is it for software projects or is it to be used on business and construction projects, too?
The scope of the first iteration should be fairly limited, covering no more than one or two close organizations. Future iterations – and there will be others – can expand the scope. At DEP-BIS, the guidebook scope focused on BIS’ Application Development and Geographic Information Systems groups. Since then, several DEP business areas have requested copies of the guide to use on their projects even though there is no immediate plan to incorporate their specific needs in the guide.
3.Involve your organization’s best people.
Frequently, your SMEs will be the people in the trenches managing and working on projects. You will need their information to make the guidebook useful and credible.
You will get much faster buy-in by these people to use and promote the guidebook because they will feel ownership. At DEP-BIS, the project leaders that had participated in guidebook creation encouraged buy-in.
4.Take advantage of your organization’s best practices.
By documenting existing best practices, you can easily “sell” the guide to other project managers because you already have proof that these methods work in your organization. Identify projects in your organization that are of the type being addressed in the guide. Interview team members from those projects to identify processes and techniques that were effective and those that were not. Obtain copies of the project plans to identify processes and techniques that were effective and those that were not. Obtain copies of the project plans to identify the project management activities and tasks performed, the resources required and the deliverables produced. Review project management deliverables, including status reports and SOWs, to better understand the structure of the outputs produced and the level of detail included.
At DEP-BIS, a best practice was the way customers submitted and tracked system change requests. Although multiple groups within BIS handled project requests somewhat differently, they worked together to define a consistent but flexible process for the guide.
5.Apply industry best practices.
The business world is rich with ideas. Incorporate new strategies in your plan, especially if they have proven to be useful elsewhere. Without this cross-pollination, an organization’s practices can become old, stagnant and dated. But recognize your organization’s limitations. At DEP-BIS, because there was little or no use of SOWs outside the application development group, the SOW structure and rules of use were reviewed and tailored appropriately of the guide.
Unless your organization has a large training budget and tolerance for a steep learning curve, do not develop a guide using unfamiliar techniques and approaches. Instead, base your guide on a practical approach that can be used effectively by your organization.
6.Keep initial versions simple and concise.
Even with a fairly small scope, you easily can include too much detail in the first cut. Focus on the activities and tasks that must be performed and the deliverables that must be produced. The guide should comprehensively address the full breadth of the project management process, but detailed “how-to” information on techniques, for example, can be provided via pointers to other sources, a separately developed resource guide or incorporated into later versions.
Keeping your guide to the point will allow you to release the initial version quickly. Project manager will understand the guide more easily and tailor it to meet the specific needs of their unique projects. Once your organization gains more experience, additional detail can be added using feedback from projects that have used the guide.
7.Develop the guidebook by detailing layers.
Start by identifying the process areas and categories of information that you intend to include (see sidebar “Chapter and Verse”). Once the structure is defined, define and gain approval on the processes, for instance, before describing the activities. Each layer drives and shapes the next layer – having a checkpoint for each allows your SMEs and other reviewers to provide valuable input and feedback for the next layer. Several of your more experienced project managers should use the first cut on their next project phase. This approach provides incremental buy-in and approval and minimizes time-consuming rework. At DEP-BIS, the initial cut of the guide mentioned project management checklists and service level agreements, but detailed checklists and specific metrics were added in subsequent versions.
8.Deploy it quickly.
Timebox our development initiative. An iteration of the guide should take no more than one to three months with one to two dedicated resources. Although far from complete after the first iteration, the guide will be a good start toward consistency. In its studies of information technology projects, The Standish Group suggests that iterative projects with short duration (three months or less) are more likely to be successful.
The timeline for DEP-BIS’s first iteration was three months. Since the initial July 2001 rollout, two iterations have followed. DEP-BIS now is moving the guidebook to an intranet site to eliminate the need for printed version control and to provide more timely updates and wider availability.
9.Market the guidebook to your organization.
As you create the guide, you must sell its usefulness to the organization. Educate people on the benefits of using the guide. Identify and get buy-in from those in your organization that are influential. Solicit their help in promoting the guide. Identify training requirements and provide for needed training, especially if the guide introduces new techniques that are not well understood by your organization.
Last, implement incentives for using the guide or form policies requiring its use. At DEP-BIS, a sticker placed on a name badge signaled that an employee completed project management training and was a successful user of the new guide’s requirement in a current project.
10.Establish a process for improvement.
Start collecting feedback and lessons learned from the projects that use the guide. By establishing a mechanism for continuous improvement, the guide will evolve to incorporate your organization’s best practices over time. After the first year and several iterations, the guide will stabilize. Perhaps yearly, review and update the guide for current relevance.
DEP-BIS is using a fairly informal process where by issues and requests for changes are sent to the project office via e-mail to be included on an issues list. At a biweekly meeting, BIS management decides if a change is necessary.
Creating a project management guidebook will help bring balance and provide insight into the “how-to” of being a successful project manager within the bounds of your organization.
Neal S. Gray, PMP, is a senior principal consultant with Keane Inc., a Boston, Mass., USA-based software development and business consulting firm. He has conducted more than 250 U.S. and international seminars in the areas of project management, estimation, risk management and project management competencies.
Judy N. Meadows is a senior principal consultant with Keane Inc. She is a member of Keane’s Center for Excellence with responsibility for developing methodologies used by the consulting firm to deliver software services to its clients.
Chapter and Verse
Each project process should have several common sections.
Purpose Statement. Describes why the process or phase is necessary. It includes the purpose of the intended project management deliverables.
Inputs. Lists all inputs to this process or phase. If not commonly known, the item can be supplemented with a brief explanation, including where it comes from and why it is important.
Personnel Roles Required. Indicates which roles should be involved in the project management process. Many people with different titles may play the same role or a single person may play more than one role.
Deliverables Summary. Lists the major deliverables and their components, which are listed in the activities/tasks and techniques section.
Activities/Tasks and Techniques. Describes the standard activities with one or more tangible deliverables identified. Activities are broken down into specific tasks with clearly identified quality process and tools and roles and responsibilities.
Project Control and Reporting Standards. Describes the standards applied to all projects. Quality assurance audits use checklists to evaluate compliance. Standards for statement of work and defining documents, the project plan, pre-audit checklists and risk assessments are included.
Answers to Common Questions. Includes the many reoccurring questions and associated responses for this part of the project to help overcome the most common pitfalls.
Figures. Detail drawings or charts that help illuminate the process flow for this area of the project management process.
References. Lists all books, Web sites and publications that the project organization found useful. This may include full publication reference information to relevant standards such as ISO 9000, SEI-CMM and A Guide to the Project Management Body of Knowledge (PMBOK Guide).
Appendices. Further details specific topic areas that are important to the process but are not placed elsewhere in the guidebook. Appendices can illustrate topics such as how to develop a SOW, project estimating tips and techniques, project control and monitoring tools.
[@more@]
大多數公司都希望在不扼殺創新的前提下遵守流程。從公司自己的觀點看來,一本專案管理指南(以下簡稱指南)描述瞭如何根據業務標準和必要流程來設立、實施和控制一個專案,然後在專案不同的階段如何應用指南。設計這些方法的目的是保證最大限度的遵守流程並且不過分強調細節的規則。
2001年夏,美國佛羅里達州環境保護部(DEP)面臨了企業應用軟體的一次主要升級,此次升級設有激進的目標和固定時間的資金支援,他們決定用一種更為正式的方法來管理專案。
在顧問的幫助下,DEP開始著手於一項專案管理改進計劃以期在資訊服務局(BIS)內部建立和實施專案管理的最佳實踐。全面的計劃包括用以監控的專案管理培訓、建立專案管理辦公室和開發一本108頁的指南。透過這項計劃,BIS提高了專案交付物的符合程度,改進了與內部業務客戶的工作關係。
以下是有助於建立專案管理指南的十項建議。
1.把開發專案管理指南的工作作為一個專案來管理。
專案管理指南是一項獨特的交付物,有它自己的開發歷時和預算。這個專案要有贊助人、專案經理、已分配資源、實施計劃和變更處理流程。要開發一份工作說明書和專案計劃來定義流程以用於建立指南、交付物、交付日期和所需的角色和職責。
開發這本指南不需要一個很大的團隊。實際上,一個人可以承擔管理開發指南的職責,領導一個由相關的主題專家(SME)組成的虛擬團隊來提供輸入和評估。在DEP-BIS,一名關鍵的指南開發人員與由八九名專家組成的虛擬團隊一起工作。
2.清楚地定義這本指南的目的和範圍。
你是否需要一本指南來保持專案的符合性、共享資訊或者建立最低的行為標準?這本指南只適用於某個部門?事業部?還是整個公司?適用於軟體專案還是商業或建築專案?
對指南首輪開發的範圍應該儘可能的限制,僅覆蓋一到兩個關聯密切的部門。以後的開發應逐漸擴充套件範圍。在DEP-BIS,起初,指南的範圍關注在BIS的應用開發和地理資訊系統部門。此後,儘管還沒有將其他的DEP業務部門需求合併到指南里的近期計劃,他們也要求把指南應用於他們的專案。
3.邀請公司最優秀的人選參與開發。
你的主題專家通常是在第一線管理著專案的人。你需要他們提供資訊以使指南可用且可信。
要讓這些專家更快地接受、使用和推銷這本指南,這樣他們就會有主人翁意識。在DEP-BIS,參與了開發工作的專案主管會鼓勵別人接受指南。
4.充分利用公司的最佳實踐。
透過記錄已有的最佳實踐,你可以很容易的向其他專案經理推銷這本指南,因為你有證據證明在公司裡這些方法可行。首先要識別專案符合指南描述的類別。然後,訪問專案的成員以確定那些有效和無效的流程和技術。獲取這些專案的專案計劃以確認專案管理活動、所需資源和交付物。評估包括狀態報告和工作說明書在內的專案交付物以更好的理解產出的結構和所包含的細節層次。
DEP-BIS的一項最佳實踐是客戶提交和跟蹤系統變更請求的方法。儘管BIS內不同的部門處理變更請求的方式有所不同,但他們還是坐到一起為指南定義統一且不乏靈活的流程。
5.應用業界的最佳實踐。
商業世界總是充滿創意。在你的計劃裡融入一些新的策略,特別是那些在其他地方被驗證為有效的策略。如果不進行這種傳播,公司的那些實踐會變得陳舊、遲滯和過時。但是要認清公司的侷限。在DEP-BIS,SOW很少用於應用開發部門之外的組織,所以SOW的結構和使用規則被適當地按照指南的要求稽核和修訂。
如果你們公司沒有可觀的培訓經費並且不能容忍突變的學習曲線,那就不要使用不熟悉的方法和技術來開發指南。相比較而言,採納那些已被有效使用的方法。
6.保持最初版本簡潔明瞭。
即使指南的範圍很小,你還是很容易在最初版本里過多的拘泥於細節。集中精力做那些必須完成的活動、任務和交付物。指南應該全面地指明專案管理流程的範圍,但是詳細的“如何做”技術資訊應被指向其他參考資料、單獨開發的參考指南或併入後期版本。
使指南緊扣主題有助於儘快地釋出最初版本。專案經理可以更容易地理解本指南併為他們獨特的專案適當修訂指南。一旦公司在這方面取得更多的經驗,基於使用本指南的專案反饋就可以作為額外的細節加入到指南里。
7.按照詳細的層次開發指南。
首先識別你想要包括的過程域和資訊類別(參見附文《專案管理指南規程》)。一旦架構定義完成,就要在描述活動之前澄清流程並取得批准。
每一層次驅動下一層次並使其定型,在每一層次設立檢查點有利於專家和其他評審者為下一層次提供有價值的輸入和反饋。幾名經驗豐富的專案經理應該在他們的下一專案階段使用最初版本。這種方法提供了增量式的接受和批准,並將費時的返工減至最少。在DEP-BIS,指南的最初版本提及了專案管理檢查表和服務水平協定,然後更加詳細的檢查表和特定的標準在隨後的版本里加入。
8.迅速地部署指南。
要限定開發指南工作的時間。每輪開發工作不應占用一到兩名專職人員超過一到三個月的時間。儘管首輪開發距結束還很遠,此指南將成為實現計劃的良好開端。Standish Group在研究了諸多資訊科技專案後給出建議:每輪開發時間持續較短(三個月或更少)的專案更有可能成功。
DEP-BIS的首輪開發時限時三個月。2001年6月首次公開發布,接下來又有兩輪開發。目前,DEP-BIS正在將指南轉移到內聯網上,以減少列印版本的控制並提供實時更新和更廣泛的便利性。
9.將指南推廣到全公司。
建立了指南後,你應該向公司推銷其實用價值,指導人們使用指南會帶來價值。確認那些在公司裡有影響力的人,從他們那裡獲取接受,然後請求他們協助推廣指南。特別是當指南使用了公司不熟悉的新技術時,確認培訓的需求並提供必要的培訓。
最後,激勵人們使用指南的動機或者出臺一些使用指南的政策。在DEP-BIS,如果一名員工完成了專案管理培訓並在當前專案中成功地應用了指南的新需求,那麼在他/她的姓名牌上就會貼上一個標籤以示成就。
10.建立改進流程。
在已經使用指南的專案裡收集反饋和經驗教訓。建立一種持續改進的機制後,隨著時間推移,指南會向前發展以引入公司的最佳實踐。經過第一年的幾輪開發後,指南會逐漸穩定下來,然後每年評審指南並更新當前的新內容。
DEP-BIS目前使用一種比較非正式的流程:問題和變更請求透過電子郵件發給專案管理辦公室以收錄於一份問題清單裡。在每兩星期舉行一次的會議上,BIS管理層決定那些必要的變更。
建立一本專案管理指南會引入創新和流程之間的均衡併為如何成為一名成功的專案經理提供指導。
《專案管理指南規程》
目的說明。描述此項流程和步驟的必要性。同時還包括專案管理交付物的目標。
輸入。羅列出此項流程和步驟的所有輸入。如果不被人熟知,此項應補充簡要的解釋,包括出處及其重要性。
人員角色。指明專案管理流程應涵蓋的人員角色。不同頭銜的人可能承擔同一角色,而某個人可能扮演不同的角色。
交付物總結。羅列主要的交付物及其元件,它們會包括在活動/任務和工具章節。
活動/任務和工具。透過一兩項確定的交付物來描述標準的活動。使用清楚的質量流程工具和角色與職責定義將活動分解為特定的任務。
專案監控和報告標準。描述應用於專案中的所有標準。質量保證審計要使用檢查表來評估是否符合標準。以下文件的標準要完備:工作說明書及其定義文件、專案計劃、預審檢查表和風險評估檔案。
對普遍的問題的回答。回答那些反覆提出的問題以幫助專案克服最普遍的缺陷。
圖表。詳細的圖表有助於闡明流程。
參考文獻。羅列所有有用的書籍、網站和出版物。此項要包含全文出版參考資訊和相關標準,如ISO9000、SEI-CMM和PMBOK等。
附錄。此項包含指南里未提及但對流程比較重要的深入詳細話題。附錄可以闡述如何開發SOW、專案評估技術和專案監控工具等。
作者簡介:Neal S. Gray系美國馬薩諸塞州波士頓市的軟體開發和商業諮詢公司基恩公司的高階主任顧問。他曾主持過超過250場美國國內外的研討會,涉及領域包括專案管理、評估、風險管理和專案管理資質等。Judy N. Meadows系基恩公司的高階主任顧問。她是該公司培訓中心的成員,負責用於諮詢公司提供軟體服務的方案開發。
原文:
By The Book
By Neal S. Gray, PMP and Judy N. Meadows
Develop a project management guidebook to ensure a repeatable and reliable process – and the fringe benefits that come with it – across your organization.
Most organization want consistency without stifling creativity. Using an organization’s own terms, a project management guidebook describes how to set up, implement and control a project according to business standards, including the required processes and how they apply at different project stages. The procedures are designed to assure the highest degree of consistency – without enforcing overly detailed rules.
Faced with a major upgrade to an enterprise suite of software applications that had aggressive targets and time-boxed funding in summer 2001, the Department of Environmental Protection (DEP) for the State of Florida, USA, determined that it needed a more formal approach to managing projects.
With the assistance of a consultant, the DEP embarked on a project management improvement program for establishing and implementing best practices for project management within its Bureau of Information Service (BIS). The overall program included project management training with mentoring, the creation of a project management office and development of a 108-page guidebook. As a result, BIS has seen improved project delivery consistency and better working relationships with internal business customers.
Here are 10 tips to help you get started on creating your organization’s project management guidebook.
1.Guidebook development is a project. Manage it.
The guidebook is a unique deliverable, often with its own time frame and budget. This project must have a sponsor, project manager, assigned resources, a plan of attack and a process to deal with change. Develop a statement of work (SOW) and a project plan to define the process that will be used to create the guide, the deliverables and their due dates, and required roles and responsibilities.
Development does not require a large team. In fact, one person could take responsibility of managing and developing the guide supported by a part-time team of subject matter experts (SMEs), who provide input and review. At DEP-BIS, one person was the key developer of the guide working with a part-time group of eight to nine SMEs.
2.Clearly define the purpose and scope of the guidebook.
Do you need guidebook for consistency across projects, to educate on best practices, to share information or to create a minimum standard of action? Is it for a single department or division, or is it for the entire company? Is it for software projects or is it to be used on business and construction projects, too?
The scope of the first iteration should be fairly limited, covering no more than one or two close organizations. Future iterations – and there will be others – can expand the scope. At DEP-BIS, the guidebook scope focused on BIS’ Application Development and Geographic Information Systems groups. Since then, several DEP business areas have requested copies of the guide to use on their projects even though there is no immediate plan to incorporate their specific needs in the guide.
3.Involve your organization’s best people.
Frequently, your SMEs will be the people in the trenches managing and working on projects. You will need their information to make the guidebook useful and credible.
You will get much faster buy-in by these people to use and promote the guidebook because they will feel ownership. At DEP-BIS, the project leaders that had participated in guidebook creation encouraged buy-in.
4.Take advantage of your organization’s best practices.
By documenting existing best practices, you can easily “sell” the guide to other project managers because you already have proof that these methods work in your organization. Identify projects in your organization that are of the type being addressed in the guide. Interview team members from those projects to identify processes and techniques that were effective and those that were not. Obtain copies of the project plans to identify processes and techniques that were effective and those that were not. Obtain copies of the project plans to identify the project management activities and tasks performed, the resources required and the deliverables produced. Review project management deliverables, including status reports and SOWs, to better understand the structure of the outputs produced and the level of detail included.
At DEP-BIS, a best practice was the way customers submitted and tracked system change requests. Although multiple groups within BIS handled project requests somewhat differently, they worked together to define a consistent but flexible process for the guide.
5.Apply industry best practices.
The business world is rich with ideas. Incorporate new strategies in your plan, especially if they have proven to be useful elsewhere. Without this cross-pollination, an organization’s practices can become old, stagnant and dated. But recognize your organization’s limitations. At DEP-BIS, because there was little or no use of SOWs outside the application development group, the SOW structure and rules of use were reviewed and tailored appropriately of the guide.
Unless your organization has a large training budget and tolerance for a steep learning curve, do not develop a guide using unfamiliar techniques and approaches. Instead, base your guide on a practical approach that can be used effectively by your organization.
6.Keep initial versions simple and concise.
Even with a fairly small scope, you easily can include too much detail in the first cut. Focus on the activities and tasks that must be performed and the deliverables that must be produced. The guide should comprehensively address the full breadth of the project management process, but detailed “how-to” information on techniques, for example, can be provided via pointers to other sources, a separately developed resource guide or incorporated into later versions.
Keeping your guide to the point will allow you to release the initial version quickly. Project manager will understand the guide more easily and tailor it to meet the specific needs of their unique projects. Once your organization gains more experience, additional detail can be added using feedback from projects that have used the guide.
7.Develop the guidebook by detailing layers.
Start by identifying the process areas and categories of information that you intend to include (see sidebar “Chapter and Verse”). Once the structure is defined, define and gain approval on the processes, for instance, before describing the activities. Each layer drives and shapes the next layer – having a checkpoint for each allows your SMEs and other reviewers to provide valuable input and feedback for the next layer. Several of your more experienced project managers should use the first cut on their next project phase. This approach provides incremental buy-in and approval and minimizes time-consuming rework. At DEP-BIS, the initial cut of the guide mentioned project management checklists and service level agreements, but detailed checklists and specific metrics were added in subsequent versions.
8.Deploy it quickly.
Timebox our development initiative. An iteration of the guide should take no more than one to three months with one to two dedicated resources. Although far from complete after the first iteration, the guide will be a good start toward consistency. In its studies of information technology projects, The Standish Group suggests that iterative projects with short duration (three months or less) are more likely to be successful.
The timeline for DEP-BIS’s first iteration was three months. Since the initial July 2001 rollout, two iterations have followed. DEP-BIS now is moving the guidebook to an intranet site to eliminate the need for printed version control and to provide more timely updates and wider availability.
9.Market the guidebook to your organization.
As you create the guide, you must sell its usefulness to the organization. Educate people on the benefits of using the guide. Identify and get buy-in from those in your organization that are influential. Solicit their help in promoting the guide. Identify training requirements and provide for needed training, especially if the guide introduces new techniques that are not well understood by your organization.
Last, implement incentives for using the guide or form policies requiring its use. At DEP-BIS, a sticker placed on a name badge signaled that an employee completed project management training and was a successful user of the new guide’s requirement in a current project.
10.Establish a process for improvement.
Start collecting feedback and lessons learned from the projects that use the guide. By establishing a mechanism for continuous improvement, the guide will evolve to incorporate your organization’s best practices over time. After the first year and several iterations, the guide will stabilize. Perhaps yearly, review and update the guide for current relevance.
DEP-BIS is using a fairly informal process where by issues and requests for changes are sent to the project office via e-mail to be included on an issues list. At a biweekly meeting, BIS management decides if a change is necessary.
Creating a project management guidebook will help bring balance and provide insight into the “how-to” of being a successful project manager within the bounds of your organization.
Neal S. Gray, PMP, is a senior principal consultant with Keane Inc., a Boston, Mass., USA-based software development and business consulting firm. He has conducted more than 250 U.S. and international seminars in the areas of project management, estimation, risk management and project management competencies.
Judy N. Meadows is a senior principal consultant with Keane Inc. She is a member of Keane’s Center for Excellence with responsibility for developing methodologies used by the consulting firm to deliver software services to its clients.
Chapter and Verse
Each project process should have several common sections.
Purpose Statement. Describes why the process or phase is necessary. It includes the purpose of the intended project management deliverables.
Inputs. Lists all inputs to this process or phase. If not commonly known, the item can be supplemented with a brief explanation, including where it comes from and why it is important.
Personnel Roles Required. Indicates which roles should be involved in the project management process. Many people with different titles may play the same role or a single person may play more than one role.
Deliverables Summary. Lists the major deliverables and their components, which are listed in the activities/tasks and techniques section.
Activities/Tasks and Techniques. Describes the standard activities with one or more tangible deliverables identified. Activities are broken down into specific tasks with clearly identified quality process and tools and roles and responsibilities.
Project Control and Reporting Standards. Describes the standards applied to all projects. Quality assurance audits use checklists to evaluate compliance. Standards for statement of work and defining documents, the project plan, pre-audit checklists and risk assessments are included.
Answers to Common Questions. Includes the many reoccurring questions and associated responses for this part of the project to help overcome the most common pitfalls.
Figures. Detail drawings or charts that help illuminate the process flow for this area of the project management process.
References. Lists all books, Web sites and publications that the project organization found useful. This may include full publication reference information to relevant standards such as ISO 9000, SEI-CMM and A Guide to the Project Management Body of Knowledge (PMBOK Guide).
Appendices. Further details specific topic areas that are important to the process but are not placed elsewhere in the guidebook. Appendices can illustrate topics such as how to develop a SOW, project estimating tips and techniques, project control and monitoring tools.
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-955705/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 淺談專案的規範管理(轉)
- 專案管理規範-RUP管理實施(三)(轉)專案管理
- 設工程專案管理規範問答(轉)專案管理
- 建設工程專案管理規範問答(轉)專案管理
- 對規範施工企業專案管理的思考(轉)專案管理
- 如何規範化專案管理,提升效率?專案管理
- 網站專案管理規範手冊網站專案管理
- 專案規劃管理(轉)
- 淳安縣移民工程專案實現規範化管理(轉)
- 專案管理:規範化的過程及關鍵概念(轉)專案管理
- 專案範圍變更管理(轉)
- 專案中的 Git 使用規範 [轉]Git
- 前端規範之vue 專案規範前端Vue
- 團隊專案的Git分支管理規範Git
- ERP專案管理制度要適時更新(轉)專案管理
- 規範BOT專案的法律對策(轉)
- 專案開發過程中的管理規範
- 專案規範筆記筆記
- Android 專案規範Android
- 建築專案合同管理風險防範(轉)
- 專案範圍管理是專案成敗的關鍵 (轉)
- 個人專案開發規範
- 我的專案命名規範
- 網站專案實施業務流程及規範(轉)網站
- 對安全專案的規劃與管理(轉)
- 糟糕的範圍管理導致專案失敗(轉)
- 工程專案管理中的風險分析與防範(轉)專案管理
- 專案中的 Git 使用規範Git
- 專案規範-git commit 配置GitMIT
- 淺談專案程式碼規範
- 專案開發流程規範文件
- 軟體專案範圍管理
- 專案管理軟體之範圍管理專案管理
- 第一次制定<專案管理制度試執行條例> (轉)專案管理
- Web應用介面設計規範—給專案組培訓 .Web
- javascript專案開發規範例項JavaScript
- 《專案經理指導手冊》規範篇5,任務規範
- 軟體專案管理FollowMe_範圍管理專案管理