Overview of Projects

Projects represent a collaborative enterprise involving multiple disciplines that are carefully planned to achieve a particular aim. PPMAnywhere supports the disciplines involved in effectively managing projects including task management, resource management, financial management, risk management, issue management, change management, deliverables management and governance.

• The project entity in PPMAnywhere provides a defined workflow for governance throughout its lifecycle and a central connection point for financials, resourcing, planning, management of controls and reporting.

• Project data is customizable to fit both simple and complex methodologies. All project data is audited and tracked so the full history is available and traceable.

• Projects can be viewed by navigating to the Projects page This page is also available from the flydown menu under the ‘Portfolio’ category.

• Projects can be created by navigating to the Projects page and clicking on the ‘+’ button. This page is also available from the flydown menu under the ‘Portfolios’ category.

• Projects can also be created as an outcome of the proposal/business case process. Proposals are created from the ­Proposals page. An overview of proposals can be found here.

• When creating a project, a project type must be selected. This cannot be changed once the project is created.

• All projects are associated with a particular project type. The type defines the behaviour of the project including how task planning is done and what the governance process is.

• An example of different project types are Waterfall, Agile, Lean, Scrum, Kanban

• Project types are set up and managed by an Administrator, through the Project Types page.

• A project’s type cannot be changed after it is created.

• Projects can be initiated from a proposal. This ensures that projects are created in response to a defined and approved business case. In such cases, data that is common to both the proposal and the project is copied across.

• Projects can result in the creation of a service. For example, a project might involve delivery of a new HR solution. Once implemented the project closes and the new solution is defined as a service to satisfy ongoing management. The service entity is used to manage the lifecycle of the service, including many of the disciplines from project management such as risk, issue, and scope change management as well as financial and benefits tracking.

• Projects can be associated with a programme which, along with other projects delivers a larger scope with larger objectives.

• Projects can be associated with a portfolio, which provides aggregated reporting of financial metrics as well as an escalation path for risk, issue, and scope change management.

• Reporting project status to stakeholders is an integral part of any project management discipline.

• To create a status report, navigate to the Projects page and click on a project to open the overview page.

• For those who have rights to create a status report for a project there will be a ‘Create Status Report’ icon to the top right of the page.

• The status report process takes the submitter through a series of stages to create the report. During these stages it is possible to make updates to the project prior to submission. This approach helps to ensure that all the project data is up to date prior to publishing of the report.

• The status report can also capture free-text commentary prior to publishing.

• Once submitted the report acts as a snapshot of the project and can be exported to PowerPoint and PDF to support sharing with stakeholders.

• Multiple status reports can be submitted for the same period. Where there is reporting of data based on the last status report, for example project financial analysis or project health, the data will be based on the most recently created report for the previous period.

• The project’s overall health is determined by the latest project Status Report that has been published. 

• To view the health of a project, navigate to the Projects page and click on a project to view the Project Overview page.

• The ‘Health’ content area in the Project Overview shows the health from the most recent status report.

• To see all reports for the project, click on the drill-down arrow in the ‘Health’ content area.

• Project task management can be achieved in a number of ways:

  • Task Work Breakdown Structure (WBS): This allows the creation of project plans in a more hierarchical and structured way. This includes a definition of duration, effort, predecessors, and constraints. This approach supports integration with Microsoft Project. Plans can be baselined to support reporting against snapshots. This approach is commonly used on ‘Waterfall’ type projects.

  • Task Board: This approach involves a simpler, less detailed, and more fluid approach to planning and an alternative way to visualize the work that needs to be done. Task boards lend themselves to scenarios where the project team meets frequently, and there is a more collaborative style of task planning and tracking. Such an approach is commonly used on ‘Agile’, ‘Scrum’ or ‘Kanban’ type projects.

  • Hybrid: The hybrid approach involves a combination of a task WBS and a task board. For example, an organisation might decide to track only milestones within the task plan but use task boards to track the work required to complete each milestone.

• The project type settings define which of these approaches are used for projects of that type.

• Accessing the task WBS (for projects that include this approach) can be done by drilling down from the ‘Timeline’ content area on the project overview page. Select a project from the ‘Projects’ page to open its overview page.

• Accessing the task board (for projects that include this approach) can be done by drilling down from the ‘Task Progress’ content area on the project overview page. Select a project from the ‘Projects’ page to open its overview page.

• All projects include a financial plan which is used to track budgets, planned and actual costs, and planned and actual benefits.

• Planned labour costs can be derived from the resourcing plan and cost rates (if defined).

• Actual labour costs can be derived from time sheets and cost rates (if defined).

• Financials for a project can be visualized through the financial analysis page. Navigate to the Projects page and click on a project to open the project overview page. Drill-down from the Project Costs content area to analyse project financials in more detail.

• Financials can be updated at any time by those with the authority to do so. This can be on an ad-hoc basis or whilst creating the project status report.

• Financials can be tracked in base currency or in a currency local to the project.

• The standard financial metric reported is that of ‘Estimate At Complete’ (EAC). This is calculated as the sum of future planned cost (current month included) plus the sum of actual cost up to and including the previous month.

• The starting point for accessing and editing the financial plan is the project overview page. Search for and open the project using the method described in Finding and viewing projects to open the project overview page. From this point the financial plan is available via the following options:

• The PM Workbook hero button

• The Project Status Report icon

• The drill-down from the ‘Project Cost’ content area to the project financial analysis page and from here, the icon ‘Edit Financials’

• The ‘Financials option on the actions drop-down menu on the governance page - accessed by drilling down from the ‘Project Summary’ content area.

• All projects include a resource plan which is used to manage the resourcing requirements of the project.

• The resource plan describes the roles required and the effort, expressed in Hours, Days or ‘Full Time Equivalents’ (FTEs).

• The resource plan differs from the task plan in that the latter plans the detail tasks for roles and resources (bottom-up planning) whereas the resource plan is used to ensure the project is adequately resourced to ensure it meets the overall timelines (top-down planning).

• From within the resource plan, it is possible to perform a comparison with the task WBS to ensure the two are broadly aligned, especially for the forthcoming days and weeks.

• The granularity of planning can be days, weeks, months, quarters, and years.

• The resource plan is used as the foundation for resource allocation. The method of allocating resources can be configured according to business process rules. Typically, this follows one of two approaches:

  1. Governed request and allocation process: The Project Manager defines the resourcing requirements and then ‘requests’ allocation by a resource manager or centralised planning team. This is typically used where a project draws on resources from multiple teams.

  2. PM based allocation process: Typically, this is used where managers of teams also manage their workload as projects. In this scenario, the manager of the project is able to define the roles required from their team and also allocate the resources.

• With the use of cost rate rules, it is possible to automate the planning of labour costs using the effort defined in the resource plan.

• With the use of cost rate rules, it is possible to automate the tracking of actual labour costs using the effort reported on time sheets.

• The starting point for accessing and editing the resource plan is the project overview page. Search for and open the project using the method described in Finding and viewing projects to open the project overview page. From this point the resourcing plan is available via the following options:

  1. The PM Workbook hero button

  2. The Project Status Report icon

  3. The drill-down from the ‘Project Team’ content area

  4. The ‘Staffing’ option on the actions drop-down menu on the governance page - accessed by drilling down from the ‘Project Summary’ content area.

• Allocation of resources to the project is performed using the Resource Balancer.

• All projects support the management of risks associated with the project.

• Each risk comprises a form and digitized workflow which defines the lifecycle of the risk.

• Risks are scored according to Impact and Probability. The risks are easily visualized through a heatmap on the project overview page.

• The risk workflow typically includes provision to turn a risk into an issue to cater for the scenario where risks materialize. When converting the risk into an issue, a new issue form is created and form values that are common to both the risk and the issue are copied across to the issue.

• It is possible to escalate risks to programme and portfolio level where the project is part of a programme and/or portfolio.

• To access a project’s risk log, search for and open the project using the method described in Finding and viewing projects to open the project overview page. Then drill down from the risk heatmap content area.

• The risk log can also be updated via the PM Workbook or the Project Status Report.

• All projects support the management of issues associated with the project.

• Each issue comprises a form and digitized workflow which defines the lifecycle of the change.

• Issues can be created as they arise, or they can be created from the risk workflow in the scenario where a risk materializes.

• It is possible to escalate issues to programme and portfolio level where the project is part of a programme and/or portfolio.

• To access a project’s issue log, search for and open the project using the method described in Finding and viewing projects to open the project overview page. Then drill down from the issue content area.

• The issue log can also be updated via the PM Workbook or the Project Status Report. 

• All projects support the management of changes associated with the project.

• Each change comprises a form and digitized workflow which defines the lifecycle of the change. The workflow will typically include an approval stage to sign-off any change in cost and may include steps to baseline the project.

• It is possible to escalate changes to programme and portfolio level where the project is part of a programme and/or portfolio.

• To access a project’s change log, search for and open the project using the method described in Finding and viewing projects to open the project overview page. Then drill down from the ‘Project Change Requests’ content area.

• The change log can also be updated via the PM Workbook or the Project Status Report.

• Projects support the capture of decisions, actions, assumptions, dependencies and lessons learned

• Each of these comprises a form and digitized workflow the defines the lifecycle of the log item. These can be as simple as an open/close action or may include assignment and approval stages.

• The dependency log should not be confused with task dependencies in a task work breakdown structure (WBS). The WBS records dependencies between detailed tasks in the same project or other projects, whilst the dependency log covers higher-level dependencies such as a dependency on suppliers or other 3rd parties.

• Decisions, actions, dependencies, assumptions, and lessons learned can be accessed from the PM Workbook..

• The PM Workbook provides a single location for updating the project on an ad-hoc basis.

• The workbook allows visualization of milestones, editing of risks, issues, scope changes, editing of the resource and financial plan, management of decisions, actions, dependencies, assumptions, and lessons learned as well as tracking of financial and non-financial benefits.

• The project type defines which entities are supported in order to allow organizations to increase their project management maturity over a period of time.

• To access the PM Workbook, search for and open the project using the method described in Finding and viewing projects to open the project overview page The PM workbook will be available as a hero button.

• All projects follow a digitized governance workflow which will typically include one or more approvals or ‘gates’ through which a project must pass during its lifecycle. The complexity of the workflow will vary from organisation to organisation based on its level of project management maturity.

• The project type defines what the governance process is.

• To access a project’s governance page, search for and open the project using the method described in Finding and viewing projects and then drill down from the ‘Project Summary’ content area on the project overview page. Actions available to the user are displayed as buttons to the top right.

• The ‘project team’ defines who manages the project as well as stakeholders, internal approvers and other members of the project who are users of the tool that should have visibility to the project.

• To define the project team, search for and open the project using the method described in Finding and viewing projects. The team is defined in the ‘Project Team’ content area. Click on one of the ‘+’ icons to add someone to the team.

• The list of people defined in the ‘Team’ content area does not define the resource ‘demand’ or who is allocated to the project (which is defined by the resource plan). To access the full resource plan, click on the drill-down from the ‘Project Team’ content area.

• Project outcomes represent the desired results for a project and deliverables are the actions or items that contribute to achieving an outcome.

• To define outcomes and deliverables, search for and open the project using the method described in Finding and viewing projects. Outcomes and deliverables are defined in the ‘Project Outcomes’ content area. Click on one of the ‘+’ icons to add them.

• If linking deliverables to an outcome, start by defining the outcomes first.

• Projects can be integrated with the KPIAnywhere Performance Measurement module to link project activity with the delivery of strategic business objectives and measured through their contribution to Key Performance Indicators (KPIs).

• The link between a project and a business objective is defined by setting the field ‘Business Objective’ on the project form. Business Objectives must first be defined in the KPI module.

• As well as linking the project to a Business Objective, it is possible to define the KPIs which the project contributes towards. This is done using the ‘Key Measures’ table on the project form. KPIs must first be defined in the KPI module.

• To access the project form, search for and open the project using the method described in Finding and viewing projects and then drill down from the ‘Project Summary’ content area on the project overview page.