Recent Comments

    Project Risk Register

    The Project Risk Register is a summary risk document. The risk register should contain a listing of all sources of risk, risk impact, risk probability, contingency plans, risk owner and the status of the risk. The risk identification, impact assessment and risk ranking, contingency planning and project execution tasks are all inputs to this document.

    The risk register should be actively maintained throughout the project. The below example project risk register is based on a generic website development project.

    Risk ID




    Risk Impact


    Impact Description


    Risk Probability


    Risk Severity


    Risk Contingency


    Risk Owner






    Content will not be available when required 



    Missed deadline will result in funding cut. 





    Hire additional copy editors 


    Currently recruiting for additional staff 



    Project resources may be reallocated for other (higher) priority



    Resources are currently 100% committed to this project. Losing a
    resource would severely delay project. 





    Work with Portfolio Manager to ensure resource availability 


    Portfolio Manager will not reallocate staff. 



    End users may be resistant to new site workflow 



    Customer feedback was instrumental in site design, but not all
    customers will like the site changes. May result in bad publicity or
    customer satisfaction issues. 





    Implement online help facility. Provide additional customer support
    staff for transition. 

    Support Manager 

    Additional staff will be brought online 1 month prior to release.
    Online help facility added as change request. 



    Data loss 



    Data migration may result in loss of customer data. Customer data is
    key for day to day business operations. 





    Revisit backup procedures. Execute manual backup prior to



    Example Project Assumptions for a Data Migration Project

    Example Project Assumptions for a Data Migration Project.

    Data Migration projects, especially those across platforms or into new database structures, are inherently complex. Identifying project assumptions early in the project planning process is necessary to facilitate the scope of work definition. Assumptions should be documented clearly, without use of department specific acronyms or terminology which might not be understood by all members of the project team. Project assumptions, especially those initially identified by the Project Manager without input from the rest of the project team, should be distributed to the whole team as early in the project planning process as is reasonable.

    Example Billing Project data migration project assumptions

    • Business rules relating to billing processes (e.g. invoice cycles, pro-rating logic, re-connection and other fee structures) remain the same. A summary of used business rules will be distributed by the Finance Department.
    • Data for active billing subscribers will be migrated. As at (date), there are 1000 active subscribers.
    • Data for recently disconnected subscribers will be migrated. As at (date), there remain 250 inactive subscribers. Given current churn rates, there is a high probability that 75% of these currently inactive subscribers will request re-connection.
    • Data for customers with an account balance (debt or credit) will be migrated.
    • Data for customers with un-returned equipment will be migrated
    • Data for customers currently in the collections queue will be migrated.
    • Data to be migrated includes (refer to data dictionary for format and detailed description of data to be migrated):
      • Customer name
      • Customer contact details
      • Customer billing package details
      • Customer equipment details
      • Customer invoices generated since (date)
      • Current, 30, 60, 90, > 90 day balances
      • Notes on customer account
      • Service call history details
      • Method of Payment details (Credit Card, Direct Deposit details)
    • Data to be migrated must be exported and cleaned before formatted for import into new platform. Cleaning can be completed by the Customer Service team before the end of (date).
    • Data transformation can be completed by the Billing Administration department.
    • The transformation tools identified and tested by the Billing Administration department will be adequate for the scope and duration of the project.
    • Existing and new platform documentation is accurate.
    • Internal staffing resources will be made available to complete required system testing.

    Data Center Relocation Work Breakdown Structure

    The purpose of this document is to provide project managers and team members with an overview of the requirements for a data center relocation. This data relocation plan document can also be used as a checklist in support of an existing data center relocation project.

    1.1. Data Center Relocation Project Management

    1.1.1. Scheduling

    1.1.2. Procurement Management

    1.2. New Data Center Requirements Definition

    1.2.1. Business Service Level Agreement Insurance

    1.2.2. Technical Current Data Center Inventory Communications Migration Requirements Contract Review New Data Center Rack Diagrams Communications Interconnects Cabling Power Environmental Controls Security Access

    1.3. Acquisition

    1.3.1. New Data Center Site Visit Contract

    1.3.2. Hardware Issue RFP Selection Criteria Purchase

    1.3.3. Communications Data Interconnect Voice Interconnect

    1.4. Installation Prerequisites

    1.4.1. Resource Allocation

    1.4.2. Notifications Internal Customer

    1.4.3. Site Preparation Circuit Cut Over Plan Rack Space Allocation Power Cabling Network IP Allocation

    1.4.4. Testing

    1.4.5. Configuration Backups

    1.4.6. Detailed Installation Documentation

    1.5. Migration

    1.5.1. Hardware Installation Testing

    1.5.2. Routing and Switching Cut Over Testing Cancel Circuit to Old Data Center

    1.6. Operations Switch Over

    1.6.1. SLA monitoring

    1.6.2. Documentation

    1.6.3. Disaster Recovery Testing

    Microsoft Office Format of Data Center Relocation Plan Work Breakdown Structure

    Website Development Contract Considerations

    Aside from the standard clauses (liability, force majeure, cancellation, etc.), a website development contract should specifically address the following:


    Many website development contracts will be signed before the project scope has been fully defined. In cases such as this, the contract should require the development firm to fully document project deliverables, budget and schedule before formally beginning work on web site. Contractually, this could be considered the first project milestone. If this milestone is not reached (and the contract would need to specify criteria for acceptance of this and all project milestones), then the contract would be void.

    If a scope of work has been developed, then, as part of the project plan, the project deliverables need to be included in the website development contract. The scope of work includes all work to be done as part of the project. Items not specifically included in the scope of work are considered out of scope and would be addressed as part of a change management process. A website development project scope of work might include:

    • Design – site graphics, layout, color schemes, logos, images, illustrations, maps, etc. If these are to be developed by an external design studio, then issues of copyright and use will specifically need to be addressed as part of a development contract. If the art works are to be provided by the customer, then the contract should specifically state this. The contract should specify the designs to be provided in as much detail as is possible. For example, “the development house will design 3 proof logos based on existing marketing materials and corporate color schemes for review by the client.”

    • Content – content includes all text, media, downloads. Content development is perhaps the most time consuming task in developing a web site. Content is extremely important! Sites that plan on deriving revenue from traffic will need content to attract and retain site visitors.

    • Supporting applications – most websites will utilize applications to support content delivery and information collection. These may include bulletin board systems, forms, database systems, shopping carts, product catalog management systems, etc. Many of these applications are available as open source. The website contract should specify the source of the applications, whether open source or custom development and document any license restrictions or rights associated with these applications. In instances of custom development, license and right to use should be specified in the contract.

    Change Management

    Change management procedures outline how changes from the initial scope are handled by both the service provider and the customer. Most change management policies call for documenting the nature of the change and allowing time for proper evaluation of the costs of change and subsequent impacts on schedule, quality and risk. In the case of a website development contract, particular attention should be paid to managing design changes, as these can be both time consuming and expensive.

    Project Responsibilities

    A responsibilities clause provides clarity to the various roles and responsibilities of team members and management involved in the website development project. If the client is responsible for generating content, for example, then this should be documented under the responsibilities clause. The contract should cover at the very minimum: design, media and content sources, search engine optimization, testing, maintenance, hosting.

    Payment Terms

    Most contracts that cover a technology deliverable will use milestones for determining the payment schedule. It is essential that these milestones be clearly defined, with documented milestone acceptance criteria. An example milestone for a website development contract might be delivery of design proofs, completion of content, or successful testing of a data management application.

    User Acceptance Testing

    Testing is essential, as a company’s website is often the first interaction that a potential customer, partner or employee has with the organization. Like all company documents, sales and marketing materials, the website must be free from error. Completion of testing should signify a project milestone.


    A warranty period will ensure that underlying web applications, components, scripts and other site developments are free from error for a period following project sign off by the client. The contract should detail the specifics of the warranty (e.g. length of warranty, what elements are covered by the warranty, time frame for remedy and what costs, if any, will be incurred by the client in the event that warranty repairs are required).

    Ongoing Responsibilities

    If the development house is responsible for site maintenance, then a regular maintenance schedule should be included in the contract, as well as a listing of the items which are covered by the maintenance agreement (e.g. data archiving, product catalog updates, content updates, design refreshes).


    In addition to underlying web applications, scripts and source code, the contract will need to cover copyright of site design, logos, graphics, illustrations, images or other media produced for the website.

    Project Timelines

    The development contract should specify in as much detail as possible the proposed delivery schedule. If a formal scope of work has not yet been established, then defining a project timeline will not be possible. Rather, the development contract should be used to specify expectations and state that as part of the formal project scope, a project schedule will be created for the client to review.

    The most important part of the website development contract and procurement process is having a legal expert who is familiar you’re your business and the project review the contract!

    Office Relocation Example Risk Matrix

    This example risk matrix uses the Office Relocation project assumptions and Office Relocation work breakdown structure documents as input. This is not an
    exhaustive list of all Office Relocation project risks and may not be applicable to your particular project. Rather, this matrix is intended to provide a framework for
    identifying, prioritizing and managing risk.

    Risk Description




    Mitigation Strategy

    Priority Scale 1-5 (5 = most severe, greater probability)




    Technology:  Data and/or Voice circuits will not be available by (date).  Company will not be able to communicate. (Note A)




    1. Contact wireless solution vendor as redundant provider.
    2. Seek alternate fixed data / voice provider
    3. Allow employees to work from home
    4. Extend existing lease by 1 mo nth to provide additional circuit implementation time.

    Operations:  Inadequate insurance.  Company may be underinsured.




    1. Check coverage
    2. Review policy

    Construction:  Construction build not complete by (date) (Note B).  Company will not be able to relocate according to schedule.




    1. Delay lease termination notice

    Construction:  Construction deficiencies.  Office environment may be hazardous.




    1. Construction warranty
    2. Phased payments
    3. Use known good contractor
    4. Request inspection

    Move:  Equipment breakage.  Core networking gear and/or peripherals would need to be replaced.




    1. Adequate packing
    2. Hire professional packing/moving company
    3. Employees responsible for laptops
    4. Ensure spare equipment available

    Note A: Historically, vendor has had difficulty deploying high speed circuits to this part of town.
    Note B: Project is currently 1 month ahead of schedule. However, project is complex, so some delays are expected.

    For additional reference, review the Project Risk Register and Risk Impact and Probability Assessment documents.

    Trade show risk planning, identification and management

    Trade shows are a fantastic opportunity for companies to showcase new products and services. If a show is well planned and managed, companies can expect to meet numerous potential customers and generate strong sales leads. A poorly planned and managed show, however, can tarnish a company’s reputation and provide a poor return on investment.

    As part of the trade show project planning process, the project manager must lead the show team in identifying all risks associated with the trade show. The goal of this process is to document all essential information relating to project risk.

    The below information is intended to assist in this trade show planning process and is not intended to be a complete risk assessment. Each company will have unique business objectives supporting with the trade show project. The risk identification process must support these business objectives

    For additional information relating to risk, refer to the Project Diva article on project risk identification and management.

    Risk ID




    Impact Description

    Possible mitigation



    Poor event turnout

    Unforeseen conditions may also contribute (e.g. weather,

    Poor ROI; minimal sales leads; poor sales; over-purchase of give-aways,

    Vetting of show venue; show attendee profile; purchase re-useable
    give-aways; marketing campaign to target specific key



    Poor ROI



    Define measurement of show success; clearly define show goals and



    Lack of site traffic to booth

    Booth location


    Staff to physically direct potential customers to



    Trade show costs limit booth location and size options

    Limited budget

    Reduced traffic to booth; reduced sales leads; poor ROI

    Consider partnering with a supporting product vendor; show business
    case analysis



    Manufacturer delay in shipping show materials to home


    Materials not available for show; negative credibility

    Research and identify alternative vendors; order materials



    Booth/materials damaged in shipping to show venue



    Professional packing and unpacking; contingency plan for display;
    verify insurance coverage



    Personnel not available; show marketing and/or execution plans are too
    labor intensive.


    Negative credibility; technical trade show staff are unavailable to
    support normal business operations

    Schedule at least 1 month in advance; identify and train alternative
    staff; financial incentives



    Technical display failure


    Poor sales; negative credibility

    Full system testing; budget for and bring redundant



    Demo errors


    Negative credibility

    Full system testing using multiple test groups



    Useless prospect data gathered from show


    Poor ROI

    Standardized forms; staff bonus based on data



    Positive risk of overselling units


    Unable to deliver on time

    Review historical trade show sales records;

    Trade show risk planning, identification and management (.docx format)

    Trade Show Project Planning

    Trade Show Planning, Execution, Project Closure

    Trade shows are a cost effective way to meet many potential customers within a short period of time. These potential customers are interested in the show venue, and by extension, in the products and services which your company offers. The Trade Show Bureau claims that the average total cost of closing a sale in the field is $1,080, while the cost of closing a sale to a qualified trade show prospect is $419 (data taken from

    For the small business, trade shows level the sales and marketing playing field. Floor space is relatively inexpensive, and as such, even small companies can afford a savvy display booth. The success of the trade show, however, does not depend solely on booth design or even the product or service being sold. Successful trade shows depend on how well the show plan is developed and executed.

    A trade show is one component of a comprehensive marketing plan, which begins months prior to a show and ends only after the project team have fully explored all of the successes and lessons learned from the trade show project. The trade show project plan will include activities such as researching potential venues, direct marketing to both existing and potential customers, booth design, staff training, well designed product demonstrations, delivering effective seminars, and coordinating all of the show activities to ensure that time spent at the show brings in quality leads that result in sales.

    Project Documents

    Trade Show Project Plan (.mpp format)

    WBS for Trade Show Project Plan

    Trade show risk planning, identification and management (.doc format)

    Point of Sale (POS) Project Documents

    Point of Sale Implementation Project Planning

    These documents provide information and assistance in planning and deploying a Point of Sale system.

    Project Documents

    Point of Sale WBS

    Point of Sale Needs Assessment Checklist

    Point of Sales (POS) Systems Needs Assessment

    A point of sales (POS) systems needs assessment is essential for planning the selection and deployment of a point of sales system. This checklist will assist in defining system requirements and will also provide the foundation for the software and systems selection process.

    As so many types of industry require a POS system, many of the requirements listed below will not directly apply to all businesses. However, it is worth considering each of the requirements listed below, as this will help define the initial list of suitable POS software vendors.

    POS General Requirements

  • Product is easy to use

  • Touch screen interface

  • Reputable vendor (local?)

  • Established and documented product lifecycle (consider security and functional updates)

  • Minimal investment; can be leased

  • Single physical cash drawer with integrated safe; minimal separate physical parts

  • Footprint size (e.g. 16″ X

  • POS Functional Requirements

    Enterprise Networking

  • Support for multiple store locations accessing shared inventory

  • Support for multiple store locations accessing independent inventory

  • Support for multiple terminals at any location

  • Customer Access

  • Support for customer self service kiosks

  • Support for self-checkout

  • Integration with WWW site offering online payment

  • Accounting

  • Support for interconnection with existing back office accounting system

  • Enables electronic submission of tax data

  • Provides for audit control, revenue assurance

  • Inventory and Order Fulfillment Management

  • Support for interconnection with existing inventory management system

  • Support for interconnection with existing shipping management system

  • Provides an inventory management system, with:

  • Inventory control

  • Product database is easy to manage and update

  • Product database can be imported /exported from/to other applications

  • Automated reordering

  • Integrated bar code printing

  • Integrated label printing

  • Provides vendor / supplier management

  • Easy menu setup and management (restaurant)

  • Interface to liquor control device

  • Transaction Processing

  • User auditing and security

  • Governance and user data privacy compliance

  • Supports discount management and sale override capabilities

  • 2-4 second credit card processing

  • Support for returns / exchanges

  • Restaurant order relay

  • Data

  • Real time data

  • Data stored in commercially available database

  • Business Intelligence Reporting

  • Supports use of existing reporting tool set or enables customized reporting

  • Inventory status

  • Items on order

  • Buying trends by store

  • Most popular product

  • Product churn

  • Trend analysis

  • Sales forecasts

  • Peripheral support

  • Handheld and mobile devices

  • Keyboard, mouse

  • Cash drawer

  • Bar code scanner

  • Check reader

  • Credit Card swipe

  • Back up phone line

  • Receipt printer

  • Report printer

  • Weight scale

  • Fingerprint ID (or other security identifier)

  • Marketing

  • Supports gift cards

  • Supports other customer loyalty programs

  • Email collection and export

  • POS Receipt / Ticket Printer

  • Network / email integration

  • Identify receipt / ticket size specifications

  • Identify receipt / ticket paper specifications

  • Supports customer message of the day

  • Supports additional message printing

  • POS Training Requirements

  • On-site training program

  • Documentation, tutorials

  • POS Support Requirements

  • 24 X 7 X 365 support

  • POS Security Requirements

  • Provides for comprehensive Disaster Recovery

  • Provides strong security framework

  • Supports integrated video surveillance

  • Supports secure remote management access

  • Project Risk Identification

    Identifying and assessing risk are essential components of project management. Risk identification needs to begin as early in the project as is possible and should include, at the very minimum, the project manager, project team members and key stakeholders. Ideally, if the project is part of a larger portfolio of, for example, technology projects, then the technology project portfolio manager would also be present during the initial phases of the project risk identification process. The portfolio manager can provide insight into the overall relationship between the organization’s various projects, and identify risks or impacts associated with other projects within the portfolio. This level of participation also ensures consistency of approach to risk identification, management and mitigation across the organization.

    It is important to remember that project risk identification and management is an iterative process, to be undertaken regularly. Risks need to be clearly defined and documented. Otherwise, the precise nature of the risk cannot be understood, making mitigation and control difficult. The following are examples of a clearly defined risk:

    • Market Risk – insufficient demand for product. If market penetration is 40% less than anticipated, then funding for phase 2 will not be available.

    • Legal Risk – land title not properly researched.

    • Acquisition Risk – failure of equipment to be delivered to site on time.

    There are many methods for identifying risk in a project. This list is not intended to be exhaustive, but simply to provide an overview of the most popular approaches to risk. All risks identified should be documented on the project risk register.

    • Lessons Learned – using lessons learns from previous projects as input into the current project risk identification and assessment process is an excellent starting point. Often projects are similar enough in circumstance that many of the risks pertinent to one project will apply to another.

      The accuracy of lessons learned documentation is normally quite high, and is often quite detailed.

    • Brainstorming –brainstorming is neither the most thorough nor efficient technique for risk identification. However, most project managers and team members are familiar with the process, as it is generic enough to be utilized in most problem solving situations. Brainstorming involves team members freely sharing ideas relating to one particular topic. In a risk identification session, this might entail the project manager or brainstorming facilitator to ask, for example “what are the risks associated with deploying this product?” Results are usually documented for later prioritization and review by the project manager.

    • Crawford Slip – the Crawford slip is a technique for collecting risk identification data. The advantage of this method is the large amount of data that can be collected from various sources in a relatively short amount of time. The process is also anonymous, freeing participants to provide genuine answers without fear or prejudice.

      The process involves team members documenting responses on to a particular question or premise. All participants respond to the same question or premise 10 times (many project managers will shorten this to 5) in order to extract the greatest amount of information. Results are then collated, either by the team as a whole (as part of an impact assessment strategy) or separately by the project manager.

    • Delphi Technique – the Delphi technique of risk identification relies on experts to provide information on projects risks. The technique essentially involves a question, answer and follow-up process, enabling the project manager to refine the expert responses and minimize disagreement between the different project experts. Key to this process is both the identification of the experts and the definition of the questions to be posed to the experts. Once the questions have been formulated, they are sent to each individual expert for response. The role of the project manager is to identify the commonalities and specific concerns of each expert. The expert responses are reformulated and sent again to each of the experts for comment.

    There are dozens of other techniques and tools for use in project risk identification, each with its own strengths and weaknesses. It is important to investigate the different risk identification tools and techniques, as many are best suited to use in particular situations or for identifying a particular type of risk.

    Once project risks have been identified, the next step is risk impact and probability assessment, which defines how cost, time, quality and scope are affected by the risk, should it be realized.