| Content Levels | |
| Register for free access to papers, case studies, and over 50 templates. | |
| Subscribe for complete access: $14.95 monthly or $149/year | |
| Risk-free 15-day trial!
Compare levels View sample templates Corporate subscriptions | |
Project Management Templates > Project Management SkillsProject Management Skills
|
|||||
|
Appointment letter |
Letter template announcing the appointment of a project manager to a newly-approved project and expressing sponsor support for it. |
||||
|
|
|||||
|
Department and Project Level WBS Example |
Work Breakdown Structures examples, created for a multi-project IEEE 802.11 department project portfolio. This portfolio was composed of projects to create or enhance networking systems that include hardware and firmware components as well as cross-functional manufacturing and support activities. Used by the Director of the technical development department responsible for these products, to provide a portfolio-level Work Breakdown view of all the projects in his department and a starting point for defining the WBS for each project in his department in a consistent way. |
||||
|
|
|||||
|
Development Project Plan |
An outline for a Development Plan document that summarizes the project goals and the major activities across the different functional groups necessary to achieve those goals. Includes sections for describing major activities of the project, including activities that are sometimes neglected during planning, such as prototype builds, compliance testing, technical publications, service strategy, etc. |
||||
|
|
|||||
|
Discontinuance End-of-Life Planning |
Provides approaches and document outlines for planning ahead for the time when you will discontinue offering a product or service. Includes impacts internal to the company (e.g. impact on support functions) and external impacts on your customers/users (e.g. decisions on supporting old products and services, migrating customers to a replacement product or service. release, etc.) |
||||
|
|
|||||
|
Guidelines - Completion Criteria |
Completion criteria are explicit goals that must be attained to call an element of a project, or the entire project, "complete." Completion criteria are really a communication tool and an important aspect of "quality management" on your project. They ensure the team agrees on when a particular activity or phase will be "done" and plans work, testing, and reviews accordingly. |
||||
|
|
|||||
|
Integration plan |
An outline for documenting how the hardware and/or software in a system will be integrated before system test. Great for making sure the integration steps have been thought through (rather than defining an amorphous block of time for integration then hoping everything comes out at the end!) |
||||
|
|
|||||
|
Leadership and Product Lifecycle |
A table showing the evolution of leadership responsibilities during the different phases of a project. This table can be used as a guide for selecting people with the right leadership attributes. |
||||
|
|
|||||
|
Microsoft Office 2000 Deployment Template |
A template for use in Microsoft Project 98 that facilitates planning the deployment of Microsoft Office 2000 in an organization by generating a representative schedule with sample task durations and dependencies. When you open this template in Project 98, the sample schedule is automatically created. This schedule can then be modified to fit your own organization's planning. Provided by Microsoft Corporation. |
Download template |
|||
|
|
|||||
|
Microsoft Windows NT to Microsoft Windows 2000 Deployment Template |
A template for use in Microsoft Project 98 that facilitates planning the deployment of Microsoft Windows 2000 in an organization by generating a representative schedule with sample task durations and dependencies. When you open this template in Project 98, the sample schedule is automatically created. This schedule can then be modified to fit your own organization's planning. Provided by Microsoft Corporation. |
Download template |
|||
|
|
|||||
| MS Project Template for IT Software Development Project | This MS Project file was created by the PMO for the IT organization of a large company, as a guideline for consistent planning of their software development projects. It provides a full cross-functional work breakdown for such a project, from business process requirements definition all the way through acceptance testing and deployment, with related work such as training and documentation as well. All WBS elements are linked to show typical dependency relationships and have generic departmental resoruces assigned. In addition, every task is annotated with notes on the purpose of that task and guidelines for executing it. | Download template | |||
|
Planning and Managing Multiple Small Projects |
This guideline is a compendium of techniques for planning and managing a group of small projects. It provides explanations and file formats for consolidating information from multiple small projects in common project documents and using those documents to efficiently plan and track the projects. |
||||
|
|
|||||
|
New Product Business Plan |
A template for a Product/Project Business Plan that describes a new project for inclusion in the corporation portfolio of projects. This Business Plan template gives you a consistent and repeatable format for all product or project that are entered and tracked in the company's Pipeline of projects and products. |
||||
|
|
|||||
|
New Product/Project Proposal |
A template for creating a brief description of a new project or product idea, typically used as input to a project portfolio front-end "go/no go" decision process. Provides a consistent format for the capture and evaluation of new product and project ideas. Helps implement the front-end of a project portfolio selection methodology, where new project proposals can be rapidly and systematically compared with projects already in the start queue or in operation. |
||||
|
|
|||||
|
Plan Development: Logical Relationships/Dependencies |
This is the third of a series of six templates for project plan development, following task creation and resource assignment. This template illustrates the process for identifying task dependencies, and provides a table for capturing these dependences. This process should be done before the scheduling process, as it often leads to some repartitioning of the tasks in the work breakdown. |
||||
|
|
|||||
|
Plan Development: Optimizing Project Plan Tradeoffs |
This is the sixth of a series of six templates on plan development. This template gives a list of activities that help optimize a Project Plan after the first pass Base Schedule has been developed. It can help resolve the conflicting objectives in Scope, Schedule, and Resources that were initially established in defining the Project Objective Statement (POS). |
||||
|
|
|||||
|
Plan Development: Project Schedule and Critical Path |
This is the fifth of a series of six templates for project plan development. This one gives a checklist of scheduling activities to be performed on a set of tasks that have had a first pass at assigning ownership, identifying dependencies, and estimating durations. The result is a task schedule in calendar time. |
||||
|
|
|||||
|
Plan Development: Task Assignment and Deliverables |
This is the second of a series of six templates for project plan development. This template contains a table that is used to track the assignment of project tasks to individual owners along with the deliverable description and effort required. |
||||
|
|
|||||
|
Plan Development: Task Duration |
This is the fourth in a series of six templates for project plan development. This template describes the process of assigning durations to tasks. The same table that was provided in the template Plan Development - Task Assignment and Deliverables is repeated in this template, with the process focused on the Duration column. The process of estimating durations should be done after the first pass of identifying task dependencies, so that any task repartitioning resulting from identifying dependencies has already been done. |
||||
|
|
|||||
|
Plan Development: Task Identification - Work Breakdown Structure |
This is the first of a series of six templates for project plan development. This template lists the process steps for developing a work break down structure that identifies all the tasks in the project's work. Examples are provided to demonstrate the process. |
||||
|
|
|||||
|
Product Risk Assessment Table |
A Product Risk Assessment table used during the early project selection process for documenting product risks; giving them a score for impact, occurrence, and difficulty of detection; and making judgments on overall product risk and the need to prototype, do early feasibility tests, etc. |
||||
|
|
|||||
|
Project Scope Definition: Statement of Work (SOW) |
One approach to documenting high-level project objectives and key parameters in a concise document. Helps make sure the team and all stakeholders understand agree upon the reasons for doing the project, what the project will produce, and various important constraints and assumptions. Such a document should be done before detailed requirements specs are written. |
||||
|
|
|||||
|
Product Definition - Success Factors |
A checklist and worksheet for creating a Product Specification. The Product Specification is the written and approved document that unambiguously defines the result expected from the project effort. The heart of a Product Specification a clear, complete Product Definition. |
||||
|
|
|||||
|
Project Alternatives Tradeoff Table |
Use this template to cut through all the complex decisions that can plague the front end of a project. The table gives your team a concise way to document (and communicate!) the alternatives you are considering for scope and features, and the impact of various combinations on the project's cost, schedule, resources, and risk. Getting it all onto a page or two can really help a cross-functional team reach agreement on a reasonable scope that meets most important customer requirements. |
||||
|
|
|||||
|
Project Scope Definition: Deliverables |
An "is/is not" worksheet for defining the major deliverables that the project is chartered to deliver. They are expressed in the terminology of the customer or end user. The Product Specification will translate this into internal terminology and objectives. This is useful during the vision definition phase of a project. |
||||
|
|
|||||
|
Project Manager/Team Leader Selection |
A worksheet to help a project sponsor select a project manager by scoring candidates on a number of selection criteria. |
||||
|
|
|||||
|
Project Scope Definition: Mission Statement |
Advice for constructing a project objective or mission statement. Use the mission statement as the summary of a high-level project vision or objective document. |
||||
|
|
|||||
|
Project Sponsor |
A list of characteristics and responsibilities of the Project Sponsor. The Project Sponsor champions executive approval for the project. The Project Sponsor provides official backing, support for obtaining timely resources, and strategic direction. He or she acts as the focal point for project decisions beyond the project manager's scope of authority. |
||||
|
|
|||||
|
Project Team Leader Description - Roles & Responsibilities |
A list of the responsibilities of a project manager or team leader. Use this list to help select the project manager and to clarify with the new project manager what his or her key responsibilities are. |
||||
|
|
|||||
|
Project Team Organization and Assignments |
A checklist for organizing a project team, and a Roles and Responsibility table for documenting all the members of a cross-functional project team, including their roles, responsibilities, and contact information. |
||||
|
|
|||||
|
Project Flexibility Matrix |
A simple but effective tool that helps guide tradeoff discussions on Scope, Resources and Schedule. |
||||
|
|
|||||
|
Project Scope Definition: Vision Document |
A 1-2 page document created by a team in the early days of a project. Captures agreement on the high-level purpose and scope of the project. Great for making sure the right things are getting done, a real customer need is being fulfilled, and everyone is staying true to the project's goals. |
Download template |
|||
|
Release decision process guidelines |
Process that can be used near the end of a project to systematically review open issues and determine which ones must be corrected before release. |
||||
|
|
|||||
|
Review Checklists: Critical Design Review |
A checklist to guide a Critical Design Review (CDR). This review is held when a prototype exists that everyone can huddle around and constructively criticize. At this point a critical innovation has passed the "chicken test (an early "reality test" of the prototype)." The final CDR reviews the system "chicken test" results. A signoff form is included as part of the template. |
||||
|
|
|||||
|
Review Checklists: Preliminary Design Review |
Checklist for Preliminary Design Reviews (PDR). These are the first early design reviews that commence when enough high-level design work and investigations have been done to allow the Project Leader and team to suggest alternatives in product Performance, Time-to-market; product Cost, and project Cost (PTCC). Design should only have occurred at the sub-system and block diagram level at this point. |
||||
|
|
|||||
|
Project Plan Example – Small Project |
Are a 20-30 page dense project plan and hefty schedule file just too much for that smaller but important effort you've got to get done? No fear, project plans "lite" can take many useful and practical forms. Check out this example from one company's project to unify its Product Development Life-cycle methodology across 3 sites after an acquisition. It wasn't a huge time-and-resource effort, but it was hugely important to control the scope, do the right reviews, get cross-functional buy-in, and get the update done fast while getting on with product development! This simple plan is what they used to accomplish that; you can adapt it for your "smaller efforts." |
||||
|
|
|||||
|
Software Quality Release Criteria |
A short document that captures the criteria with which the software's quality will be judged at various stages of the project. |
||||
|
|
|||||
|
Software Release Life Cycle |
These files define recommended deliverables for the first 4 phases of a Software Release Life Cycle, focused on planning a major software release composed of multiple projects. The guidelines provide a one-to-two page detailed definition of each deliverable in the phase, defining Purpose, Audience, Prerequisites, Driver (who should drive or take responsibility for this deliverable getting done), and a detailed checklist of "recommended accomplishments" - what the deliverable should contain. These phases provide an upfront process that ensures all sources of requirements are considered, while helping cut through the clutter of all the things that COULD be included in a software release, to ensure the release focuses on important features and projects, AND is humanly possible to complete in the alotted time! |
|
|||
|
|
|||||
|
Software Release Life Cycle WBS (Microsoft Project file) |
This is an MSP file that provides a "work breakdown structure" that covers all 10 phases of the SRLC. For each phase it lists the deliverables called out in the Software Release Life Cycle Overview to show when they get accomplished in the phase. Typical dependencies and primary resource assignments are specified for each deliverable. The file can be edited to give you a big jump-start on your own release-level schedule. Contributed by Peter Michels, who has served as Director of Engineering and Program Management, Senior Project Manager, Software Development Manager and software developer in large and small companies. |
||||
|
|
|||||
|
Software Release Team Member Glossary |
Defines all the roles that may be needed on a software release team and gives a summary of their responsibilities. Understanding these roles is a critical part of setting up a release-level team that meshes effectively and appropriately with the individual project teams in the release. It also helps clarify what aspects of the release are managed at the release level (rather than done individually by each team), and by whom. Contributed by Peter Michels, who has served as Director of Engineering and Program Management, Senior Project Manager, Software Development Manager and software developer in large and small companies. |
||||
|
|
|||||
|
User Documentation Plan |
A checklist for planning the creation of the user and support documentation for a product. Examples of this documentation include user and service manuals, labeling text, box inserts, training manuals, etc. The checklist helps to ensure that this documentation is planned early in the project, all work involved in creating the documentation is identified, and ownership of both technical writing and development team input tasks is established. |
||||
|
|
|||||
|
Vendor assessment checklist |
A set of questions to ask a company or contract resource you're thinking of hiring for your project. The questions are aimed at ensuring you have a common understanding and good fit in goals, skills and experience, processes, and priorities. Avoid disaster! Choose your partner well. |
||||
|
|
|||||
|
WBS for Electromechanical Systems Project |
Task list/ Work Breakdown Structure (WBS) in Microsoft Project, from a multi-subsystem electomechanical development project, covering activities from the early planning phase through the end of the alpha and beta testing activities. Includes not only engineering activities for hardware and software design, prototyping, and integration, but also cross-functional activities such as user manual and training development. There are a number of custom views and filters coded to aid showing subsets of information - see the Views menu in Microsoft Project. |
||||
|
|
|||||
|
WBS & Gantt for 802.11 Master Development Schedule |
WBS with dependencies created for a 100-person project to develop an Access Point and PCMCIA card using IEEE 802.11b technology. Includes input from the software, hardware, mechanical engineering, marketing product management, technical publications, human factors, test systems, quality assurance, software release, operations, manufacturing, customer service and other various groups. Has dependencies for portions outsourced to an OEM company. |
||||
|
|
|||||
|
WBS & Gantt for USB Development Schedule |
WBS/ Gantt chart created for a project to create client laptop or desktop connections using IEEE 802.11b technology and USB version 1.1. The project was staffed by around 10 full allocated and 10 partially allocated resources from various groups. This is an example of an "early" WBS; it was produced very early in the Initiation Phase of the project for rough planning and used to elicit more detailed information from the cross-functional product development team. |
||||
|
|
|||||
|
|
|||||
|
Department and Project Level WBS Example |
Work Breakdown Structures examples, created for a multi-project IEEE 802.11 department project portfolio. This portfolio was composed of projects to create or enhance networking systems that include hardware and firmware components as well as cross-functional manufacturing and support activities. Used by the Director of the technical development department responsible for these products, to provide a portfolio-level Work Breakdown view of all the projects in his department and a starting point for defining the WBS for each project in his department in a consistent way. |
||||
|
|
|||||
|
Estimating Process and Methods |
Provides an overview of project estimating methods. Methods covered include Historical Data, decomposition, brainstorming, heuristics, Delphi, and more Using various estimating methods can help the project team come up with the best possible estimates. |
||||
|
|
|||||
|
Microsoft Office 2000 Deployment Template |
A template for use in Microsoft Project 98 that facilitates planning the deployment of Microsoft Office 2000 in an organization by generating a representative schedule with sample task durations and dependencies. When you open this template in Project 98, the sample schedule is automatically created. This schedule can then be modified to fit your own organization's planning. Provided by Microsoft Corporation. |
Download template |
|||
|
|
|||||
|
Microsoft Windows NT to Microsoft Windows 2000 Deployment Template |
A template for use in Microsoft Project 98 that facilitates planning the deployment of Microsoft Windows 2000 in an organization by generating a representative schedule with sample task durations and dependencies. When you open this template in Project 98, the sample schedule is automatically created. This schedule can then be modified to fit your own organization's planning. Provided by Microsoft Corporation. |
Download template |
|||
|
|
|||||
| MS Project Template for IT Software Development Project | This MS Project file was created by the PMO for the IT organization of a large company, as a guideline for consistent planning of their software development projects. It provides a full cross-functional work breakdown for such a project, from business process requirements definition all the way through acceptance testing and deployment, with related work such as training and documentation as well. All WBS elements are linked to show typical dependency relationships and have generic departmental resoruces assigned. In addition, every task is annotated with notes on the purpose of that task and guidelines for executing it. | Download template | |||
|
Plan Development: Logical Relationships/Dependencies |
This is the third of a series of six templates for project plan development, following task creation and resource assignment. This template illustrates the process for identifying task dependencies, and provides a table for capturing these dependences. This process should be done before the scheduling process, as it often leads to some repartitioning of the tasks in the work breakdown. |
||||
|
|
|||||
|
Plan Development: Optimizing Project Plan Tradeoffs |
This is the sixth of a series of six templates on plan development. This template gives a list of activities that help optimize a Project Plan after the first pass Base Schedule has been developed. It can help resolve the conflicting objectives in Scope, Schedule, and Resources that were initially established in defining the Project Objective Statement (POS). |
||||
|
|
|||||
|
Plan Development: Project Schedule and Critical Path |
This is the fifth of a series of six templates for project plan development. This one gives a checklist of scheduling activities to be performed on a set of tasks that have had a first pass at assigning ownership, identifying dependencies, and estimating durations. The result is a task schedule in calendar time. |
||||
|
|
|||||
|
Plan Development: Task Assignment and Deliverables |
This is the second of a series of six templates for project plan development. This template contains a table that is used to track the assignment of project tasks to individual owners along with the deliverable description and effort required. |
||||
|
|
|||||
|
Plan Development: Task Duration |
This is the fourth in a series of six templates for project plan development. This template describes the process of assigning durations to tasks. The same table that was provided in the template Plan Development - Task Assignment and Deliverables is repeated in this template, with the process focused on the Duration column. The process of estimating durations should be done after the first pass of identifying task dependencies, so that any task repartitioning resulting from identifying dependencies has already been done. |
||||
|
|
|||||
|
Plan Development: Task Identification - Work Breakdown Structure |
This is the first of a series of six templates for project plan development. This template lists the process steps for developing a work break down structure that identifies all the tasks in the project's work. Examples are provided to demonstrate the process. |
||||
|
|
|||||
|
Resource Leveling using Microsoft Project |
Guidelines for the complex and critical task of leveling the resources working on a project. Includes an overview of the general approaches, and detailed instructions for using the leveling features of MS Project. |
||||
|
|
|||||
|
Task Responsibility Matrix Formats |
Formats and example contents for a team Responsibility Matrix, used to document and communicate the type of involvement of each team member and/or different functional groups and the ownership of specific tasks. Provides an easy-to-scan condensed format to record important team member responsibilities and helps ensure that responsibility for and involvement in for "hidden" items (items that might not show up explicitly in your schedule) - such as key review attendance or key decisions - are explicitly documented. |
||||
|
|
|||||
|
WBS for Electromechanical Systems Project |
Task list/ Work Breakdown Structure (WBS) in Microsoft Project, from a multi-subsystem electomechanical development project, covering activities from the early planning phase through the end of the alpha and beta testing activities. Includes not only engineering activities for hardware and software design, prototyping, and integration, but also cross-functional activities such as user manual and training development. There are a number of custom views and filters coded to aid showing subsets of information - see the Views menu in Microsoft Project. |
||||
|
|
|||||
|
WBS & Gantt for 802.11 Master Development Schedule |
WBS with dependencies created for a 100-person project to develop an Access Point and PCMCIA card using IEEE 802.11b technology. Includes input from the software, hardware, mechanical engineering, marketing product management, technical publications, human factors, test systems, quality assurance, software release, operations, manufacturing, customer service and other various groups. Has dependencies for portions outsourced to an OEM company. |
||||
|
|
|||||
|
WBS & Gantt for USB Development Schedule |
WBS/ Gantt chart created for a project to create client laptop or desktop connections using IEEE 802.11b technology and USB version 1.1. The project was staffed by around 10 full allocated and 10 partially allocated resources from various groups. This is an example of an "early" WBS; it was produced very early in the Initiation Phase of the project for rough planning and used to elicit more detailed information from the cross-functional product development team. |
||||
|
|
|||||
|
|
|||||
|
Master Test List - Schedule and Results Log |
Provides a tabular format for listing the tests to be run during a testing cycle (such as Beta, System test etc.), with a place to categorize and describe each test, provide pass-fail criteria, indicate the planned run day or week; and log pass-fail test results. Usable on any project, but especially useful for smaller projects, where it can be THE test plan/test case document, while still providing a quick-reference tracking document for what has been tested, what has failed, what is left to test etc. |
||||
|
|
|||||
|
Planning and Managing Multiple Small Projects |
This guideline is a compendium of techniques for planning and managing a group of small projects. It provides explanations and file formats for consolidating information from multiple small projects in common project documents and using those documents to efficiently plan and track the projects. |
||||
|
|
|||||
|
Release decision process guidelines |
Process that can be used near the end of a project to systematically review open issues and determine which ones must be corrected before release. |
||||
|
|
|||||
|
Tracking Example – Small Project |
When the project is small and short and straightforward (but still important!), how to make sure it stays on track without going overboard on detail? Check out this example from one company's small project to unify its Product Development Life-cycle methodology across 3 sites after an acquisition. The team was small but it was still important to track and communicate actions and milestones and results of key reviews. See their approach to "lite tracking" for ideas for your own small projects. |
||||
|
|
|||||
|
Software Release Life Cycle Phase 5: Development Tracking |
This phase is focused on monitoring, controlling, and tracking at the release level. It is also a phase where test activities are reviewed, updated and finalized for movement of the various projects, components, sub-projects, modules, etc. into the formal Integration phase. |
||||
|
|
|||||
|
Project or Software Release One-Page Summary |
One-page format for communicating key information about a software release or project. Provides a handy way to communicate the purpose and contents of a release, along with key team and schedule information, to a variety of stakeholders in a nice at-a-glance, postable-on-the-cubicle-wall format. |
||||
|
|
|||||
|
Software Quality Release Criteria |
A short document that captures the criteria with which the software's quality will be judged at various stages of the project. |
||||
|
|
|||||
|
Tracking with Visible Deliverables |
This template provides formats and example project data illustrating effective ways to track project progress --- by explicitly tracking drafts, reviews, and completion of multiple very small deliverables. Embedded Excel files provide both data charts for capturing progress, and graphs automatically generated off the data. The examples include tracking detailed design activities and design review cycles for multiple subsystem or component designs; tracking completion of multiple small deliverables, in this case art or graphics assets on a multi-media project; tracking execution of test cases and test results ; and tracking defect discovery and correction rates during a testing phase. These approaches are especially valuable for when a team includes an outside partner or the team members are distributed . Tracking such "visible " deliverables is a much more effective and accurate way to assess progress than highly-subjective status such as "we're 50% complete on this task..." |
||||
|
|
|||||
|
|
|||||
|
Product Risk Assessment Table |
A Product Risk Assessment table used during the early project selection process for documenting product risks; giving them a score for impact, occurrence, and difficulty of detection; and making judgments on overall product risk and the need to prototype, do early feasibility tests, etc. |
||||
|
|
|||||
|
|
|||||
|
Opportunity Screening Worksheet |
This is an Opportunity Screening worksheet used to help determine if an idea is worth enough to the company to commission a product development project. The management team at your organization can use this worksheet to evaluate a number of factors in determining if a new product development project should be undertaken and identify the important issues in making that decision. The worksheet is written for analyzing a specific product idea - with respect to the market, the company's capability, potential market risks, return to the company, etc. With some deletion of items and minor modifications, the worksheet can be used for a benefits analysis for projects other than product development projects. |
||||
|
|
|||||
|
Plan Development: Task Identification - Work Breakdown Structure |
This is the first of a series of six templates for project plan development. This template lists the process steps for developing a work break down structure that identifies all the tasks in the project's work. Examples are provided to demonstrate the process. |
||||
|
|
|||||
|
|
|||||
©Copyright 2000-2010 Emprend, Inc. All Rights Reserved.
About us Site Map View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy