MONITOR AND CONTROL – SCHEDULE MAINTENANCE

Schedule Maintenance Process Diagram

The below diagram indicates the typical maintenance process for the project plans and program plan.

Collect Work Performance Data

Collecting of Work performance data and Actuals is a key activity for the Schedule Manager.  Regular weekly meetings with project managers and team leaders will be required to develop insight into the progress of activities.

Where possible the collection of data should be via toolsets which are standardized across the organization or supplier organization.  Otherwise a standard approach for marking progress should be provided by the Schedule manager so that different supplier organizations will provide a consistent measure of progress to the program.

 

Consolidate Program Plan

Rolled up work performance data is entered by the Schedule Manager from the Project plans into the Program plan.  Any changes to the remaining work should be incorporated as provided by the project managers into the program plan.

 

Approved changes to Scope, Timelines or Milestones should be added to the program plan as baselined.  Non- approved changes can be added to the plan however the baseline for these activities should not be set.

 

Develop Schedule

Critical path analysis and rescheduling forward of remaining work should be performed.  Any variances to the Baseline should be reviewed with the project managers prior to the development of Variance reports.  Major deviations to the program plan must be discussed with the project manager and/or program director prior to the development of variance reports.

 

Variance reports

Variance reports should be developed directly from the program plan.  The Schedule manager must ensure the reporting data matches exactly to the data provided by the project managers in the project plans and rolled up into the program plan.

 

Any risk’s which have been identified as a result of variances and critical path analysis should be added to the Program risk log.

 

Communication and Reporting

Program status information should be incorporated into Program Communications as per the Communications management plan.  Generally the Schedule Manager will need to develop a “plan on a page’ which is a communication tool to provide stakeholders an indication of the progress of the program

 

PLANNING – QUALITY CONTROL CHECKLIST

All plans in the Program should be reviewed by the Schedule Manager and verified against the quality control checklist and quality control filter checklist.

 

A written report should be provided by the Schedule Manager to the project managers including a summary of the defects to be rectified in the plans.  Quality control reports should be developed for each Baseline of the program plan and project plans.  The Quality control reports can be filed in the project repository in line with the project configuration policy.

 

 

Item	Quality Criteria Description
1	Milestones
1.1	Is there a milestone section at the top of the plan?
1.2	Have all key milestones been included?
1.3	Do Milestone names provide unambiguous and descriptive definition?
1.4	Do dates of milestones match baseline planned dates in PMP?
1.5	Is Milestone name concise enough to appear uncluttered in Rolled up view? Abbreviations should make sense to staff in the organization not working on the project
1.6	Is there an even spread of milestones across the time periods of the project?
2	WBS
2.1	Does the WBS structure align to the project approach, methodology or standard project lifecycle?
2.2	Does the WBS evenly distribute work effort across the phases and through the WBS levels?
2.3	Is there activities or tasks which would be better placed in other WBS elements?
2.4	Do project plans roll up in an effective manner and are broken down into key work products at level 3?
2.5	Do the key Work Products match the PMP deliverables?
3	Scope
3.1	Is the project scope completely represented in the program plan?
3.2	Do individual project plans completely represent the scope in the program plan?
4	Dependencies and Constraints
4.1	Is there a dependencies section at the top of the plan?
4.2	Have all External project dependencies been included?
4.3	Do all External dependencies have a successor project task?
4.4	Constraints should be set only where absolutely necessary. The MPP should be as dynamic as possible through the use of predecessors and successor logic.
5	Progress Reporting
5.1	Actual Start date is correct if the task has started
5.2	Actual Finish date is correct if the task has finished
5.3	Forecast Start date if the task has not started (date to be populated and in the future)
5.4	Forecast Finish date if the task has not finished (date to be populated and in the future)
5.5	% Work Complete is present and maintained?
5.6	Project One page view appears reasonable (e.g. Reads well etc)?
6	Resourcing
6.1	Tasks have resourcing assigned and resourcing appears reasonably leveled?
6.2	Are there any resource conflicts across phases which could create resource issues for execution?
7	Tasks, Hours, Predecessors, Successors, Approval Points, Naming
7.1	Work hours are spread at task level and total planned hours at the product level are consistent with the earned value reporting system.
7.2	Predecessors and successors do not appear at summary level.
7.3	Tasks and milestones are linked to predecessors and successors.
7.7	Baseline has been saved in the scheduling tool
7.8	Project File Naming convention aligns to Configuration management standard?
8	Critical Path
8.1	Does the schedule tool calculate the critical path through the expected activities/tasks and align to the critical activities noted in the project brief or approach?  If the tool isn’t calculating the expected activities adjustments will be required to the network logic.

 

PLANNING – DEVELOP SCHEDULE QUALITY GUIDELINES

When developing plans the following guidelines should be followed by the program management team to provide a quality deliverable.

 

Work Breakdown Structure Guidance

• The Program Plan and project plans must have aligned Work Breakdown Structures which are in alignment to the Program management plan and scope statement.
• The Program Plan contains the WBS to Level 3 – Activity level.  The project plans contain the WBS to Level 6 – Deliverable level
• The WBS must be aligned between the plans so that the Schedule Manager can take Work performance data from project plans directly into the Program plan.
• Activities and Deliverables should be consistent with the Program management plan and Scope statements
• Include a Key Milestones and External Dependencies section in all plans.  All external project dependencies should be identified in the dependency section of the plan.
• Summary tasks in the plan should relate to the name of the work product
• Tasks and predecessors should show the work flow required to achieve delivery of this work product

Network Logic Guidance

• Avoid using the Constraint logic in the scheduling tool (except for external project dependencies).  Use Network logic (task predecessors and successors) to drive the start / finish dates in the scheduling tool.
• All external project dependencies must have a successor task in the plan
• All tasks in the scheduling tool should contain a predecessor and successor
• All Milestones must have a task predecessor

 

Resource profile Guidance

• The resource profile should be developed and leveled in the Program plan to Level 3. 
• The leveled resource profile must align to the Program Budget and resource plan.  The overall Program plan effort in hours should be consistent with the Program Budget.
• Generic resources can be used if required however if the resource names are known for specific activities in the program plan then these should be used.

 

Deliverables Guidance

• Appropriate review and approval tasks should be included for all deliverables
• Resource names should be included for all tasks.  Resource names shouldn’t be used on summary tasks
• Task names should be descriptive of what work needs to occur.  Action verbs should be included.
• Consistent names should be used across project plans. 
• There should be no ambiguity for task names and each task should have an individual descriptive name.  Task names should be readable by organization staff not working on the project.

 

Milestones Guidance

• Milestones are used to mark the completion (or start) of a key deliverable or activity phase. 
• Milestones should not be too low level of detail; they should provide a view of project progress. 
• An even distribution (over time) of milestones is important as this will provide stakeholders a measure of successful progress. 
• The Program Manager may be required to develop interim phase milestones if a project phase is running over several months.  Interim phase milestones will require project managers to order their deliverables in such a way to achieve interim phase deliverables and therefore interim phase deliverables will require the project managers’ support.  Interim phase milestones are important risk mitigation as they can provide an early indication to the Program Manager of any technical or stakeholder risks to the completion of the phase.
• Milestones should be zero task duration and not have resources assigned to them.  Milestones should have a % complete of either ‘0’or ‘100%’.

 

Naming Conventions Guidance

• Baseline program and project plans should be saved and clearly named and dated in line with the organizational or project configuration management policy. 
• The Schedule Manager should ensure each plan version made during the Monitoring and Control process should be saved as an individual version.

PLANNING – KEY INPUTS FOR DEVELOP SCHEDULE

The development of the program plan requires some key inputs;

• Project Charter (4.1)
• Project Scope (5.3)
• Work Breakdown Structure (5.4)

Project Charter (PMBOK 4.1)

The project charter documents the business need and high level requirements for the expected product, service or result.  The Charter contains key inputs for the program plan such as the summary milestone schedule and key constraints.

Project Scope (PMBOK 5.3)

The project scope defines the work which needs to be completed to deliver the product, service or result with the specified features or functions.   The scope of the project is defined at a high level in the Initiation phase and is further elaborated as the project progresses through feasibility phase in the Scope statement.  Changes to scope are managed via the change control process (5.6 Control Scope).

The project scope baseline is a key input to the development of the program plan. 

Any changes to the scope baseline must be reflected with an update to the program plan and potentially the Work Breakdown Structure.

Work Breakdown Structure (PMBOK 5.4)

The Work Breakdown Structure is a hierarchical decomposition of the total scope of the program which defines and organizes the scope of the program.  The WBS provides a program framework for project control, schedule management and effort estimation.

The Program Work Breakdown Structure is used by the Schedule Manager to define the Levels of activity in the program and project plans.  Since all scope of the project is included in the Work Breakdown Structure then clear accountability for scope delivery will be defined by the WBS.

One objective of the Schedule Manager is to ensure all scope elements are included in the program plan and any lack of clarity regarding scope accountability or delivery is clearly highlighted to the program management team.

IT Branch – Function Chart

Introduction 

The IT Branch – Function Chart is a hybrid function and organisational chart to explain the key functions of an IT Branch of a organisation with a total of 1000-5000 employees.  I would suggest that each of these functions is filled with an ‘manager’ who may have a number of people working in the function.

The PMOBK, PRINCE2 and ITIL methodologies feature somewhat in this chart.  The structure doesn’t employ either of these methodologies completely. 

Diagram:

Strategy & Governance – Function Descriptions

Function	Brief Description
General Management	Operational management of a business unit that delivers specialist technology services to an organisation.
Strategy	Help the business deliver on its objectives, business strategies and goals by aligning business and IT. Develop and maintain and IT systems strategy and direct IT investments in line with business and IT strategies.
Architecture	Develop and maintain enterprise architecture strategies and standards. Provide specialist advice and review projects to ensure compliance and integration with enterprise architecture.
PMO	Owner of the branch project management methodology including processes and templates.  Develop and maintain project management tools, methods, procedures and equipment. Provides project controls function across portfolio in relation to quality, time or cost risks to projects.
Contracts management	Manage IT supplier relationships and monitor commercial, contractual, legal and financial outcomes against contract and contract Key Performance Indicators. Ensure the organisation achieves maximum value from IT supplier arrangements.
Business Administration	Provide administration services to the branch including purchasing, bookkeeping and office management.

Project Delivery – Function Descriptions

Function	Brief Description
Project Delivery (Program Management)	Program management ensures the effective delivery of multiple, simultaneous projects. Ensure all projects are successfully monitored, documented, tracked, reported, integrated and implemented.
Project Management	Manage the end-to-end delivery of projects to deliver quality outcomes for business owners. Application of Project Management competencies including scope, time, costs, quality, HR, communications, risk, procurement, and integration management.
Business Analysis	Business Analysts work with and on behalf of business owners to ensure that business and user requirements are delivered in IT solutions.  Business analysis may include process/scenario analysis or process re-engineering, documentation of business requirements for IT systems and project management of activity within projects.
Design and Development	Designing, developing, system testing and maintenance of applications software to meet users requirements and compliance to enterprise architecture standards.
Test Management	Planning and execution of scenario or functional based testing of applications to ensure stability, reliability of production applications.
Organisational Change	Supports the business throughout the project implementation period.  Activities include change impact analysis, change planning and implementation activities such as road-shows, training and communication.

Systems Support – Function Descriptions

Function	Brief Description
Systems Support (Systems Support Manager)	Systems support ensures the operation of systems to support the business as agreed in Service Level Agreements with the business. Systems support management incorporates a wide range of activity and is well defined by ITIL (Information Technology Infrastructure Library)
Change & Release Management	The change management function ensures minor changes to infrastructure and application or configuration/data changes follow process and are managed effectively.  The release management function ensures major releases have followed process.  Release management is a key quality point for major implementations.
Incident Management	Ensure procedures and processes are in place to deal with high impact incidents that impact Service Level Agreements.  Manage incidents through to return to SLA, raise Problems as potential projects to delivery group.
Disaster Recovery	Developing, planning, testing and administering the organisation’s Disaster Recovery plans and procedures.
Service Desk	The Service Desk provides first level support to all users of IT systems and incident trend reporting to the IT branch.
Desktop Support	Provides Desktop support services to the organisation including desktop lifecycle management and Standard Operating Environment release management.
Infrastructure Support	Infrastructure support provides enterprise level infrastructure services including Email services, messaging systems (EAI), financials infrastructure and other hardware, database and facility management services.