Baseel Portfolio Management runs every project, team, and delivery milestone through one governed platform — from initial workspace setup to final sign-off. It replaces scattered spreadsheets, disconnected trackers, and informal approvals with a single system of record, giving delivery leaders real-time visibility into progress, cost, quality, and risk across the entire project portfolio.
From assigning a new team member to closing out a release, every action moves through the same task engine, the same role-based access model, and the same audit log — so nothing is approved off the record, and nothing has to be reconstructed later for a stakeholder review. Beyond delivery tracking itself, the platform also gives the organization a live view of who its people are and how they're performing — through a built-in employee directory and a scored monthly performance report — so portfolio governance and workforce visibility live in the same system rather than a separate HR tool.
Project delivery often relies on disconnected systems for tasks, budgets, approvals, quality, and workforce management, making it difficult to maintain visibility, governance, and accountability across the entire project lifecycle.
Tasks, time, budgets, and risk are tracked in separate tools with no single view of project health.
Work often proceeds before sign-off, budget approval, or role authorization is actually granted.
Managers lack a clear view of who is assigned where, leading to over-commitment or idle capacity.
Fund requests and budget consumption are managed manually, with no real-time balance validation.
Defects, vulnerabilities, and code-quality signals live outside the delivery workflow, so issues surface late.
Evidence of who approved what, and when, has to be manually rebuilt for compliance or client reviews.
Who's on which team, who they report to, and how they're performing tends to live in a separate HR system disconnected from the delivery data that actually reflects it.
Baseel Portfolio Management brings Project Setup, Team & Capacity Planning, Task Delivery, Time Tracking, Sign-Off Governance, QA & Testing, Release Management, Security, Finance, Risk, Performance Analytics, and an Employee Directory onto one platform. Every project — from a small consultant engagement to a multi-team infrastructure rollout — flows through the same tracking engine, the same approval gates, and the same permanent audit trail.
Because every capability shares the same underlying engine, a task's status, its time logged, its linked risk, and its sign-off state are always in sync — without switching tools or reconciling spreadsheets by hand. The result is a platform that scales from day-to-day task management up to enterprise-grade portfolio governance, financial control, and workforce visibility.
The foundation every other module builds on — a project is never just a name and a status; it's a structured container with the classification and breakdown needed to support everything downstream.
Every project carries a defined status (Active, Planned, Completed, Archived), a priority (Low/Medium/High/Critical), and a type (Development, Consultant, Infrastructure) from the moment it's created. This classification isn't cosmetic — priority and type feed into how the project surfaces in portfolio-wide dashboards and reporting, so leadership can filter and compare projects consistently rather than relying on inconsistent naming conventions.
Projects are broken down into named modules (e.g., "Authentication," "Reporting Engine"), and this module concept isn't a cosmetic label — tasks, sign-offs, deployments, QA test cases, and fund requests can all be scoped to a specific module. This means a project's delivery can be governed and reported on at either the whole-project level or the individual-module level, depending on what a stakeholder needs to see.
Completed or discontinued projects can be archived rather than deleted, keeping historical data intact for later reference or audit without cluttering active portfolio views.
This is where a project's staffing plan becomes a governed, trackable commitment rather than an informal headcount conversation.
Team members are assigned using a purpose-built role taxonomy spanning engineering (full-stack, frontend, backend, mobile, QA, DevOps, security — each with a corresponding intern variant), leadership (team lead, solution architect, project manager, CEO/CTO/CFO/CMO/CRO/CSO), and support functions (HR, marketing, consultant). This level of specificity means capacity planning reflects the actual shape of a delivery team, not a generic "developer" bucket.
Each project defines its total planned headcount and a breakdown of how many people are expected in each role. The platform actively enforces that the sum of role allocations can never exceed the total headcount — so a project can't be planned on paper with more specialists than the budget or team size actually supports.
Adding someone to a project isn't a direct action — it's a formal request specifying which roles and how many are needed, which then routes for approval with recorded notes, a rejection reason if declined, and who made the decision and when. No one joins a project's roster without that decision being made and logged.
Independent of project-level headcount planning, the platform also enforces a lighter per-person guard against overload — capping how many active tasks, and how many high/critical-priority tasks, a single person can be juggling at once — protecting individual capacity even within an otherwise well-staffed project.
The operational core where day-to-day delivery work actually happens and gets recorded.
Tasks move through To Do, In Progress, In Review, Blocked, and Completed, carrying a priority (Low/Medium/High/Critical) and a tag describing the nature of the work (Bug, Rework, Testing, Security, Performance, Deployment, and more). This gives every task both a status and a classification, so filtering a backlog by "all open security-tagged work" or "all blocked high-priority tasks" is a first-class query, not a manual scan.
Tasks can be linked to one another as dependencies (with lag time and mandatory/optional flags), so the platform understands sequencing, not just a flat list of unrelated to-dos. Tasks can also be assigned to more than one person at once, reflecting how delivery work is actually staffed — pairs, small groups, or a lead plus a reviewer — rather than forcing a single-owner model that doesn't match real team structures. Comments are captured per task as a running discussion log; today this is a flat list rather than nested replies, so following a back-and-forth means reading the sequence in order rather than jumping to a specific reply thread.
Every transition a task goes through — its old status, its new status, when it changed, who changed it, and why — is written to a dedicated history record. This means the full lifecycle of a task, from creation to completion, can be reconstructed exactly, which matters both for retrospectives and for resolving disputes about when work actually happened.
Effort visibility that's captured as work happens, not reconstructed afterward from memory.
Timers and manual entries — Team members can start a live timer against a task while they work, or log time manually after the fact — including bulk manual entry for catching up on multiple days at once. Every manual edit to a time entry is itself tracked (who edited it and when), so time data stays trustworthy even when it's entered retroactively rather than in real time.
Daily/weekly/project reports — Effort visibility is computed live from the underlying time-entry data at every level — per task, per person, per project — rather than relying on a periodic batch report that's already stale by the time someone reads it. This feeds directly into the performance analytics and dashard views described below, so time data isn't a dead end sitting in a timesheet.
This is the platform's hardest governance control — and it's a real, enforced gate, not a soft process convention.
A module or an entire project can be submitted for sign-off, moving through Draft, Pending, Approved, Rejected, or Changes Requested. If changes are requested or the submission is rejected, it can be revised and resubmitted, opening a new round rather than silently overwriting the prior decision — so the full history of "what was asked for changes, and what changed in response" is preserved.
Every individual approver's decision — approved, rejected, or changes recommended, along with their comment — is recorded separately, so a multi-approver sign-off doesn't collapse into a single ambiguous outcome. Each resubmission bumps the version number, and a scheduled job automatically expires any sign-off that's sat in Pending status past its due date, so approvals can't be indefinitely stalled without anyone noticing.
This is enforced at the system level, not just as a UI warning: attempting to move a task into In Progress, or attempting to log time against a task — whether via timer, manual entry, or bulk entry — is actively blocked with an explicit error if the relevant module or project sign-off hasn't been approved yet. There is no way for work or time logging to proceed around an unapproved sign-off, by accident or otherwise.
Quality validation that's tied directly to the deployment it's testing, not a disconnected test-tracking spreadsheet.
Test case execution — Test cases are scoped to specific deployments and modules, and each execution is recorded with a clear pass/fail/blocked/not-run outcome. Multiple test runs can be grouped by testing type or session, so a full regression pass and a quick smoke test are both tracked, but distinguishably.
Defect lifecycle — A failed test case can generate a defect record carrying its own severity and status (Open, In Progress, Resolved, Closed), linked directly back to the specific test case and execution that surfaced it. Once a fix is in place, a structured retest request — with its own tracking number and result — drives verification before the defect is considered closed, so "fixed" is confirmed by a recorded retest, not just marked closed on trust.
Deployment activity tracked with the same rigor as everything else in the platform, including the messy reality of things going wrong.
Full deployment lifecycle — Deployments move through Planned, In Progress, Completed, Failed, Rolled Back, and Closed, each one classified by environment (Dev, Staging, UAT, Production, Client). QA pass-rate metrics are carried directly on the deployment record and kept current automatically, so a deployment's quality signal is visible at a glance alongside its status.
Rollback and redeployment support — A rolled-back deployment is explicitly linked back to the deployment it rolled back, and a redeployment is linked forward to the attempt it replaced — so a failed release and its recovery form a traceable chain, rather than looking like two unrelated events in a list.
Security posture folded directly into delivery tracking, rather than living in a separate tool only the security team looks at.
Vulnerabilities are tracked per project with severity, an assigned owner, who found it, who resolved it, and target remediation dates — giving every open vulnerability the same accountability structure as a task or a risk.
This runs as a genuine scheduled job — by default nightly — pulling quality-gate status, code coverage, and bug, vulnerability, and code-smell counts (plus reliability, security, and maintainability ratings) directly from SonarQube into the project's record. No one has to remember to manually check a separate SonarQube dashboard and copy numbers across; the sync keeps the platform's view of code health current on its own.
Real budget governance, not a spreadsheet with an approval email attached.
Project budgets are established through formal fund allocations, and any additional funding need is raised as a fund request — optionally scoped to a specific module rather than the whole project — that must be approved before it counts against the budget.
This is a server-side check performed at the moment of approval, not a UI estimate: the platform calculates the project's currently available balance (total allocated minus everything already approved, reconciled across currencies if a request is in a different currency than the allocation) and will hard-reject an approval that would push spend past what's actually available, returning the exact requested amount and the actual available balance in the error. A budget genuinely cannot be over-approved by an approver who isn't paying close attention.
Project- and module-level financial reporting is always current because it's computed from the same live allocation and request data the approval gate itself relies on — there's no separate, potentially stale reporting snapshot to reconcile against the real numbers.
Risk that's tracked with the same discipline as delivery work, scoped down to the individual task where relevant.
Likelihood × impact scoring — Risks can be logged at the project level or tied to a specific task, and every risk is auto-scored from its likelihood and impact ratings the moment it's created or updated — so severity is never a subjective label someone assigns by feel, it's a consistent, recalculated number.
Controlled close-out — A risk can't be closed through the same generic update path used for everything else; closing a risk requires going through a dedicated close action that mandates a written justification. This means the register never accumulates risks that were closed with a silent status flip and no explanation of why the exposure is considered resolved.
A scored, monthly view of delivery contribution — built directly from the same task, time, and QA data the rest of the platform already captures, rather than a separate self-reported performance process.
Monthly scored reporting — Every month, the platform computes a performance report across the portfolio, scoring developers on completed tasks and logged time entries, and testers on passed versus non-passed test executions. Because the scoring pulls directly from actual task completions, time entries, and QA execution records, it reflects what genuinely happened during delivery rather than a subjective end-of-month self-assessment.
Exportable reporting — The monthly report can be exported (CSV or PDF) for performance reviews, staffing decisions, or client-facing delivery reporting, without needing to manually compile the underlying task and time data by hand.
A live, searchable view of the organization's people — reporting lines, departments, and status — that sits inside the same platform driving delivery work.
Every employee profile is searchable and filterable by department, employment status, employment type, and work location, with sorting and pagination for larger organizations.
Each profile links into a live org chart and a paginated list of direct reports, so reporting structure is always visible and navigable rather than living in a static org-chart image that goes stale the moment someone changes teams.
An employee's department, reporting line, and employment status (including an end date when applicable) can be updated individually or in bulk, keeping the directory accurate as the organization changes.
The full directory can be exported to Excel for offline reporting or handoff to HR systems.
There's no skills or competency tracking in the directory today — no skill taxonomy, rating, or competency matrix — so staffing decisions based on specific technical skills still rely on knowing the team personally rather than searching for a skill in the directory.
Baseel Portfolio Management is built in four layers that work together end to end:
Projects, workspaces, and teams are configured with roles, capacity, and work-breakdown modules.
Task tracking, time logging, and sign-off governance share one lifecycle and one audit trail, with sign-off acting as a hard, enforced gate on task progress and time logging.
QA/Testing, Security, Financial, and Risk management validate quality, cost, and exposure across every project, each backed by genuine enforcement logic (a real balance check, a real scheduled Sonar sync, a real mandatory-justification close-out) rather than advisory-only tracking.
Role-based dashboards, monthly performance scoring, and the employee directory give every stakeholder — contributor, manager, auditor, HR — the view they need, backed by SLA timers, approval gates, and an exportable audit trail.
A new project is set up with defined roles and capacity; onboarding requests route for approval before any member is assigned, and the platform prevents planning more specialists into roles than the approved headcount allows.
A module reaches completion, is submitted for sign-off, and no further task progress or time entry is possible on that module until every approver has responded — enforced at the point someone tries to act, not just flagged after the fact.
A QA failure logs a defect with severity, tracks it through resolution, and drives a structured, trackable retest before closure.
A team requests additional funds against a project budget; the request is validated against the real available balance at approval time and rejected outright if it would overspend, before it's ever routed further.
Leadership reviews cross-project risk exposure via the portfolio dashboard before greenlighting the next release, with every risk carrying a consistent, auto-calculated severity score.
SonarQube results sync automatically overnight into the project record, surfacing vulnerabilities and quality-gate failures alongside open tasks without anyone manually checking a separate dashboard.
A manager reviews the monthly scored performance report alongside the employee directory's org chart before deciding where to allocate a new hire or reassign capacity.
One engine, every discipline — Tasks, time, QA, risk, finance, sign-off, performance, and people data all share one lifecycle and one audit trail.
Hard governance gates — Sign-off approval and fund-balance validation are enforced structurally at the point of action — work and spend cannot silently bypass authorization, not because of process discipline, but because the system itself blocks it.
Built-in financial control — Real-time budget-balance validation is native to the platform and computed from live data, not a bolted-on spreadsheet reconciled after the fact.
Native quality and security signals — SonarQube metrics sync automatically on a schedule, no manual reporting required.
Configurable without custom code — Roles, permissions, and approval routing are all admin-configurable, including a genuine three-tier access model (manage a project, elevated portfolio-wide access, audit-log access) settable per organization, role, or user.
Full exportable audit trail — Every action — task, sign-off, fund, or risk — is permanently recorded and exportable in CSV, XLSX, or PDF for review.
Delivery and workforce visibility in one place — Performance scoring and the employee directory sit natively alongside delivery tracking, so staffing and performance decisions can be made against the same data driving the work itself.
Talk to our team to see a live demo tailored to your requirements.
Fill in the form below and our team will get back to you shortly.