Project Management in its conventional form is a temporary endeavour undertaken to create a unique product, service, or result (Schwalbe, 2010,

p4), that has a clear start position, and will end when a defined objective has been achieved (unless of course the project is stopped). In summary it is a focused piece of work against a defined, clear, and achievable deliverable . Organisations will define standards, structures, and policies for how projects should be conducted, a fundamental part of which will be the production of a business case at the initial identification stage of the project to demonstrate to sponsors that the activity has value to the organisation. An important aspect of the business case is an options appraisal to present reasoned arguments for the direction for change proposed by the project. A weighted decision matrix is a mechanism to assist with a logical approach to options appraisal, and provides evidence based means to either narrow selection and/or provide a recommended approach. This methodology will establish a list of weighted criteria and then evaluates each option against those criteria (Tague, 2004, p219-223). The conceptual approach is one that can be applied to any aspect of business activity, from defining routes for laying gas pipes through to selecting new product lines, and is summarised by Bitman & Sharif (2008), where they outline the use of a decision matrix for ranking R&D project activity to ensure that it makes optimal use of limited resources available to improve the firms competitive advantage . When a project is approved, there are many tools and techniques that can be used to build High performing teams that use structured approaches to deliver success. Techniques such as Belbin (Belbin associates, nd) or Meyers-Briggs Type Indicators to obtain the right number and mix of social styles aligned against the skilled resources required, following talent management disciplines to develop technical, managerial/business or social skill gaps, running team building activities, and the use of the organisations reward framework to generate a performance and targets based culture as outlined by Herzbergs hygiene factors and motivators (Schwable, 2010, p346). Tools that can be used to support the project team include; the project plan, maintaining decision/risk/issue logs, producing detailed work briefs to support activities listed within the work breakdown structure, identifying and measuring metrics that define success criteria e.g. number of machines upgraded, customer satisfaction ratings, product build costs, conducting regular structured team meetings where actions are documented, ensuring the right people are available at the right time through analysing resource loading, and performing resource levelling (Schwable, 2010, p360-362).

These tools provide the information required for governance of the project, both internally within the project team, and externally to the project board, the sponsors who will make the business decisions that ensure the expected benefits are achieved within acceptable cost and time parameters. A project manager needs to be leader, a manager, and a monitor in order to deliver against the project schedule. Monitors can track what's being done, Managers can contribute to how it's being done, but a Leader understands deeply why it's being done and can change up the game when needed to win (Miller, nd). Through impact analysis, the effect of any

scenario can be managed, and the tools a PM has available to support them with this analysis are: Work breakdown structure: to make the necessary modifications to accommodate delays or changes to the project, and to change the estimates on task completion dates. PERT Chart & task activity network map: to gauge the impact of task schedules being changed. Critical path: to validate the impact of change on individual tasks against the overall project schedule. Resource loading and resource levelling: to validate staff are not over committed, and adjusting the scheduling of lower priority tasks to favour tasks on the critical path where possible.

Appendix 1 outlines in detail these tools, taken from the Project Managers Book of Knowledge, an international framework for project management that is very popular within the USA. By defining relevant criteria, understanding the risks and potential impact, and weighting the aspects that are most important to the project, It helps the business because it provides an objective fact based means in which to support a proposed solution, and the supporting sub components that make up that solution design. Specifically it will deliver the following benefits: Provides the reasoning behind why the decisions have been made. Aligns the decision with business priorities, and other factors like organisational readiness, technical compatibility, legal compliance, and affordability. Each option is evaluated on its own merits. The decision is logic rather than emotion or perception based. Delivery is broken down into achievable manageable and measurable steps. Provides a mechanism for rationally considering the approach in a balanced fashion as outlined by the project scope triangle (Jenkins, 2010).

Enterprise Project Management, which is also known as project portfolio management or transition management according to Scwable (2010, p21) integrates information from multiple projects to show is the ability to take an show the states of active, approved, and future projects across an entire organisation where the projects are prioritised, resourced, and delivered against the vision, objectives, and ambitions of the enterprise in order to compete and grow the organisation.

Whilst there are similarities between Project Management & Enterprise Project Management in that they both apply structure and discipline to managing the delivery of defined objectives, they are significantly different in relation to scale and viewpoint of the deliverables. For example, conceptually they may both invoke management rights to descope activity, this would translate to the removal of a work breakdown structure for a project, but could mean the stopping of an entire project for EPM. An individual project is only one part of larger programme and portfolio plans, so the success of a single project becomes a milestone achieved on the big picture, and the lessons learnt from achieving that progress needs to feed into and contribute to the success of other active and future projects. This feeds into the vision and goals of an organisation where; The senior management board will set the overarching direction of the company, and communicate the high level vision, aims, and objections of the organisation. Individual business units will develop their own plans for how their part of the organisation will support the achievement of this vision. Delivery of the business plans are broken down into a number of project programmes, that are grouped into logical portfolios for reporting purposes and simplicity of understanding the big picture Project programmes are achieved through a number of individual projects.

Individual projects are small manageable pieces of work that can be traced back to the overarching organisation vision, but in a way that simplifies the definition of the big picture and allows dependencies, prioritisation, and delivery to be managed. Stakeholder analysis defines who is associated and involved with the project, from the senior decision makers, through to supporting suppliers, the team that will deliver the project, and the users and customers of the system. A stakeholder map will define the stakeholder groups and their area of interest. These stakeholders can then be represented through RACI a RACI matrix to define their role against key aspects of the project, programme, or portfolio, which in turn will identify who needs to be contacted as part of the stakeholder engagement plan, either to gather information for planning, to inform on progress, or to seek approval and make decisions. The main purpose of this is to manage expectations, where each group will have their own specific needs that will need to be satisfied. Appendix 2 provides some examples outputs related to these expectations, which can be summarised as: The expectations management matrix; stakeholder views on scope, cost, timing, quality, etc.. Project Charter; the scope of the project and the roles and responsibilities of the actors involved in its delivery.

Milestone report; a progress update report Client acceptance form; sign off with the sponsor that the delivered product meets its defined requirements.

Communication is the main means to manage these expectations, and stakeholder analysis will define all the relevant parties that need to be informed about the project, and through establishing knowledge on their background will inform on the types of communications that are required, the language and tone of that communication, the timing of the communication, and its importance. This knowledge enables the communication strategy to be formulated, and will inform on what supporting tools are required such as the glossary of terms, or the use of standards like plain English (Plain Language Commission, nd). A communication management plan will address 8 areas, namely; 1. Stakeholder communication requirements; what the stakeholders need to be informed about. 2. The information to be communicated; what is to be produced and by understanding the audience, ensuring the language and medium used is commensurate to the intended audience, 3. Clarity on who are the Creators & Readers of the information. 4. What delivery mechanism will be used; e-mail, web sites, by phone, presentations, written letters, multimedia,.. 5. Frequency of communications; one off events or regular updates, and when to communicate. 6. Governance and feedback; management of the plan, obtaining feedback from communications. 7. Maintaining the communication plan; the ability to review and continually improve the plan itself and the communication needs for stakeholders. 8. Glossary of Terms; explaining the use of technology terms and acronyms. Another important tool that will accompany the communication strategy is the change management strategy which covers business process adjustments, training needs, and cultural changes associated with the project. The final aspect is project termination planning, the process that will engage with the stakeholders and customer to agree sign off, and to bring the project to an orderly conclusion, disbanding the team and handing over any ongoing responsibility to the appointed support groups (Schwable, 2010, p114). The benefit of knowing where the finish line is, is that it provides a target for the team to focus on, and reasons for celebrating success when you get there. The nature of this activity will differ significantly depending on whether the project was successful or unsuccessful, however the process is predominantly the same, namely:-

a. Client Acceptance form signed by the project sponsor (to accept the project, or to sign off the abandonment and agree what alternative approach if any will be taken to address the original business need). If it is too early to see that the intended benefits have been realised, then timescales and actions for validating this need to be agreed. Client and user satisfaction should be obtained at this stage. b. Lessons learnt report and subsequent additions to the organisations continual improvement plan. c. Final project documentation (operational handover, configuration management updates, budget closure, procurement closure) d. Celebrating success (hopefully!), and project disbandment.

Everyone involved with the project is a potential ambassador for the project, and as such they should be fully aware of the communications plan and adhere to the messages it will deliver.

References Belbin Associates. nd. Belbin team roles [online] http://www.belbin.com/rte.asp?id=3 [accessed 28/08/2012] Bitman, R & Sharis, N. 2008 A conceptual framework for ranking R&D projects , IEEE transactions on engineering management vol 55, no2, May2008, p267-269. http://ieeexplore.ieee.org.ezproxy.liv.ac.uk/stamp/stamp.jsp?tp=&arnumber=4494724 [accessed 17/08/2012]
Jenkins, N. 2010 A project management primer: Basic principles scope triangle [online] http://www.projectsmart.co.uk/project-management-scope-triangle.html [accessed 16/08/2012]

Milner, K. nd Project leader, manager, or monitor [online] http://www.projectsmart.co.uk/projectleader-manager-or-monitor.html [accessed 21/08/2012] Plain Language Commission, nd. Accredition with the clear English standard [online] http://www.clearest.co.uk/?id=28 [accessed 14/08/2012]
Schwalbe, Kathy. (2010). Managing Information Technology Projects, sixth edition, Canada:Course Technology Cengage Learning

Tague, N. (2004) The Quality toolbox, Second edition, ASQ Quality Press

Appendix 1: Tools to support Project Managers

Project Management process groups and knowledge area mapping:

Knowledge Area Processes Initiating Process Group

Project Management Process Groups Planning Process Group Executing Process Group Monitoring and Controlling Process Group Closing Process Group

Project Management Integration

Develop Project Charter

Develop Project Management Plan

Direct and Manage Project Execution

Monitor and Control Project Work

Close Project

Develop Preliminary Project Scope Statement

Integrated Change Control

Project Scope Management

Scope Planning

Scope Verification

Scope Definition Scope Control Scope WBS

Project Time Management

Activity Definition

Schedule Control

Activity Sequencing

Activity Resource Estimating

Activity Duration

Estimation

Schedule Development

Project Cost Management

Cost Estimating

Cost Control

Cost Budgeting

Project Quality Management

Quality Planning

Perform Quality Assurance

Perform Quality Control

Project Human Resources Management

Human Resources Planning

Acquire Project Team

Manage Project Team

Develop Project Team

Project Communication Management

Communications Planning

Information Distribution

Performance Reporting

Manage Stakeholders

Project Procurement Planning

Plan Purchase and Acquisitions

Request Seller Responses

Contract Administration

Contract Closure

Plan Contracting Select Sellers

Project Risk

Risk

Risk

Management

Management Planning

Monitoring and Control

Risk Identification

Qualitative Risk Analysis

Quantitative Risk Analysis

Risk Response Planning

Monitoring and controlling Processes Outputs:

PMBOK Guide Fourth Edition TEMPLATES

Included in this section are templates from the Project Management Institute, aligned with the PMBOK Guide Fourth Edition and modified for the Oregon Department of Human Services. The templates can be viewed with Microsoft Word and Excel, and can be modified to your specific projects needs.

The forms are arranged sequentially as they appear in the PMBOK Guide Fourth Edition. A blank copy of the template and a guide with a description of the information that goes into

each field is presented. For more information on the form, please consult the PMBOK Guide Fourth Edition. INITIATING FORMS

1.01 Project Charter The Project Charter is a document that formally authorizes a project or phase. The Project Charter defines the reason for the project and assigns a project manager and his or her authority level for the project. (Template) (Guide)

1.02 Stakeholder Register The Stakeholder Register is used to identify those people and organizations impacted by the project and document relevant information about each stakeholder. (Template) (Guide)

1.03 Stakeholder Analysis Matrix The Stakeholder Analysis Matrix is used to categorize stakeholders. It can be used to help fill in the Stakeholder Register. The categories of stakeholders can also assist in developing stakeholder management strategies that can be used for groups of stakeholders. (Template) (Guide)

1.04 Stakeholder Management Stakeholder Management Strategy documents stakeholders and their influence on the project and analyzes the impact that they can have on the project. It is also used to document potential strategies to increase stakeholders positive influence and minimize potential disruptive influence on the project. (Template) (Guide)

PLANNING FORMS

2.01 Requirements Documentation Requirements documentation includes requirements, categories, stakeholders associated with requirements and acceptance criteria. This documentation assists the project manager in making trade-off decisions among requirements and in managing stakeholder expectations. (Template) (Guide)

2.02 Requirements Management Plan The Requirements Management Plan is part of the Project Management Plan. It specifies how requirements will be managed throughout the project. (Template) (Guide)

2.03 Requirements Traceability Matrix A Requirements Traceability Matrix is used to track the various attributes of requirements throughout the project life cycle. It uses information from the Requirements Documentation and traces how those requirements are addressed throughout the project. (Template) (Guide)

2.03a Requirements Inter-Traceability Matrix A Requirements Inter-Traceability Matrix traces the relationship between categories of requirements. (Template) (Guide)

2.04 Project Scope Statement The Project Scope Statement is used to define, develop, and constrain the project and product scope. (Template) (Guide)

2.05 Assumption and Constraint Log The Assumption and Constraint Log can be incorporated into the Project Scope Statement or it can be a stand-alone document. This log is a dynamic document since assumptions are progressively elaborated throughout the project. (Template) (Guide)

2.06 Work Breakdown Structure (WBS) Diagram The WBS is used to decompose all the work of the project. It begins at the project level and is successively broken down into finer levels of detail. The lowest level is a work package. (Graphic) (Outline)

2.07 WBS Dictionary The WBS Dictionary supports the Work Breakdown Structure (WBS) by providing detail about the work packages and control accounts it contains. The dictionary can provide detailed information about each work package or summary information at the control account level and work package levels. (Template) (Guide)

2.08 Activity List The Activity List identifies all the activities necessary to complete the project work. It also describes the work in sufficient detail so that the person performing the work understands the requirements necessary to complete it correctly. (Template) (Guide)

2.09 Activity Attributes Activity Attributes are details about an activity. Sometimes the information is entered directly into the schedule software. Other times the information is collected in a form that can be used later to assist in building the schedule model. (Template) (Guide)

2.10 Milestone List The Milestone List defines all the project milestones and describes the nature of each one. It may categorize the milestone as optional or mandatory, internal or external, interim or final, or in any other way that supports the needs of the project. (Template) (Guide)

2.11 Network Diagram The Network Diagram is a visual display of the relationship between schedule elements. It can be produced at the activity level, the deliverable lever, or the milestone level. The purpose is to visually depict the types of relationships between elements. (PDF example)

2.12 Activity Resource Requirements Activity Resource Requirements describe the type and quantity of resources needed to complete the project work. (Template) (Guide)

2.13 Resource Breakdown Structure Outline

The Resource Breakdown Structure is a hierarchical structure used to organize the resources by type and category. It can be shown as a hierarchical chart or as an outline. (Outline only)

2.14 Activity Duration Estimates Activity Duration Estimates provide information on the amount of time it will take to complete project work. (Template) (Guide)

2.15 Duration Estimating Worksheet A Duration Estimating Worksheet can help to develop duration estimates when quantitative methods are used. (Template) (Guide)

2.16 Project Schedule Sample The Project Schedule combines the information form the Activity List, Network Diagram, Activity Resource Requirements, Activity Duration Estimates and any other relevant information to determine the start and finish dates for project activities. (Sample Gantt Chart)

2.17 Activity Cost Estimates Activity Cost Estimates provide information on the resources necessary to complete project work, including labor, equipment, supplies, services, facilities, and material. (Template) (Guide)

2.18 Cost Estimating Worksheet A Cost Estimating Worksheet can help to develop cost estimates when quantitative methods or bottom-up estimates are developed. (Template) (Guide)

2.18a Bottom-Up Cost Estimating Worksheet Bottom-up estimates are detailed estimates done at the work-package level. (Template) (Guide)

2.19 Cost Performance Baseline

The Cost Performance Baseline is a time-phased budget that is used to measure, monitor, and control cost performance for the project. (Example only)

2.20 Quality Management Plan The Quality Management Plan is a component of the Project Management Plan. It describes how quality requirements for the project will be met. (Template) (Guide)

2.21 Quality Metrics Quality Metrics provide detailed specific measurements about a project, product, service, or result and how it should be measured. (Template) (Guide)

2.22 Process Improvement Plan The Process Improvement Plan is a component of the Project Management Plan. It describes the approach to selecting and analyzing work processes that can be improved. (Template) (Guide)

2.23 Responsibility Assignment Matrix (RAM) The RAM shows the intersection of work packages and resources. Generally RAMs are used to show the different levels of participation on a work package by various team members, but they can also show equipment and materials can be used on work packages. (Example only)

2.24 Roles and Responsibilities Roles and Responsibilities describe the attributes of a position on the project team. (Template) (Guide)

2.25 Human Resource Plan The Human Resource Plan is part of the Project Management Plan. It describes how all aspects of human resources should be addressed.

(Template) (Guide)

2.26 Communications Management Plan The Communications Management Plan is a component of the Project Management Plan. It describes the communications needs of the project including audiences, messages, methods, and other relevant information. (Template) (Guide)

2.27 Risk Management Plan The Risk Management Plan is a component of the Project Management Plan. It describes the approach for managing uncertainty, both threats and opportunities, for the project. (Template) (Guide)

2.28 Risk Register The Risk Register is used to track information about identified risks over the course of the project. (Template) (Guide)

2.29 Probability and Impact Assessment The Probability and Impact Assessment contains narrative descriptions of the likelihood of events occurring and the impact on the various project objectives if they do occur. (Template) (Guide)

2.30 Probability and Impact Matrix The Probability and Impact Matrix is a table that is used to plot each risk after performing a risk assessment. The Probability and Impact Assessment determines the probability and impact of the risk. This matrix provides a helpful way to look at the various risks on the project and prioritize them for responses. (Template)

2.31 Risk Data Sheet

A Risk Data Sheet contains information about a specific identified risk. The information is filled in from the Risk Register and updated with more detailed information. (Template) (Guide)

2.32 Procurement Management Plan The Procurement Management Plan is a component of the Project Management Plan. It describes how all aspects of procurement will be managed. (Template) (Guide)

2.33 Source Selection Criteria The Source Selection Criteria is used to determine and rate the criteria that will be used to evaluate bid proposals. (Template) (Guide)

2.34 Project Management Plan The Project Management Plan describes how the team will execute, monitor, control, and close the project. It can be a summary level plan or have many detailed components. (Template) (Guide)

2.35 Configuration Management Plan The Configuration Management Plan is a component of the Project Management Plan. It describes how functional and physical attributes of products will be controlled on the project. It may or may not be aligned with a Change Management Plan. (Template) (Guide)

3.36 Change Management Plan The Change Management Plan is a component of the Project Management Plan. It describes how change will be managed on the project. It may or may not be part of a Configuration Management Plan. (Template) (Guide)

EXECUTING FORMS

3.01 Team Member Status Report The Team Member Status Report is filled out by team members and submitted to the project manager on a regular basis. It tracks schedule and cost status for the current reporting

period and provides planned information for the next reporting period. Status reports also identify new risks and issues that have arisen in the current reporting period. (Template) (Guide)

3.02 Change Request A Change Request is used to change any aspect of the project. It can pertain to project, product, documents, requirements, or any other aspect of the project. Upon completion, it is submitted to the change control board or other similar body for review. (Template) (Guide)

3.03 Change Log The Change Log is a dynamic document that is kept throughout the project. It is used to track changes from request through final disposition. (Template) (Guide)

3.04 Decision Log The Decision Log is a dynamic document that is kept throughout the project. Frequently there are alternatives in developing a product or managing a project. Using a Decision Log can help keep track of the decisions that were made, who made them, and when they were made. (Template) (Guide)

3.05 Quality Audit A Quality Audit is a technique that employs a structured, independent review to project and/or product elements. Any aspect of the project or product can be audited. (Template) (Guide)

3.06 Team Directory The Team Directory lists the project team members and their primary contact information. It is particularly useful on virtual teams when team members often have not met one another and may work in different time zones. (Template) (Guide)

3.07 Team Operating Agreement The Team Operating Agreement is used to establish ground rules and guidelines for the team. It is particularly useful on virtual teams and teams that are comprised of members from different organizations. (Template) (Guide)

3.08 Team Performance Assessment The Team Performance Assessment is used to review technical performance and interpersonal competencies of the team as a whole. It also addresses team morale and areas for team performance improvement. (Template) (Guide)

3.09 Team Member Performance Assessment The Team Member Performance Assessment is used to review technical performance, interpersonal competencies, and strengths and weaknesses of individual team members. (Template) (Guide)

3.10 Issue Log The Issue Log is a dynamic document that is kept throughout the project. An issue is a point or matter in question or in dispute, one that is not settled and is under discussion, or one over which there are opposing views or disagreements. (Template) (Guide)

MONITORING AND CONTROLLING FORMS

4.01 Project Performance Report The Project Performance Report is filled out by the project manager and submitted on a regular basis to the sponsor, project portfolio management group, Project Management Office or other project oversight person or group. (Template) (Guide)

4.02 Variance Analysis Variance Analysis reports collect and assembles information on project performance variance. Common topics are schedule, cost, and quality variances. (Template) (Guide)

4.03 Earned Value Analysis An Earned Value Status report shows specific mathematical metrics that are designed to reflect the health of the project by integrating scope, schedule, and cost information.

Information can be reported for the current reporting period and on a cumulative basis. (Template) (Guide)

4.04 Risk Audit Risk Audits are used to evaluate the effectiveness of the risk identification, risk responses, and risk management process as a whole. (Template) (Guide)

4.05 Contractor Status Report The Contractor Status Report is filled out by the contractor and submitted on a regular basis to the project manager. It tracks status for the current reporting period and provides forecasts for future reporting periods. The report also gathers information on new risks, disputes, and issues. (Template) (Guide)

4.06 Product Acceptance The Product Acceptance form records the requirements and the method of verification and validation. It is used to document acceptance by the customer or other stakeholder. (Template) (Guide)

CLOSING FORMS

5.01 Procurement Audit The Procurement Audit is a structured review of the procurement process. Information in the audit can be used to improve the process and results on the current procurement or on other contracts. (Template) (Guide)

5.02 Contract Close-out Contract Close-out involves documenting the vendor performance so that the information can used to evaluate the vendor for future work. Additionally, information from the Contractor Status Report can be used when collecting information for Lessons Learned.

(Template) (Guide)

5.03 Project Close-out Project Close-out involves documenting the final project performance as compared to the project objectives. The objectives from the Project Charter are reviewed and evidence of meeting them is documented. If an objective was not met, or if there is a variance, that is documented as well. (Template) (Guide)

5.04 Lessons Learned Lessons Learned can be compiled throughout the project or at specific intervals, such as the end of a life cycle phase. The purpose of gathering Lessons Learned is to identify those things that the project team did that worked very well and should be passed along to other project teams and to identify those things that should be improved for future project work. (Template) (Guide)

Appendix 2: Sample Stakeholder forms

Expectations Management Matrix

Prepared by: Date:

Measure of Success Scope Time Cost Quality

Priority

Expectations

Guidelines

Customer Satisfaction Financial Impact

Project Charter
Project Title: Project Start Date: Budget Information: Projected Finish Date:

Project Manager: Name, phone, e-mail Project Objectives:

Approach:

Roles and Responsibilities Role Name Organization/ Position Contact Information

Sign-off: (Signatures of all above stakeholders. Can sign by their names in table above.)

Comments: (Handwritten or typed comments from above stakeholders, if applicable)

Milestone Report for Project Name

Prepared by: Date:

Milestone

Date

Status

Responsible

Issues/Comments

Client Acceptance/Project Completion Form

Project Name: Project Manager: ________________________________________________ ________________________________________________

I (We), the undersigned, acknowledge and accept delivery of the work completed for this project on behalf of our organization. My (Our) signature(s) attest to my (our) agreement that this project has been completed. No further work should be done on this project.

Name

Title

Signature

Date

1. Was this project completed to your satisfaction?

Yes

No

2. Please provide the main reasons for your satisfaction or dissatisfaction with this project.

3. Please provide suggestions on how our organization could improve its project delivery capability in the future.

Thank you for your inputs.