Monitoring and Control (MC)

(Approval of the Monitor and Control indicates an understanding of the purpose and content described in this document. By approving this procedure, each individual agrees on the proposed subsystems' roles and business logic they are responsible for; Planning should be initiated on this project and necessary resources should be committed as described in Charter document.)

Document Revision History

1. Introduction

For a successful project, there are some best practices to implement good project monitoring & control. Because monitoring and controlling activities check if there are deviations from the expected results of the project. Every project has a life cycle. During this life cycle, there are several phases called ‘process groups‘. Each of these process groups has a different and crucial objective, which helps to produce desired outcomes in a project. The project monitoring and controlling process group activities help to keep the project on track.

2. Purpose, Goals, and Objective

The main purpose of monitoring and Control is,

• To manage project activities and practices for the betterment of the project
• To keep the project on track
• To check the Project Performance with respect to,
  • Timelines
  • Estimations (Estimated vs Actual)
  • Project Quality
  • Project Stability
• To Check Resource Performance with respect to,
  • Timelines
  • Estimations (Estimated vs Actual)
  • Work Quality
  • Work Quantity
  • Potential
• To Gain Acceptance from the customer

3. Scope

• Process of monitoring the status of the project and the product scope, and managing changes to the scope baseline
• Measuring project and product scope performance and managing scope baseline changes.
• Process of monitoring resources and performance.

4. Policies

• Provide a common language for use by all our teams in the implementation of our projects.
• Boost the organization's continuous improvement approach, with particular regard to the management of performance and project results.
• Guide the Planning, Monitoring, and controlling practices of our projects and ensure that they meet the quality, learning and accountability challenges that sit at the very heart of our organizational procedures.
• Track down all the issues and action items that we come across throughout the life cycle of the project with a documented proced

5. Work Product

A work product may begin as an analysis made during the development of a project, creating a type of proposal for the project that a company cannot deliver until the project has received approval. Companies use work products to provide information to current stakeholders and potential investors. Types of information available in a work product might include prototypes, presentations, recorded discussions, diagrams, and status reports. The organization can also use the work product as a source of information while the project progresses.

Work product for the MC area is,

• Project Plan
• Release Plans
• Task List (Which will be maintained in Jira)

6. References

7. Records of MC

8. Roles and Responsibilities

9. Process flow and Description

1. Initial Phase

• Project Monitoring & Control
  • Monitoring and control activities begin once the project plan is finalized.
  • The Project Manager (PM) is responsible for monitoring and controlling the project.
• Release Planning
  • After finalizing the project plan, the Business Analyst (BA) and PM prepare the release plan.
  • Release plans are maintained in Jira.
• Task Creation & Allocation
  • Based on the release plan, the PM creates development/technical tasks in Jira.
  • The PM identifies tasks requiring:
    • Unit Test Cases
    • High-Level Design (HLD)
    • Low-Level Design (LLD)
  • Tasks are assigned to respective resources with:
    • Estimated timelines
    • Estimated effort (hours)
• Development Initiation
  • The PM reviews the Unit Test Cases.
  • Development work begins only after approval of Unit Test Cases by the PM.

2. Mid Phase

• Monitoring & Follow-up
  • The PM and BA conduct periodic follow-ups to ensure alignment with the release plan.
  • Any issues related to this are escalated to the PM
    • Release
    • Resources
    • Project-level risks
  • The PM is responsible for resolving such issues.
  • All issues are logged and tracked in Jira.
• Task Review & Stability
  • The PM or Team Lead reviews tasks to ensure:
    • Work progress is aligned
    • Stability is maintained

3. ** Release Management Framework**

• Types of Releases
  • Client Release
    • Client Release is created to share updates with the client team.
    • It may include:
      • Stories
      • Improvements
      • Change Requests (CR)
      • Client Tasks
    • A Client Task may also be part of a Dev Release if it involves development work and has a merge request.
    • Every Client Release must be linked to one or more Dev Releases.
  • Dev Release
    • Dev Releases are used for CI/CD tracking and to manage incremental deliveries.
    • Dev Releases are created based on Client Releases.
    • One Client Release can have one or multiple Dev Releases, depending on how we plan to deliver features step by step.
    • Dev Releases can include:
      • Backend tasks
      • Frontend tasks
      • QA bugs
      • UAT bugs
      • Unit test bugs
      • Tech support tasks
• Linking & Approval Governance in Jira
  • Dev Releases must be linked to Client Releases using the “Related Work” option in Jira.
  • Every Dev Release must be approved by QA.
  • QA approval must be recorded in the Approvers section in Jira.
  • Every Client Release must be approved by:
    • QA
    • PO / PM / Coordinator
  • All related evidence and documentation must be properly maintained in Jira.

4. Release Phase

• Pre-Release Activities

  • Developers will perform unit testing before giving the module for testing or managerial review
  • The PM conducts:
    • Task Review
    • Code Review
    • Milestone Review
  • Review findings are recorded in Jira.
  • Review tasks, if created, must be linked to the main task.

• Status Verification

  • PM or Team Lead ensures task statuses are correctly updated in Jira
  • An email is sent to QA with the required release details before QA testing.

• Stage Deployment Process

  • The Development Team deploys completed features to the Stage environment.
  • After deployment, Jira status must be updated to “Deployed on Stage.”
  • QA Responsibilities:
    • Test the stage deployment.
    • Confirm whether it is ready for production.

• Production Release Process

  • QA creates a Production Release using a naming format such as:
    • 2026_DevRelease_V1.0
    • 2026_DevRelease_V1.1
  • The same release name/tag must be used in GitLab.
  • QA will inform the client in Telegram (TG) with a release notes summary and mention the expected halt time. Release notes can be copied from Jira.
  • After client approval, we proceed with the production release.
  • The client will be informed once deployment is completed.

5. Post-Release Phase

• After Production Release
  • The Coordinator / PO / PM will:
    • Inform the client which features from the Client Release are now live.
    • Perform final verification/testing of released features.
• Client Feedback Handling
  • After release:
    • If Approved:
      • BA records approval status in Jira.
    • If Findings Are Provided:
      • BA and PM review findings for:
        • Client-reported bugs
        • New feature requests
• Client Bug Handling
  • Client bugs are logged in Jira by the BA.
  • Bugs are linked to the respective task.
  • Developers resolve the bugs.
  • QA tests to ensure a bug-free module.
  • BA delivers the updated module to the client.
• Change Request (CR) Handling
  • If findings include new requests:
    • BA raises CR forms as per the RDM process.

graph TD

%% =======================
%% STYLES (Light Professional Palette)
%% =======================
classDef initial fill:#e1f5fe,stroke:#01579b,stroke-width:1px;
classDef mid fill:#fff3e0,stroke:#e65100,stroke-width:1px;
classDef framework fill:#f3e5f5,stroke:#4a148c,stroke-width:1px;
classDef release fill:#e8f5e9,stroke:#1b5e20,stroke-width:1px;
classDef post fill:#ffebee,stroke:#b71c1c,stroke-width:1px;

%% =======================
%% 1. INITIAL PHASE
%% =======================
A[Project Plan Finalized]:::initial --> B[Monitoring & Control Begins]:::initial
B --> C[PM Responsible for Monitoring]:::initial

A --> D[Release Planning by BA & PM]:::initial
D --> E[Release Plan Maintained in Jira]:::initial

E --> F[Task Creation in Jira by PM]:::initial
F --> G[Identify Tasks: HLD / LLD / Unit Test Cases]:::initial
G --> H[Assign Tasks with Timeline & Effort]:::initial

H --> I[PM Reviews Unit Test Cases]:::initial
I --> J[Development Starts After PM Approval]:::initial

%% =======================
%% 2. MID PHASE
%% =======================
J --> K[Periodic Monitoring by PM & BA]:::mid
K --> L[Issues Identified]:::mid

L --> M{Issue Type}:::mid
M -->|Release| N[Escalated to PM]:::mid
M -->|Resource| N
M -->|Project Risk| N

N --> O[Issue Resolution by PM]:::mid
O --> P[All Issues Logged in Jira]:::mid

J --> Q[Task Review by PM / TL]:::mid
Q --> R[Check Progress & Stability]:::mid

%% =======================
%% 3. RELEASE MANAGEMENT FRAMEWORK
%% =======================
R --> S[Client Release Created]:::framework
S --> T[Includes Stories / CR / Improvements / Client Tasks]:::framework

S --> U[Dev Release Created]:::framework
U --> V[Linked to Client Release via Related Work]:::framework
V --> W[Dev Release Includes Dev/QA/UAT/Bugs]:::framework

W --> X[QA Approval Required for Dev Release]:::framework
S --> Y[Client Release Approval Required]:::framework
Y --> Z[QA + PO/PM Approval]:::framework

%% =======================
%% 4. RELEASE PHASE
%% =======================
X --> AA[Pre-Release Activities]:::release
AA --> AB[Developer Unit Testing]:::release
AA --> AC[PM Task / Code / Milestone Review]:::release
AC --> AD[Review Findings Logged in Jira]:::release

AD --> AE[Stage Deployment]:::release
AE --> AF[Status Updated to Deployed on Stage]:::release
AF --> AG[QA Stage Testing]:::release

AG --> AH{Ready for Production?}:::release
AH -->|Yes| AI[Production Release Creation by QA]:::release
AH -->|No| Q

AI --> AJ[Same Tag Used in GitLab]:::release
AJ --> AK[Release Notes Sent to Client in TG]:::release
AK --> AL[Client Approval]:::release
AL --> AM[Production Deployment]:::release
AM --> AN[Client Informed After Deployment]:::release

%% =======================
%% 5. POST RELEASE PHASE
%% =======================
AN --> AO[Coordinator / PO Final Verification]:::post
AO --> AP{Client Feedback}:::post

AP -->|Approved| AQ[BA Records Approval in Jira]:::post
AP -->|Findings| AR[Review Findings by BA & PM]:::post

AR --> AS{Bug or New Request?}:::post
AS -->|Bug| AT[Bug Logged in Jira]:::post
AT --> AU[Dev Fixes]:::post
AU --> AV[QA Testing]:::post
AV --> AW[BA Delivers Fix to Client]:::post

AS -->|New Feature| AX[CR Raised as per RDM Process]:::post

10. Measurements

Measurements for Monitor and Control,

• MOM and Action Item Compliance
• GOOD and BAD metrics will be given to MOM and Action items,
  • If Action Item Compliance = 100% = GOOD
  • If Action Item Compliance not equal to 100% = BAD

11. Verification and Validation

• Periodic reviews of the process and work will be done by BA and Manager.
• A Periodic project review will be done by a manager which will contain,
  • Task Review
  • Code Review
  • Issue Logs
  • Milestone Review
• All managerial tasks and required information will be maintained in jira.
• This provides awareness of and insight into software process activities at an appropriate level of abstraction and promptly. The time between the reviews should meet the needs of the organization.

11. Skills Required

13. Entry and Exit Criteria

• Entry Criteria

  • Inputs and Start Criteria
    • Project Plan
    • Release Plan
    • Tasks list

• Exit Criteria

  • Customer Deliverable
    • Customer approval on the release
  • Completion Criteria
    • QA assurance on product quality
    • Statuses of tasks updated correctly
    • Actual date and hours information provided by resources.

14. Acronyms and Abbreviation