Saturday, April 12, 2014

Communication Management Plan template

COMMUNICATIONS MANAGEMENT PLAN TEMPLATE

Introduction

The purpose of the Communications Management Plan is to define the communication requirements for the project and how information will be distributed. The Communications Management Plan defines the following:
  • What information will be communicated—to include the level of detail and format
  • How the information will be communicated—in meetings, email, telephone, web portal, etc.
  • When information will be distributed—the frequency of project communications both formal and informal
  • Who is responsible for communicating project information
  • Communication requirements for all project stakeholders
  • What resources the project allocates for communication
  • How any sensitive or confidential information is communicated and who must authorize this
  • How changes in communication or the communication process are managed
  • The flow of project communications
  • Any constraints, internal or external, which affect project communications
  • Any standard templates, formats, or documents the project must use for communicating
  • An escalation process for resolving any communication-based conflicts or issues

This Communications Management Plan sets the communications framework for this project. It will serve as a guide for communications throughout the life of the project and will be updated as communication needs change. This plan identifies and defines the roles of persons involved in this project. It also includes a communications matrix which maps the communication requirements of this project. An in-depth guide for conducting meetings details both the communications rules and how the meetings will be conducted, ensuring successful meetings. A project team directory is included to provide contact information for all stakeholders directly involved in the project.

Communications Management Approach

Approximately 80% of a Project Manager’s time is spent communicating. Think about it – as a Project Manager you are spending most of your time measuring and reporting on the performance of the project, composing and reading emails, conducting meetings, writing the project plan, meeting with team members, overseeing work being performed, meeting with clients over lunch and many more activities related to your projects.
You should give considerable thought to how you want to manage communications on this project. By having a solid communications management approach you’ll find that many project management problems can be avoided. In this section give an overview of your communications management approach.

The Project Manager will take a proactive role in ensuring effective communications on this project. The communications requirements are documented in the Communications Matrix presented in this document. The Communications Matrix will be used as the guide for what information to communicate, who is to do the communicating, when to communicate it and to whom to communicate.
As with most project plans, updates or changes may be required as the project progresses or changes are approved. Changes or updates may be required due to changes in personnel, scope, budget, or other reasons. Additionally, updates may be required as the project matures and additional requirements are needed. The project manager is responsible for managing all proposed and approved changes to the communications management plan. Once the change is approved, the project manager will update the plan and supporting documentation and will distribute the updates to the project team and all stakeholders. This methodology is consistent with the project’s Change Management Plan and ensures that all project stakeholders remain aware and informed of any changes to communications management.

Communications Management Constraints

All projects are subject to limitations and constraints as they must be within scope and adhere to budget, scheduling, and resource requirements. Project planning and documentation are no exception to this rule. There may also be legislative, regulatory, technology, or organizational policy requirements which must be followed as part of communications management. These constraints must be clearly understood and communicated to all stakeholders. While communications management is arguably one of the most important aspects of project management, it must be done in an effective manner and within the constraints of the allocated budget, time, and resources.
All project communication activities will occur within the project’s approved budget, schedule, and resource allocations. The project manager is responsible for ensuring that communication activities are performed by the project team and without external resources which will result in exceeding the authorized budget. Communication activities will occur in accordance with the frequencies detailed in the Communication Matrix in order to ensure the project adheres to schedule constraints. Any deviation of these timelines may result in excessive costs or schedule delays and must be approved by the project sponsor.
ABC Corp. organizational policy states that where applicable, standardized formats and templates must be used for all formal project communications. The details of these policy requirements are provided in the section titled “Standardization of Communication” in this document.
ABC Corp. organizational policy also states that only a Vice President or higher level employee may authorize the distribution of confidential information. The project manager is responsible for ensuring that approval is requested and obtained prior to the distribution of any confidential information regarding this project.

Stakeholder Communication Requirements

Most projects consist of a broad range of stakeholders all of whom may have differing interests and influence on the project. As such, it is important for project teams to determine the communication requirements of these stakeholders in order to more effectively communicate project information. There are a number of methods for determining stakeholder communication requirements; however, it is imperative that they are completely understood in order to effectively manage their interest, expectations, and influence and ensure a successful project.
As part of identifying all project stakeholders, the project manager will communicate with each stakeholder in order to determine their preferred frequency and method of communication. This feedback will be maintained by the project manager in the project’s Stakeholder Register. Standard project communications will occur in accordance with the Communication Matrix; however, depending on the identified stakeholder communication requirements, individual communication is acceptable and within the constraints outlined for this project.
In addition to identifying communication preferences, stakeholder communication requirements must identify the project’s communication channels and ensure that stakeholders have access to these channels. If project information is communicated via secure means or through internal company resources, all stakeholders, internal and external, must have the necessary access to receive project communications.
Once all stakeholders have been identified and communication requirements are established, the project team will maintain this information in the project’s Stakeholder Register and use this, along with the project communication matrix as the basis for all communications.

Roles

Project Sponsor
The project sponsor is the champion of the project and has authorized the project by signing the project charter. This person is responsible for the funding of the project and is ultimately responsible for its success. Since the Project Sponsor is at the executive level communications should be presented in summary format unless the Project Sponsor requests more detailed communications.
Program Manager
The Program Manager oversees the project at the portfolio level and owns most of the resources assigned to the project. The Program Manager is responsible for overall program costs and profitability as such they require more detailed communications than the Project Sponsor.
Key Stakeholders
Normally Stakeholders includes all individuals and organizations who are impacted by the project. For this project we are defining a subset of the stakeholders as Key Stakeholders. These are the stakeholders with whom we need to communicate with and are not included in the other roles defined in this section. The Key Stakeholders includes executive management with an interest in the project and key users identified for participation in the project.
Change Control Board
The Change Control Board is a designated group which is reviews technical specifications and authorizes changes within the organizations infrastructure. Technical design documents, user impact analysis and implementation strategies are typical of the types of communication this group requires.
Customer
You should identify the customer if the project is the result of a solicitation. In such a case, the customer will be involved in reviewing prototypes, approval of designs and implementation stages and acceptance of the final project the project generates.
The customer for this project is . As the customer who will be accepting the final deliverable of this project they will be informed of the project status including potential impacts to the schedule for the final deliverable or the product itself.
Project Manager
The Project Manager has overall responsibility for the execution of the project. The Project Manager manages day to day resources, provides project guidance and monitors and reports on the projects metrics as defined in the Project Management Plan. As the person responsible for the execution of the project, the Project Manager is the primary communicator for the project distributing information according to this Communications Management Plan.
Project Team
The Project Team is comprised of all persons who have a role performing work on the project. The project team needs to have a clear understanding of the work to be completed and the framework in which the project is to be executed. Since the Project Team is responsible for completing the work for the project they played a key role in creating the Project Plan including defining its schedule and work packages. The Project Team requires a detailed level of communications which is achieved through day to day interactions with the Project Manager and other team members along with weekly team meetings.
Steering Committee
The Steering Committee includes management representing the departments which make up the organization. The Steering Committee provides strategic oversight for changes which impact the overall organization. The purpose of the Steering Committee is to ensure that changes within the organization are effected in such a way that it benefits the organization as a whole. The Steering Committee requires communication on matters which will change the scope of the project and its deliverables.
Technical Lead
The Technical Lead is a person on the Project Team who is designated to be responsible for ensuring that all technical aspects of the project are addressed and that the project is implemented in a technically sound manner. The Technical Lead is responsible for all technical designs, overseeing the implementation of the designs and developing as-build documentation. The Technical Lead requires close communications with the Project Manager and the Project Team.

Project Team Directory

The following table presents contact information for all persons identified in this communications management plan. The email addresses and phone numbers in this table will be used to communicate with these people.
Role Name Title Organization/ Department Email Phone
Project Sponsor A. White VP of Technology IT a.white@abc.com (555) 555-1212
Program Manager B. Brown PMO Manager PMO b.brown@abc.com (555) 555-1213
Project Manager C. Black Project Manager PMO c.black@abc.com (555) 555-1212
Project Stakeholders See Stakeholder Register See Stakeholder Register See Stakeholder Register See Stakeholder Register See Stakeholder Register
Customer J. Doe XYZ Corp. Manager IT j.doe@xyz.com (555) 555-8121
Project Team




Technical Lead




Communication Methods and Technologies

Many times, the methods and technologies used to communicate are just as important of a consideration as the information being communicated. Imagine a large project with many stakeholders who all have different technological capabilities. Some may have access to a share drive while others do not. Some may have access to video teleconferencing and others only have telephone and email capabilities. In order to be effective, project information must be communicated to everyone involved by some method using available technology. Determining communication methods and what technologies are available should be part of determining stakeholder communication requirements.
The project team will determine, in accordance with ABC Corp. organizational policy, the communication methods and technologies based on several factors to include: stakeholder communication requirements, available technologies (internal and external), and organizational policies and standards.
ABC Corp. maintains a SharePoint platform within the PMO which all projects use to provide updates, archive various reports, and conduct project communications. This platform enables senior management, as well as stakeholders with compatible technology, to access project data and communications at any point in time. SharePoint also provides the ability for stakeholders and project team members to collaborate on project work and communication.
For stakeholders who do not have the ability to access SharePoint, a web site will also be established for the project. Access to the website will be controlled with a username and password. Any stakeholders identified who are not able to access SharePoint will be issued a unique username and password in order to access the web site. The project manager is responsible for ensuring all project communications and documentation are copied to the web site and that the content mirrors what is contained on the SharePoint platform.
ABC Corp. maintains software licenses for MS Project software. All project teams are responsible for developing, maintaining, and communicating schedules using this software. PERT Charts are the preferred format for communicating schedules to stakeholders. The project schedule will be maintained on both the SharePoint platform and the project website.
All project communication and documentation, in addition to being maintained on the SharePoint platform and project website, will be archived on the internal ABC Corp. shared drive which resides in the PMO program directory. Organizational naming conventions for files and folder will be applied to all archived work.

Communications Matrix

The following table identifies the communications requirements for this project.
Communication Type Objective of Communication Medium Frequency Audience Owner Deliverable Format
Kickoff Meeting Introduce the project team and the project. Review project objectives and management approach. - Face to Face Once - Project Sponsor
- Project Team
- Stakeholders
Project Manager - Agenda
- Meeting Minutes
- Soft copy archived on SharePoint site and project website.
Project Team Meetings Review status of the project with the team. - Face to Face
- Conference Call
Weekly - Project Team Project Manager - Agenda
- Meeting Minutes
- Project Schedule
- Soft copy archived on SharePoint site and project website.
Technical Design Meetings Discuss and develop technical design solutions for the project. - Face to Face As Needed - Project Technical Staff Technical Lead - Agenda
- Meeting Minutes
- Soft copy archived on SharePoint site and project website.
Monthly Project Status Meetings Report on the status of the project to management. - Face to Face
- Conference Call
Monthly - PMO Project Manager - Slide Updates - Project Schedule - Soft copy archived on SharePoint site and project website.
Project Status Reports Report the status of the project including activities, progress, costs and issues. - Email Monthly - Project Sponsor
- Project Team
- Stakeholders
- PMO
Project Manager - Project Status Report
- Project Schedule
- Soft copy archived on SharePoint site and project website.

Communication Flowchart

Flowcharts provide a visual representation of a process or processes which often allow a better understanding of how the process is intended to work. Project communications may be extremely complex depending on the size and scope of the project and the number of stakeholders. A flowchart provides all stakeholders with a better understanding of the steps involved with the distribution of all project communications.
The communication flowchart below was created to aid in project communication. This flowchart provides a framework for the project team to follow for this project. However, there may be occasions or situations which fall outside of the communication flowchart where additional clarification is necessary. In these situations the Project Manager is responsible for discussing the communication with the Project Sponsor and making a determination on how to proceed.
Communications Flowchart

Guidelines for Meetings

Meeting Agenda
Meeting Agenda will be distributed 5 business days in advance of the meeting. The Agenda should identify the presenter for each topic along with a time limit for that topic. The first item in the agenda should be a review of action items from the previous meeting.
Meeting Minutes
Meeting minutes will be distributed within 2 business days following the meeting. Meeting minutes will include the status of all items from the agenda along with new action items and the Parking Lot list.
Action Items
Action Items are recorded in both the meeting agenda and minutes. Action items will include both the action item along with the owner of the action item. Meetings will start with a review of the status of all action items from previous meetings and end with a review of all new action items resulting from the meeting. The review of the new action items will include identifying the owner for each action item.
Meeting Chair Person
The Chair Person is responsible for distributing the meeting agenda, facilitating the meeting and distributing the meeting minutes. The Chair Person will ensure that the meeting starts and ends on time and that all presenters adhere to their allocated time frames.
Note Taker
The Note Taker is responsible for documenting the status of all meeting items, maintaining a Parking Lot item list and taking notes of anything else of importance during the meeting. The Note Taker will give a copy of their notes to the Chair Person at the end of the meeting as the Chair Person will use the notes to create the Meeting Minutes.
Time Keeper
The Time Keeper is responsible for helping the facilitator adhere to the time limits set in the meeting agenda. The Time Keeper will let the presenter know when they are approaching the end of their allocated time. Typically a quick hand signal to the presenter indicating how many minutes remain for the topic is sufficient.
Parking Lot
The Parking Lot is a tool used by the facilitator to record and defer items which aren’t on the meeting agenda; however, merit further discussion at a later time or through another forum.
A parking lot record should identify an owner for the item as that person will be responsible for ensuring follow-up. The Parking Lot list is to be included in the meeting minutes.

Communication Standards

Standardization is a proven way to simplify the complexities of project management communications. Many organizations develop and use standard templates or formats for the various communication tools used throughout projects. Standard templates and formats may be applied to certain types of project meetings or specific types of communication (i.e. emails, status reports, etc.). By using standardization, organizations can help ensure that its project teams and stakeholders have a thorough understanding of what is expected and achieve consistent and effective communications.
In addition to standard templates and/or formats, organizations may standardize file naming or sharing conventions. An organization may use SharePoint or some other type of Web Portal/Network tool (blogs, message boards, etc.) as a standard platform from which to share information and communicate. Additionally, an organization may have standard file naming conventions for their stored data on their internal share drives. Many of these tools and new technologies are used in today’s projects with team members and stakeholders often spread over wide geographic areas. Standardization provides a level of simplicity to an organization’s communication platforms and improves effectiveness and efficiency.
For this project, ABC Corp. will utilize standard organizational formats and templates for all formal project communications. Formal project communications are detailed in the project’s communication matrix and include:
Kickoff Meeting – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.
Project Team Meetings – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.
Technical Design Meetings - project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.
Monthly Project Status Meetings - project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard slideshow template.
Project Status Reports – project team will utilize ABC Corp. standard templates for meeting agenda and meeting minutes. Additionally the standard project status report document, available on the share drive, will be used to provide project status.
Informal project communications should be professional and effective but there is no standard template or format that must be used.

Communication Escalation Process

As issues or complications arise with regards to project communications it may become necessary to escalate the issue if a resolution cannot be achieved within the project team. Project stakeholders may have many different conflicting interests in a given project. While escalations are a normal part of project management, there must be a documented process that defines how those escalations will take place.
Efficient and timely communication is the key to successful project completion. As such, it is imperative that any disputes, conflicts, or discrepancies regarding project communications are resolved in a way that is conducive to maintaining the project schedule, ensuring the correct communications are distributed, and preventing any ongoing difficulties. In order to ensure projects stay on schedule and issues are resolved, ABC Corp. will use its standard escalation model to provide a framework for escalating communication issues. The table below defines the priority levels, decision authorities, and timeframes for resolution.
Priority Definition Decision Authority Timeframe for Resolution
Priority 1 Major impact to project or business operations. If not resolved quickly there will be a significant adverse impact to revenue and/or schedule. Vice President or higher Within 4 hours
Priority 2 Medium impact to project or business operations which may result in some adverse impact to revenue and/or schedule. Project Sponsor Within one business day
Priority 3 Slight impact which may cause some minor scheduling difficulties with the project but no impact to business operations or revenue. Project Manager Within two business days
Priority 4 Insignificant impact to project but there may be a better solution. Project Manager Work continues and any recommendations are submitted via the project change control process
** NOTE: Any communication including sensitive and/or confidential information will require escalation to VP level or higher for approval prior to external distribution.

Glossary of Communication Terminology

Term Definition
Communication The effective sending and receiving of information. Ideally, the information received should match the information sent. It is the responsibility of the sender to ensure this takes place.
Stakeholder Individuals or groups involved in the project or whose interests may be affected by the project’s execution or outcome.
Communications Management Plan Portion of the overall Project Management Plan which details how project communications will be conducted, who will participate in communications, frequency of communications, and methods of communications.
Escalation The process which details how conflicts and issues will be passed up the management chain for resolution as well as the timeframe to achieve resolution.

Sunday, April 6, 2014

Quality Metrics template

Quality Metrics
It is an output from Plan Quality Management process.

QUALITY METRICS TEMPLATE

Introduction

Quality metrics are a key component of an effective quality management plan and are the measurements used in ensuring customers receive acceptable products or deliverables. Quality metrics are used to directly translate customer needs into acceptable performance measures in both products and processes. Project managers must be able to assess the progress, efficiency, and performance of their projects and metrics are the means which allow project managers to do this. However, it is important to note that metrics must be established in an effort to directly improve the product or processes involved in the project. They must be attributable to an established goal, threshold, or customer requirement or else they provide no value. ABC Corporation has approved the Beta Tool project which requires the design, building, testing of the Beta Tool to be used with Argo Tooling Company’s proprietary fastening device CamBolt. In accordance with the Beta Tool Quality Management Plan, ABC Corp. will use various metrics in order to ensure efficient processes are established and that the product meets the customer requirements for delivery. All metrics have been reviewed and approved by internal executive leadership and project sponsor as well as the customer, Argo Tooling Co.

Metrics

This section should list the quality metrics chosen for this project and a description of each. These descriptions should include an explanation of how the metric applies to the quality of the product or process it is being used to measure. Additionally, any thresholds or limits should be clearly stated in this section. Metrics should always be clear, measurable, controllable, and reportable.

Based on customer product requirements, internal process standards, and applicable industry standards, the following metrics have been established for the Beta Tool Project. These metrics have been reviewed and approved internally and with the customer, Argo Tooling Co.:
a. Tensile Strength: The Beta Tool will be used in various industrial environments under high material stress loads. Based on anticipated customer usage and industry tooling standards, it has been determined that the tensile strength of the Beta Tool must meet or exceed 500 mega-pascals (MPa). Tensile strength will be measured for each prototype of ABC Corp.’s tensile bench. The results will be verified by ABC Corp.’s Material Testing Manager and presented to stakeholders in the monthly Beta Tool Quality Management Review.
b. Shear Strength: The Beta Tool will be subject to potentially high stress torque loads in various applications. Based on anticipated customer usage and industry tooling standards, it has been determined that the shear strength of the Beta Tool must meet or exceed 375 MPa. Shear strength will be measured for each prototype on ABC Corp.’s shear stress bench. The results will be verified by ABC Corp.’s Material Testing Manager and presented to stakeholders in the monthly Beta Tool Quality Management Review.
c. Customer Satisfaction: The Beta Tool is being developed for usage by Argo Tooling Co. technicians. Each prototype will be tested by a panel of Argo technicians on various criteria. Argo technicians will be asked to rate the Beta Tool on a scale of 1 to 10 for each criteria. The scores will then be calculated to determine a total average score. Customer satisfaction much be greater than or equal to 8 out of 10 for each criteria with no individual score lower than a 7. ABC Corp. will then solicit feedback from Argo technicians on areas for improvement.
1) Customer Satisfaction Criteria: Comfort, Ergonomic Functionality, Adjustability, Aesthetics, Size, Dexterity
d. Material Scrap: In order to minimize costs and reduce waste, ABC Corp. has internally established metrics for measuring and controlling material scrap for its tool manufacturing efforts. The Beta Tool Project will be subject to internal guidelines regarding material scrap. The Beta Tool manufacturing process must result in material waste below 1% of the total material used in the manufacturing of one tool. Waste is defined as material that cannot be re-used or re-allocated for another purpose. Waste will be calculated for each prototype. No manufacturing process will be approved unless it yields less than 1% of waste material per unit manufactured. Only once this has been achieved will the process be approved for operations.
e. Product Defect Rate: In order to minimize costs, reduce waste, and achieve consistent quality, ABC Corp. has internally established metrics for measuring and controlling product defects. The Beta Tool Project will be subject to internal guidelines regarding product defects. The approved manufacturing process must be repeatable, produce a Beta Tool product which meets previous quality metrics, and incurs a defect rate less than one item per every five hundred. Product defects result in wasted costs for manufacturing personnel and equipment, material waste, and re-work. In order to minimize the impact of these costs all Beta Tools will be measured against approved specifications and metrics. Each tool must conform to the metrics herein while also meeting product specifications within the allowable tolerances contained in the project scope.
Metric Standard Frequency Report
Tensile Strength >=500MPa Per prototype Monthly Quality Management Review (QMR)
Shear Strength >=375 MPa Per prototype Monthly QMR
Customer Satisfaction 8/10 or higher with no individual scor below 7 Per prototype Monthly QMR
Material Waste <1% based on total material used per tool Per prototype Monthly QMR
Product Defect Rate <1 out of 500 Per production of 500 totals As achieved

Metrics Measurement and Data Collection

This section should describe in detail how quality metrics measurements will be taken and what will be done with the data. These measurements are key to the success of the product and project and there must be clear documentation on how the data will be used.
As each Beta Tool prototype is completed the project’s quality manager will measure the tool against the customer specifications contained in the project scope. These specifications pertain to the specific dimensions of the tool and its total weight. The quality manager will ensure that the prototype falls within the allowable specification tolerances and document the findings on the quality inspection form contained in the Project Quality Management Plan. Additionally, the manufacturing line manager and Project Manager will calculate material waste by determining the percentage of waste as compared to the total amount of material used for the tool. The Project Manager will document these findings and consolidate them to present at the Quality Management Review.
Once the tool is determined to meet the customer specifications, it will be submitted to the Argo Technical Manager where Argo technicians will test the tool for 2 days. Upon completion of testing the Argo Technical Manager will return the tool to the ABC Project Manager along with the completed customer satisfaction forms contained in the Project Quality Management Plan.
Once the tool is determined to meet customer satisfaction requirements the Project Manager will submit the tool to the Materials Testing Manager where it will undergo tensile and shear strength tests in the Material Lab. The Materials Testing Manager and Project Manager will verify and document all findings and consolidate the data for presentation at the Quality Management Review.
Once all measurements are completed for each prototype, the Project Manager, Quality Manager, and Project Team will meet to review and compile data and develop their recommendations based on the findings. If any of the metrics have not been satisfied, the Project Manager will include recommendations for correcting the metric in the Quality Management Review. This may be a small change to a process parameter or consist of a larger scale process or product quality improvement initiative.

Quality Management Review

This section of the Quality Metrics document includes a description of what will be included in the Quality Management Review as well as the frequency of the meetings and who will participate. Some of this information may also be included in the Quality and Communications Management Plans.
The Beta Tool Quality Management Reviews (QMRs)will be scheduled on a monthly basis throughout the project lifecycle. The Project Manager is responsible for scheduling the meetings and ensuring a room is reserved as well as all necessary audio/visual support. The Project Manager is also responsible for ensuring all required attendees are notified in advance of the meeting.
Required attendees include the Beta Tool Project Team, ABC Corp. Materials Testing Manager, ABC Corp. Quality Manager, Beta Tool Project Sponsor, ABC Corp. Manufacturing Manager, Argo Co. Technical Manager, and Argo Co. Customer Representative. Other stakeholders may be invited at the Project Manager’s discretion.
The QMR will consist of a presentation of all quality metrics and specifications measurements and a comparison to previous prototype iterations to show progress. Cumulative data will also be presented to provide a status of process and product repeatability. For any metrics which did not meet the established standards, the Project Manager will present recommended course(s) of action to correct the fault(s). The Project Sponsor is the approving authority for implementation of any recommended course of action or corrective measures.
Based on the QMR results and corrective measures, the Project Manager is responsible for updating all project documentation, submitting any changes through the change control process, and communicating changes to all stakeholders.

Saturday, March 15, 2014

Scope statement template

Project Scope Statement Template

Project Scope Statement Sample Partially Completed Template

Download the Microsoft Word version
Project Name:  Employee Portal
Project Number:
EEPO 0010
Project Manager:
 Alice Johnston
Date:
May 4, 20xx
Business case
As the company grows, the number of individuals working virtually has increased to over 150 in the past year and a half.  Additionally, virtual workers may only come into the office on average twice a month for meetings with others.  Access is needed to employee paperwork, forms, and other documentation, along with the ability to communicate and share information between employee and manager. 
Objectives
Develop an employee portal to:
  • Access various HR forms and other documentation relevant to the organization
  • Provide a way to share information between employee and manager
  • Provide a forum for employees to share information and communicate with each other
  • Access to training/development plans and progress against those plans
  • Access to performance review information

Scope description
 The employee portal should be developed using technology already in use within the company – Microsoft SharePoint.  The portal in phase 1 should provide access to all employees, but be segmented depending on employee role within the organization.   The portal should provide access to the information documented above in the “Objectives” section.
Acceptance criteria
Phase 1 of project is complete when portal contains the components noted above and access has been provided to all employees, with access level dependent on employee role.
Deliverables
Microsoft SharePoint portal for use by all company employees.
Exclusions
Any additional components of the portal are out of scope for this project, but will be included in a list of objectives for Phase 2 of project, to be completed within 1 year of rollout of Phase 1.
Constraints
Application development resources are currently involved in the roll out of 2 other initiatives and will not be able to devote 100% of time to this project until after 4 – 6 months of the start.

Assumptions
Application development resources are well versed in Microsoft SharePoint.
The use of Microsoft SharePoint as a portal can meet the objectives of the organization, and allow for growth in the future.
Milestones
Date
Requirements gathering
June
Phase 1 development
July – Sept
Phase 1 testing
October
Phase 1 complete
November
Pilot group rollout
Dec – Feb
Incorporate changes/recommendations of pilot group
Feb – March
Organization wide rollout
March – April
Training in application
March – April
Project Budget
Estimated at $75,000 – $150,000
Project Risks
Training offshore team