NBB GROUP | EPMO

Project Schedule
Guidelines
December 2021
Table of contents

1. Project Management Plan .................................................................................................3

1.1 Schedule ..................................................................................................................3
1.1.1 Structure ....................................................................................................3
1.1.2 Phases ........................................................................................................3
1.1.3 Critical Path Setup ....................................................................................4
1.1.4 Naming conventions .................................................................................5
1.1.5 Dependencies ............................................................................................ 5
1. Project Management Plan
1.1 Schedule
One of the most critical components of any project plan is the project schedule. The schedule does
not only track all key milestones but is a key input into the monitoring dashboard.
Projects should be detailed to the task level with specific start dates, end dates and owners. The
duration should be realistic, taking into account the resources' day to day priorities and tasks.

1.1.1 Structure
The structure of the master plan are driven mainly on the approach by which the projects plan will
be used to drive oversight, control and report progress.
Some high-level planning should be performed to define set of work that will need to be managed
as separate projects or as a centralized program. For example, there could be 5 projects defined
separately, however when as these projects approach the final phases of the system implementation,
the remaining activities such as rollout and product support might be managed centrally. Therefore,
standardizing the project structure will enable easier integration between different project sin the
portfolio.
A typical project structure should have the following key levels:
• L0 – program
• L1 – project
• L2 – phase; at this level we should identify the milestone
• L3 – major activity –at this level we should identify the deliverable
• L4 – task

L0: Program

L1: Project L1: Project

L2: Phase L2: Phase L2: Phase L2: Phase

(milestone) (milestone) (milestone) (milestone)

L3: Major L3: Major L3: Major L3: Major L3: Major L3: Major L3: Major L3: Major
Activity Activity Activity Activity Activity Activity Activity Activity
(Deliverable) (Deliverable) (Deliverable) (Deliverable) (Deliverable) (Deliverable) (Deliverable) (Deliverable)

L4: Task L4: Task L4: Task L4: Task L4: Task L4: Task L4: Task L4: Task

L4: Task L4: Task L4: Task L4: Task L4: Task L4: Task L4: Task L4: Task

1.1.2 Phases

In order for overall progress be tracked, consolidated, managed, and reported across portfolios, the
following levels of program phase demarcation need to be followed:
 • Initiation (this cover the initial phases of the projects, building the team, allocating the
budget, project request, project charter pointing out the business outcomes targetted,
vendor selection, procurement, etc.)
• Planning (this cover the work to be performed to define the scope of the project, schedule,
resource planning, and how it will be implemented, and also includes continuous project
status tracking / reporting, etc.)
• Delivery (the actual execution of the work, which will be spread across multiple phases
depending on the project) (this could be on iterations i.e. delivery 1, Delivery 2, delivery 3)
• Closure (Change Management Transition / Institutionalization, taking the project work into
the BAU / production, and lessons learned. This should not be only systems, it should be
people, process, etc.)
• Value (Measuring impact and business outcomes achieved and whether business outcomes
are achieved)
As an example, the procurement of the services / solution will be covered initiation phase.
For each project, have well defined milestones and deliverables. Critical deliverables that need to be
tracked by the sponsor and different committees are called “key deliverables” at L3 and hence they
are tracked at the enterprise-level, vs. deliverables needed to build up to a key deliverable are placed
at L4. The team may further add additional milestones / deliverables for internal purposes.

1.1.3 Critical Path Setup

In principle, the milestone should be defined at the phase level, and it should be the last step in the
phase. The predecessor for the milestone should be the deliverables. This create structure by which
all tasks are linked to deliverables and all deliverables are linked to milestones, as demonstrated
below:
ID Activities Duration Predecessor

1 L2: Phase 1
2 L3: Major Activity 1
3 L4: Task 1 x
4 L4: Task 2 x 3
5 L4: Task 3 x 4
6 L4: Task 4 x 5
7 L3: Key Deliverable 1 Completed 0 6
8 L3: Major Activity 2
9 L4: Task 1 x 7
10 L4: Task 2 x 9
11 L4: Task 3 x 10
12 L4: Deliverable 2 Completed 0 11
13 L2: Milestone 1 Completed 0 6, 7

4
Within the major activity in the phases, set of tasks that are managed together should produce a
deliverable. These need to be grouped together and the sequencing / linking of the predecessors
should end into the deliverable.
The activities should be defined in form of duration and predecessors. Using hard dates should be
avoided entirely, if possible. This will allow for clear definition of critical path and easier impact
analysis later one.

1.1.4 Naming conventions

Tasks should be start with verb to indicate the work performed as follows:
• Start with verb and indicate the work to be performed. For example, “Conduct xyz
functionality requirement definition workshops.”
• Minimum duration is 1 day, and max is 5 days; takes beyond 5 days should be broken into
multiple tasks. This is crucial to have sense of progress
• the tasks sequencing / referencing is critical to identify the critical activities that form the
critical path. In principle, you want to identify the impact by changing tasks schedule on
the plan. This was a challenge, and it should be designed properly from 1st day.
On the other hand, Key milestones / deliverables should be in the past tense. for example,
“Requirements for XYZ functionality Defined”.

1.1.5 Dependencies
There should be a clear logic behind linking different dependencies with other plans. Dependencies
must be defined explicitly at the project; there should be a section for it at the beginning of the
schedule. The definition of the dependencies should follow the same principle for naming definition
for milestone / deliverables.
Afterwards, dependencies must be linked to the key activity; and it should not be linked to the tasks.
This will significantly reduce the overhead of managing the dependencies.

1.1.6 Governance
The adherence of the above is driven by the need to establish a balance of flexibility and
governance controls needed on managing the schedule; Therefore, the L0 – L3 is baselined at the
enterprise and the project manager has the flexibility to further change/elaborate the tasks
definition, provided the timeline of key deliverables and milestones is not impacted.

The following table provides an illustration of the governance on schedule baseline, reporting and
changes:

Project Category A

Level Baselined by Progress <5% change 5-15% change >15% Change

Reported to APPROVAL BY: APPROVAL BY: APPROVAL BY:

L0: Program PSG PSG, EPMO PSG PSG PSG

L1: Project PSG PSG, EPMO, PSG PSG PSG

Project Sponsor

L2: Milestone PSG PSG, EPMO SteerCo PSG PSG

SteerCo

5
L3: Major SteerCo SteerCo, SteerCo SteerCo PSG
Activity / EPMO,
Deliverable Working Group

L4: Task Project Owner Working Group Project Owner Project Owner Project Sponsor

Project Category B

Level Baselined by Progress <5% change 5-15% change >15% Change

Reported to APPROVAL BY: APPROVAL BY: APPROVAL BY:

L0: Program PSG PSG PSG PSG PSG

L1: Project PSG EPMO PSG PSG PSG

L2: Milestone SteerCo (If not EPMO, SteerCo SteerCo (If not SteerCo (If not PSG
available, Project available, Project available, Project
Sponsor) Sponsor) Sponsor)

L3: Major SteerCo (If not SteerCo, SteerCo (If not SteerCo (If not SteerCo (If not
Activity / available, Project Project Sponsor available, Project available, Project available, Project
Sponsor) Sponsor) Sponsor) Sponsor)
Deliverable Working Group
L4: Task Project Owner Working Group Project Owner Project Owner Project Owner

Project Category C

Level Baselined by Progress <5% change 5-15% change >15% Change

Reported to APPROVAL BY: APPROVAL BY: APPROVAL BY:

L0: Program Project Sponsor Project Sponsor Project Sponsor Project Sponsor Project Sponsor
Project Owner

L1: Project Project Sponsor EPMO, Project Project Sponsor Project Sponsor Project Sponsor
Sponsor
Project Owner

L2: Milestone Project Sponsor EPMO, Project Project Owner Project Sponsor Project Sponsor
Sponsor
Project Owner

L3: Major Project Sponsor Project Sponsor Project Project Owner Project Sponsor
Activity / Project Owner Manager
Deliverable

L4: Task Project Owner Working Group Project Project Owner Project Sponsor
Manager