The DBT Framework 1 - Career Insights · PMO in support of the PMO plan and strategy are reviewed...

© Digital Bananas Technology

The DBT Framework 1.9

BY KEJI GIWA


Programme Office

Program Plan

Prioritisation

Budget

Project Plan

Plan / Actual / Tolerance

Milestones

Stage PlanTeam Plan

• Tasks

• Sub Tasks

Team Plan

• Tasks

• Sub Tasks


DBT Project GovernanceTool Project Governance Template

Purpose To create a decision framework for the PMO office and project managed by the PMO office. This consists of:

Structure and People

The governance committee, project sponsors, PMO office and project team.

RACI

Define who is responsible, accountable, who needs to be informed and consulted.

When Project governance strategy must be identified and agreed during the Strategy and Initiation stage and implemented during

the Plan and Assemble stage.


The DBT Governance Structure provides support for the

team to execute and deliver the project outcomes

As N

eed

ed

Weekly

Sponsors programs for overall business strategy

Programme Office

Adore SCaroline A

Executes project, works to resolve issues, provides regular updates and escalates issues as necessary

Directs the programs while there is still business value, change authority and project assurance

Daily

Project Portfolio / Project Workstream Leads

Project Managers

Project Sponsor

Board of

Directors

Project Work stream Team Manager

Business

Analyst

QA

Manager

Head of

SiteTech Lead


5

Team roles & method of communicationGoverning

StructureGeneral Responsibilities Role Who Comms

Project Sponsor • Provide support and direction to the project team on deliverables and

actions

• Help remove organizational barriers

• Align with all other client and Tellallmyfriends work efforts

Executive members • Names here Monthly

Meetings

Programme Office

/Project Board /

Project Steering

Committee

• Accountable to Execs for deliverables and implementation

• Responsible for working with the team to set objectives and goals

• Accountable for risk mitigation, resource alignment, communication and

change leadership plans, and optimal working across workstreams

• Project Sponsors

• Senior Stakeholders

• Names here Weekly

meetings,

Status reports

Project Team • Responsible for execution of the plan toward meeting targeted

objectives, including scope, schedule and resources

• Facilitate alignment and optimal working across team structures and

functional workstreams

• Responsible for ensuring that the solution satisfactorily meets the

agreed-upon success criteria for the project

• Escalation point for any issue that cannot be satisfactorily resolved

within the workstream

• Responsible for risk mitigation, resource alignment, communication and

change leadership plans, and optimal working across workstreams

• Project Lead

• Project Manager

• Workstream Leads

• Members of the

extended Team (when

required)

• Names here Daily

meetings,

Status reports

Supporting Teams • Provide necessary organization support from finance, HR, operations,

change leadership, client teams, or any other required function or role

• Names here As Needed


6

Examples of roles and responsibilitiesRole Responsibility Named Individual

Project Steering Committee • Directing the project, change authority and project assurance Name here

Project Manager • Manage, monitor and control the project Name here

Business Analyst • Justify, translate and communicate business requirements Name here

Tech Lead • Implement, quality assure and deliver a fully functional system Name here


Program Director / Manager A program manager is first and foremost a leader.

In fact, the program manager's main leadership duty is to turn chaos into clarity for the team. People need clear direction and circumstances that allow them to be successful. The program manager must establish such direction both within and outside the organization through a variety of means. Additionally, the program manager may have to accept calculated risk when he or she is unable to obtain clarity from the organization and then define clarity in his or her own terms

The primary difference between a program manager and a project manager can be summed up in the words create and comply. The program manager is responsible for creating the business environment culture the project manager complies with to execute.


Project Manager

The project manager's role in

a nutshell, is the overall

responsibility for the

successful planning, execution,

monitoring, control and

closure of a project.


Project Managers Toolkit

Approach

• Framework

• Governance

• Methodology

Control

• Business Case

• Stakeholder Analysis

• Communication Plan (RACI)

• Project Planning

• Resource Planning & Budgeting

• Checklist

• RAID

• Change Control

• Quality Control

• Configuration Management

Reporting

• Status Reporting

• Issue Reporting

• End Stage Reporting

• Highlight Reporting

• Exception Reporting

• Checkpoint Reporting

• Dashboard


PMO Analyst - Worked with executive management to

develop the strategic direction of the PMO- Contributed to the develop of the PMO's strategic plan- Developed new processes- Performed process improvement activities

- Developed and delivered training- Participated in project selection activitiesPMO in support of the PMO plan and strategy are reviewed and continually improved upon. In this context, the PMO analyst is not so much invloved with project-related analysis but rather analysis related to the effectiveness and performance of the PMO as a business unit.


Project Planner Develop and define project goals and objectives.

Monitor and analyze project effectiveness using qualitative and quantitative tools.

Recommend and implement modifications to improve effectiveness and attain project milestones.

Plan, coordinate and monitor activities of assigned projects to develop and implement procedures, processes and systems.

Educate employees in methods to ensure project continuity and completeness.

Develop detailed task lists and work effort assessment.

Prepare short and long-term resource allocation plans based on input from all key players and team members.

Oversee schedules and risk management plans and provide serious deviations warnings hindering project results.

Identify changes in work scope in the project plan.

Ensure to take appropriate planning measures with all clients to reassess, renegotiate and amend scope of work responsibilities, proposals, contracts and budgets.


Project Coordinator Provide support to the Project Manager and Work Stream

Managers on all aspects of the project.

Ensure that the project team follow all governance and process as defined by PMO and to ensure that all reports are submitted on time and in the format required.

Be called upon by the Project Manager to undertake specific tasks other than those listed in the responsibilities below.

Responsibilities

Set up and maintain project control filesEstablish document control procedures and set-up and maintain project documentation management

Collect actuals data and forecasts and produce consolidated actual/accrual/forecast reports

Update central project plans, support Workstream Lead in maintaining their workstream plans and ensure alignment between workstream plans and central project plans

Administer or assist the quality review processAdminister change control process


Program Management


Program Management


Program Management


Our Programs

DBT

HMC

iOS Android Analytics

CI

Personality test

Interview Q & A

Video Tutorials


Prince 2


The Prince 2 Process


Prince 2

RINCE2 (an acronym for PRojects IN

Controlled Environments) is a de facto process-based

method for effective project management. Used

extensively by the UK Government, PRINCE2 is also

widely recognised and used in the private sector, both in

the UK and internationally. The PRINCE2 method is in the

public domain, and offers non-proprietorial best practice

guidance on project management.


Key features of Prince 2

Focus on business justification

Defined organisation structure for the project

management team

Product-based planning approach

Emphasis on dividing the project into manageable and

controllable stages

Flexibility that can be applied at a level appropriate to the

project.


Prince 2Principles

• Business justification

• Learn from experience

• Roles and Responsibilities

• Manage by Stages

• Manage by exception

• Focus on products

• Tailor to suit the project environment

Processes

• Starting Up a Project (SU)

• Initiating a Project (IP)

• Directing a Project (DP)

• Controlling a Stage (CS)

• Managing Product Delivery (MP)

• Managing Stage Boundaries (SB)

• Closing a Project (CP)

Themes

• Business Case

• Organisation

• Quality

• Plans

• Risk

• Change

• Progress


Live Hap

Happy After

The Relationship Framework

Dating

Courtship

Planning

Intro Engagement WeddingHoney moon

S S

S


Live Hap

Close

The Prince 2 FrameworkSU

Initiate

Control

MP MP MP MP

S S

S


The Prince 2’s Approach to Project Management

•Project Brief

•Project Governance

•Acceptance Criteria

•Stakeholder buy-in

•Authorise Initiation

Business Justification

•Business Case

•Requirement Specification

•Project Plan

•Risk Management Strategy

•Quality Management Strategy

•Configuration Management

•Progress Management & Control

Initiation•Manage By Stages

•Managed By Exception

•Control Documents

•Continuous Progress Reporting

•Quality Stage Reviews

•Project Delivery

Progress Monitoring & Control


Live Hap

Close

The DBT FrameworkConceptualise

Strategise & Initiate

Plan, Assemble & Control

Analyse Design Develop Test Deploy

S S

S

S

Implement & Test


WAGILE MethodologyConceptualis

e the Idea

Strategise &

Initiate

Plan,

Assemble &

Control

Deploy &

Close

Implement & Test


WAGILE MethodologyConceptualise

the Idea

Strategise &

Initiate

Plan, Assemble &

Control

Deploy & Close

Implement & Test

Phase 1

Phase 2


Process Flow

Conceptualise the Idea

Strategise & Initiate

Plan, Assemble & Control

Implement & Test

Deploy and Close

Directing the Project

M M M MAnalyse

Design

Develop

Test

Deploy


PMO Framework

Conceptualize

the idea

Plan

& Assemble

Implement

& Test

Deploy, Close

& Support

Strategies &

Initiate

• Business Analyst, Project

Manager

• Project Sponsor

Who

Stage 2: Project is approved to begin, resources allocated, project team approved

• BA (Justifiable business

case), Project Manager

(initiates the projects),

Project Sponsor (authorises

the project)

Stage 1: Proposed concept is defined, outlined and approved for initiation

Stage 3: Plans approved, detailed project set up complete, resources secured, implementation begins

Function

• Definitive scope work (MOSCOW) based on

business value (IBV, MBV, LBV).

• Resource allocation and budgeting

• Definitive project plan

• Requirement spec / Product backlog

prioritisation, sprint planning meeting

• BA / Tech Lead

• Project Manager

• QA Manager

• Project Manager (project

planning, resource

allocation & budgeting)

• BA (req spec)

• Tech Lead

• QA Manager

• Waterfall / Agile using the SDLC - Deliverables,

System Test, Bug fixing, UAT, Defect

Management,, System Integration, Client Review

• Ensure project is completed as planned

• Submit Application

• Ensure any ongoing work is handed over

• Go live

Stage 4: Implement & Test

Results

Project brief (Terms of reference,

project charter) - Purpose outlined,

Business Case Outlined,

Authorise Initiation

PMO Toolkits & PMO office setup

Justifiable business case, Project plan ,

Comms plan, stakeholder analysis,

benefit review plan, project

management strategies

Project control & Reporting tools –

Approve project

• Define proposed project in concept, Prepare project

brief

• Assemble project team, capture previous lessons

• Select project approach & plan initiation stage

• Outline business case, preliminary risks, assumptions

•

• Create a justifiable business case

• Define scope, resources, timeline, budget and

tolerance for project

• Project Governance , stakeholder analysis,

communication plan

• Project plan, project controls, reporting tools,

resource planning and budgeting

• Project Manager, Tech Lead

• QA Manager , BA

• Project Sponsor

Plans aligned with project objectives

Plans sufficiently detailed to track &

manage progress and deliver benefits

Sprint planning & Burn down chart

Deliverables built incrementally

Start implementation

Full Functional Application

Development

UAT and Client Sign off

All deliverables accepted

Benefits secured, Open activities

transitioned

Lesson’s learnt, Project closure

Stage 5: All scoped deliverables complete


MOSCOW

Burn Rate &

Project

Profitability

Detailed

Requirement

List

Resource

Allocation &

Budgeting

Define

Project

Approach

Analyse

Support

Checklist

Client Sign

Off

Dev >

Staging >

Live

Agree

Status /

Progress

Reporting

Process

Capture

Previous

Lessons

Project

Proposal

Project

Controls

Definitive

Project Plan

RAID Doc

Change

Control

Process

Client

Feedback

Process

Project

Governance

Lessons

Learned

Stakeholder

Analysis &

Comms PlanProject Brief

Agree

Checkpoint &

Quality

Review

1. Conceptualise

the Idea

2.

Strategise &

Initiate

3.

Plan,

Assemble &

Control

4.

Implement

&

Test

5.

Deploy, Close &

Support

Assemble

Project Team

Justifiable

Business

Case

Defining

Scope of

Work

Reporting

Tools

Project Plan

& Resource

Planning

Implement

SDLC

Approach

Benefit

Review Plan

Develop

Test

Design

Deploy

Supporting

Documentati

on

Follow On

Recommend

ation

Lessons

Learnt

Report

Phased

Release

Development

Immediate

Business

Value

Mid Term

Business

Value

Long Term

Business

Value

Process Flow

Waterfall Approach


Burn Rate &

Project

Profitability

Detailed

Requirement

List

Resource

Allocation &

Budgeting

Define

Project

Approach

Product

Backlog

Prioritisation

Support

Checklist

Client Sign

Off

Dev >

Staging >

Live

Agree

Status /

Progress

Reporting

Process

Capture

Previous

Lessons

Project

Proposal

Project

Controls

Definitive

Project Plan

RAID Doc

Change

Control

Process

Client

Feedback

Process

Project

Governance

Lessons

Learned

Stakeholder

Analysis &

Comms PlanProject Brief

Agree

Checkpoint &

Quality

Review

1. Conceptualise

the Idea

2.

Strategise &

Initiate

3.

Plan,

Assemble &

Control

4.

Implement

&

Test

5.

Deploy, Close &

Support

Assemble

Project Team

Justifiable

Business

Case

Defining

Scope of

Work

Reporting

Tools

Project Plan

& Resource

Planning

Implement

SDLC

Approach

Benefit

Review Plan

Sprints

(Iterations)

Incremental

Deliverables

Sprint

Planning

Meeting

QA

Supporting

Documentati

on

Follow On

Recommend

ation

Lessons

Learnt

Report

UAT

Phased

Released Dev

Plan

Immediate

Business

Value

Mid Term

Business

Value

Long Term

Business

Value

Sprint

Reviews

Process Flow

Agile - Scrum

MOSCOW


Using SDLC

Feasibility Analyse Design Develop Test Deploy Maintain

The approach is defined at the conceptualise stage of the framework and implemented at the Plan, Assemble and Control Stage.


Waterfall


Project Approach: WATERFALL APPROACH


Software

Hardware


Modules Senses

Sight - eyes

Smell - notse

Touch – hands & legs

Organs

Liver

Heart

kidney

Skeleton

Skeleton – hand

Skeleton - finger



the Idea

Strategise &

Initiate

Plan, Assemble &

Control

Deploy & Close

Implement & Test



the Idea

Strategise &

Initiate

Plan, Assemble &

Control

Deploy & Close

Implement & Test

Phase 1

Phase 2


U S 1Fi

F2

F3

AGILE DEVELOPMENT PROCESS

User Story 8

User Story 7

User Story 6

User Story 5

User Story 4

User Story 3

User Story 2

User Story 1

Deliverables 1

Deliverables 2


Scrum Development Process



the Idea

Strategise &

Initiate

Plan, Assemble &

Control

Deploy & Close

Implement & Test

Phase 1

Phase 2



the Idea

Strategise &

Initiate

Plan, Assemble &

Control

Deploy & Close

Implement & Test


The Creator & Developer


When Waterfall Goes Right

Defined Timeline: 9 Months

Modules Already exist and easy to define.


When waterfall Goes Wrong


Agile


Must / IBV

End User Needs

Should / MBV

End User Wants

Could / LBV

End User Don’t Mind

Won’t / NBV

End User Don’t Want

End user requirements based on business

value

MOSCOW PRIORITISATION MODELLING IN LINE WITH BUSINESS VALUE (BV)


Prioritising Requirements

InputBottom

LineBigger Picture

Business Value

Business Needs / Success Criteria

Opinions

Facts

End User / Use Led

User Requirements

Need

Want

Don’t Mind

Don’t Want


SME – Subject Matter Experts

Identify staff responsible for implementing key stages of

the project with subject matter knowledge, expertise and

application


Constant collaboration

Working across cross functional teams

Stakeholders / Clients / SME PM, BA & Product Owner

Designers & DevelopersQA Team


Stakeholder Analysis






Communication PlanProject

Sponsor

Project

Manager

BA UX Tech Lead Developer QA Tester

Justification A I R I C - - -

Analysis I A R C C I I I

Design I A C R C I - -

Implementation I I C C A R I I

QA I I I I I C A R

Deploy I A I I R C C I

RACI – Responsible, Accountable, Consult, Inform

Establish: Method of Communication & Frequency of Communication.


Communication PlanMethod of

Communication

Frequency of

Communication

Project Sponsor Email / Conference Ad hoc

Project Steering Committee Email / Conference Fortnightly

Project Manager Weekly Status

Meeting

RACI – Responsible, Accountable, Consult, Inform

Establish: Method of Communication & Frequency of Communication.


U S 1Fi

F2

F3

AGILE DEVELOPMENT PROCESS

User Story 8

User Story 7

User Story 6

User Story 5

User Story 4

User Story 3

User Story 2

User Story 1

Deliverables 1

Deliverables 2Teenage

Sprint


VersionRelease

UAT

QA(Components,

Integration, System)

Back End Development

Software RequirementSpecification

User Story

User Journey

(Wireframes, Key screens)

Phase 1Core Functionality

Phase 2

Improved Functionality

Phase 3Additional Functionality

Prioritisation

Analysis

Test PlanTest Cases

1

2

3

4

5

6

7

8

Customer AcceptanceCriteria &

Expectations

Usability Validation

Usability Evaluation & GUI

FunctionalityCross Browser

TestingCross App Testing

Performance Testing

GUI TestingBrand Guidelines

GUI TestingBrand Guidelines


Defining the Scope of the Project (MOSCOW)

Scope

Acceptance Criteria

Must

Must be implemented within the allocated time,

budget and resources

Quality Expectations

Should

Only to be implemented if there is spare time,

budget or resources from allocation

Could

Only to be implemented if allocated time, budget

or resources can be extended

Not In Scope

Won’t

Will not be implemented within the scope of work


Must / IBV

End User Needs

Should / MBV

End User Wants

Could / LBV

End User Don’t Mind

Won’t / NBV

End User Don’t Want

End user requirements based on business

value

MOSCOW PRIORITISATION MODELLING IN LINE WITH BUSINESS VALUE (BV)


Prioritising Requirements

InputBottom

LineBigger Picture

Business Value

Business Needs / Success Criteria

Opinions

Facts

End User / Use Led

User Requirements

Need

Want

Don’t Mind

Don’t Want


Project Approach: Agile / Scrum Process


Product BacklogI want to list stuff to sell to my friends

I want to list stiff to give away to my friends

I want to offer a service to my friends

I want to list stuff I need to my friends

I want to list stuff to contacts who are not on my friends list

I want to set miles radius when listing stuff

I want to follow a contact

I want to unfollow a contact

I want to filter my activity feed I want to contact a user via sms

I want to contact a user via call

I want to comment on a product

I want to contact a user via chat

I want to contact a user via email


Agile / Scrum Process


What’s working?

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan


In a nutshell

Agile management or agile project management is an iterative method of determining requirements for software and for delivering projects in a highly flexible and interactive manner.

It requires empowered individuals from the relevant business, with supplier and customer input.


Agile Risk Management Process


Agile-Scrum


SCRUM

• Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.

• Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.


SCRUM PRINCIPLES

The framework and terminology are simple in concept yet difficult to implement. Successful Scrum teams embrace the values upon which Scrum is based (paraphrased from the Agile Manifesto):

We value

Individuals and interactions over processes and tools

Completed functionality over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, the items on the left matter more.

True success with the Scrum framework comes from teams and organizations who understand these values and the principles that form the foundation of all agile processes.


Constant collaboration

Working across cross functional teams

Stakeholders / Clients / SME PM, BA & Product Owner

Designers & DevelopersQA Team


SCRUM ROLES Product Owner

A single individual responsible for the project and the overall

quality/success of the project. They manage the Product Backlog,

manages expectations of the project and has the final word on which

tasks are "done" during sprint review meetings.


SCRUM ROLES

Scrum Development Team

The team which is responsible for the actual development of the project. Generally team size will be from 5-10 people and all of which will have their specialities, however as a whole will contain all of the expertise that would generally be found in several departments.


SCRUM ROLES

Scrum Master

The Scrum Master facilitates the Scrum, they are responsible for keeping the process current, shields the team from external distractions and manages the process quality of the teams output.While the scrum master is responsible for these items along with many more, the scrum masteris not senior to the team and the team does not report to the Scrum Master, they are simply there to ensure the scrum runs effectively. They do not have authority to make business, technical or resource decisions as they may cloud that true role of Scrum master.


FLOW OF SCRUM

1. Sprint Planning Meeting

2. Daily Scrum

3. Sprint Review Meeting

4. Sprint Retrospective Meeting

5. Backlog Refinement Meeting


Iterative


Incremental

Delivery


FLOW OF SCRUM

Sprint Planning Meeting

Previous to starting the Sprint Planning Meeting, the Product Owner will have worked on producing a Product Backlog (see lingo). The planning meeting should generally be one full day split in two.

The first half has the development team concentrating solely on the product backlog and deciding on the tasks and committing to completing those tasks. The Product Backlog will be discussed through out the sprint.

The second half includes the development team and the Product Owner. The team decide how to build and also decide on tasks based on the Product Backlog and allocate the tasks to a Sprint Backlog (see lingo)


FLOW OF SCRUM

Daily Scrum

This is a short (max 15 min) meeting which occurs every day of the sprint. It should generally be held where development takes place and all member should stand as to ensure it's quick. The main aim is to have each member answer 3 basic questions

"What have I done since the last scrum"

"What will I do before the next scrum"

"What issues are stopping my progress“

The Scrum Master is responsible for ensuring the meeting sticks to these items, and if something needs to be discussed more then that happens after the meeting.


FLOW OF SCRUM

Sprint Review Meeting

The team show all "done" tasks to the Product Owner. Feed back will be given from the ProductOwner and they may decide to re-prioritize on-coming sprints. The Scrum master schedules the next Sprint Review Meeting.


FLOW OF SCRUM

Sprint Retrospective Meeting

This is a formal meeting including the full team, including the Scrum Master, although the Project Owner is optional. The aim of the meeting is to talking through what went well and what didn't go well. The scrum Master is there to push the questions, however not there to provide the answers.


FLOW OF SCRUM

Backlog Refinement Meeting

During this meeting the Project Owner has the opportunity to re organise the Product Backlog based on customer needs. This impact is then discussed.


AGILE LINGO

Sprint Backlog: To-Do list for the sprint.Defined by the full team.Product Owner order's tasks priority.

Product Backlog: List of desired product features/bugs/issues.Owned and organized by the Product Owner.Items can be added by any one/any time.

Time Box:The amount of time task should take.


DBT Requirement

Engineering Process

Sprint Planning Meeting

Use Case / Epic Stories

User Stories

Mockups

Business Rules

BDD / Gherkin Syntax

Functionalities / DFD

Non Functional Req

Wireframes

Keyscreens

Implement

Test

Release

HLR

Workshop

Requirement

Catalogue

Product

Planning


Date post:	20-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times