Author: Mark Whitfield

Welcome to my site! After graduating in Computing in 1990, I accepted a position as a programmer at a Runcorn based software house specialising in electronic banking software, namely sp/ARCHITECT-BANK on Tandem Computers (now HPE NonStop). This was before the internet became more prevalent and so the notion of enabling desktop access to company accounts for inter-account transfers and book keeping was still quite a cutting edge idea (and smartphones only ever hinted at in Space 1999). The company was called The Software Partnership (which was taken over by Deluxe Data in 1994). I spent 5 years in Runcorn developing code for SP/ARCHITECT for various banks like TSB, Bank of Scotland, Rabobank and Girofon (Denmark) to name but a few. I then moved onto a software house in Salford Quays for further bank facing projects. After a further 23 years in the IT industry and now a Senior IT Project Manager (both Agile and Waterfall delivery), I thought I would echo out my Career Profile in this corner of the internet for quick and easy access.

Over 200 editable templates for both Agile & Waterfall / PRINCE2 frameworks

Mark Whitfield’s Project Management (PM) methodology relies on over 200 editable templates tailored for both Agile Scrum and Waterfall / PRINCE2 frameworks. Developed over 24 years of IT and digital delivery, the toolkit focuses on high-level reporting, rigorous risk control, and visual tracking to align teams with corporate governance.

Over 200 editable templates for both Agile & Waterfall / PRINCE2 frameworks
An example of many Plan On a Page
(POAP) templates

Templates by Category and Methodology

1. Detailed Planning & Scheduling

  • Methodology: Mapped to the Software Development Life Cycle (SDLC) for both sequential Waterfall phases and iterative Agile sprints.
  • Templates:
    • Microsoft Project (MPP): Fully loaded schedules detailing project inception, elaboration, construction, and transition.
    • Excel Detailed Plans: Work Breakdown Structure (WBS) mapped to sequential and date-driven task management with built-in RAG (Red/Amber/Green) status indicators.

2. Visual Reporting & Execution (Plan on a Page)

  • Methodology: Focuses on structural, executive communication to prevent scope creep and keep stakeholders aligned.
  • Templates:
    • POaP (Plan on a Page): High-level visual summaries designed for client presentations and quick-glance milestone tracking in Excel and PowerPoint.
    • Burn-up / Burn-down Charts: Visual tracking metrics used in Agile Sprints to show progress towards delivery goals.

3. Risk & Governance Control

  • Methodology: Built on strict risk/action tracking and regular lessons learned to manage uncertainty throughout the project lifecycle.
  • Templates:
    • RAID Log: Centralized Excel trackers recording Risks, Actions, Issues, and Dependencies.
    • Change Requests/Decisions Log: Supplementary tabs within the RAID register to strictly manage scope changes and project governance.

4. Financial Trackers

  • Methodology: Ensures project adherence to contracted margins, tracking both internal/external costs and resource efforts.
  • Templates:
    • Budget & Resource Trackers: Spreadsheets for forecasting versus actual expenses, variance calculations, expense reporting, and margin tracking with pivot-table readiness.

5. Team RACI & Status Reporting

  • Methodology: Clearly defines stakeholder roles and communication frequencies (weekly/monthly) to ensure continuous monitoring and control.
  • Templates:
    • RACI Matrix: A mapping tool defining who is Responsible, Accountable, Consulted, and Informed.
    • Weekly Status Reports: Word/Excel templates detailing internal and external project health, current milestones, and upcoming sprints.

To explore the entire toolkit, you can visit the Mark Whitfield PROject Templates portal.

Empiricism is the foundational theory of the Scrum framework

Empiricism is the foundational theory of the Agile Scrum framework, asserting that knowledge comes from experience and that decisions should be based on real-world observations rather than upfront predictions. Instead of following a rigid, predefined plan, Scrum relies on an iterative process to navigate complex and unpredictable environments. This empirical process control model is sustained by three distinct pillars.

The Three Pillars of Empiricism

The Three Pillars of Empiricism
The Three Pillars of Empiricism

The Scrum Guide specifies three pillars that must work together to create an effective empirical feedback loop:

  • Transparency: The significant aspects of the process must be visible to those responsible for the outcome. Decisions are driven by the perceived state of artifacts, which means any hidden issues or misreported metrics directly sabotage future decision-making.
  • Inspection: Scrum artifacts and progress toward agreed goals must be evaluated frequently and diligently. This continuous assessment identifies unwanted variances or deviations from the desired outcome.
  • Adaptation: If an inspection reveals that aspects of a process or product deviate outside acceptable limits, the team must adjust immediately. An adjustment must be made as quickly as possible to minimize further deviation.

How Scrum Events Enable Empiricism

Inspection and adaptation cannot happen in a vacuum. Scrum provides four formal events that act as a structured cadence for empirical evaluation:

  • Sprint Planning: The team inspects the Product Backlog and adapts their upcoming workload to define a realistic Sprint Goal.
  • Daily Scrum: Developers inspect progress toward the Sprint Goal and adapt their immediate daily plan.
  • Sprint Review: The team and stakeholders inspect the newly created product increment to adapt the Product Backlog for future value.
  • Sprint Retrospective: The team inspects their internal dynamics, tools, and processes to adapt how they operate in the next Sprint.

The Critical Role of Trust

Empiricism fails without a baseline culture of trust and psychological safety. For transparency to occur, team members must possess the courage to share bad news and highlight product deficiencies early. When individuals fear blame, they hide reality—rendering subsequent inspection flawed and any adaptation completely wasteful.

Project Plan on a Page (POAP) is a Concise, Visual Summary of a Project

A Project Plan on a Page (POAP) is a concise, visual summary of a project’s objectives, timeline, milestones, and risks. Its primary purpose is to provide an instant, high-level overview for stakeholders and executives, ensuring alignment without overwhelming them with low-level details.

3. Project Plan on a Page (POAP) is a Concise, Visual Summary of a Project
4. Project Plan on a Page (POAP) is a Concise, Visual Summary of a Project
1. Project POAP by Mark Whitfield, Plan on a Page
1. Project POAP by Mark Whitfield, Plan on a Page
Mark Whitfield POAP examples, 35+ in all

Best Structure for a POAP

An effective POAP eliminates excessive task lists in favor of a clean, scannable layout organized into these key sections:

  • Project Overview: Title, Project Manager, and the overarching “Why” or business objective.
  • Timeline & Milestones: A horizontal, time-phased bar chart mapping the project’s key phases (e.g., Initiation, Beta Launch, Go-Live).
  • Key Deliverables: 4 to 6 major outputs or goals required to consider the project a success.
  • Risks & Dependencies: Critical blockers or assumptions that require management attention.

Examples & Templates for Download

Because POAPs are highly visual, they are most effectively built in Excel (for data and dates) or PowerPoint (for visual presentation).

  • Excel/PowerPoint Templates: You can download ready-made POAP layouts via Titanium Consulting or Mark Whitfield Consulting to generate professional visual graphics.
  • Word/Spreadsheet Variations: For simpler initiatives, you can access the 1-page summary templates available through Smartsheet’s Project Plan Templates.
  • Automated Software: If you already track complex projects in MS Project, Excel, or Primavera, automation tools like SummaryPro can automatically ingest your detailed schedule and spit out an accurate POAP.

Enterprise Data Governance, Business Ownership to Trusted Data Value

Enterprise Data Governance, Business Ownership, Trusted Data Value
Text : Enterprise Data Governance > Business Ownership > Trusted Data Value
Enterprise Data Governance > Business Ownership > Trusted Data Value

Business Requirements Document, BRD Key Sections

Business Requirements Document, BRD Key Components
BRD Key Sections

A Business Requirements Document (BRD) details what a project must accomplish and why it matters to the organization, acting as a bridge between business stakeholders and technical execution teams.

Here is a summary of the core sections required to construct a comprehensive BRD:

1. Document Control

  • Version History: Tracks changes, authors, and dates to ensure everyone uses the current iteration.
  • Approvals: Formal sign-off section where stakeholders authorize moving the project forward.

2. Executive Summary

  • Project Overview: A brief one-page overview stating the essence and main purpose of the project.
  • Needs Statement: Outlines the core business challenges or opportunities the project solves.

3. Project Scope & Objectives

  • Project Objectives: High-level, measurable targets aligned with company goals, often using SMART criteria.
  • In-Scope: Clear boundaries stating exactly what deliverables or processes are included.
  • Out-of-Scope: Explicit list of features or tasks intentionally left out to prevent scope creep.

4. Stakeholder Analysis

  • Key Stakeholders: Identifies project sponsors, department heads, and end-users.
  • Roles & Responsibilities: Maps out who provides requirements, who reviews them, and who receives deliverables.

5. Process Specifications

  • Current State (AS-IS): Maps current operational workflows to illustrate existing bottlenecks.
  • Future State (TO-BE): Details the desired future process after implementing the solution.

6. Core Requirements

  • Business Requirements: The high-level operational goals and capabilities the system must offer.
  • Functional Requirements: Descriptions of specific system tasks or behaviours from a business user perspective.
  • Non-Functional Requirements: Standards for performance, system security, and scalability.

7. Financial & Strategic Analysis

  • Cost-Benefit Analysis: Compares estimated financial expenses against anticipated business gains.
  • Success Metrics: Defines Key Performance Indicators (KPIs) and expected Return on Investment (ROI).

8. Project Dynamics & Risk Management

  • Assumptions: Unverified elements assumed to be true for the project to progress.
  • Constraints: Fixed limitations such as budget, time, technology, or legal compliance.
  • Risks & Mitigation: Potential threats to project delivery paired with backup action plans.
  • Dependencies: External factors or other projects that this initiative relies on to succeed.

9. Supporting Documentation

  • Acceptance Criteria: The standards and conditions required for stakeholders to accept the final delivery.
  • Glossary: Clear definitions of industry terms and acronyms used throughout the document.

Agile Scrum Artifacts and Commitments

Artifacts and Commitments in Scrum
Scrum Artifacts & Commitments
Agile Scrum Artifacts and Commitments
Agile Scrum Artifacts and Commitments

Agile Scrum Master versus Project Manager

The fundamental difference in project delivery ownership is that a Project Manager (PM) owns the overall project outcomes (Scope, Schedule, Budget, Risks), whereas a Scrum Master (SM) owns the delivery process, team effectiveness, and Agile practices.

Scrum Master vs Project Manager –
who owns delivery

A PM directs what needs to happen externally, while an SM coaches how the team works internally.

Agile Scrum Master versus Project Manager
Scrum Master vs Project Manager
Scrum Master vs Project Manager

Detailed Ownership Breakdown

1. Scope, Requirements, and Product Backlog

  • Project Manager: Directly manages the agreed-upon project scope. They review change requests, evaluate how scope changes impact the budget, and negotiate modifications with stakeholders. They are legally or contractually accountable for delivering the specified scope.
  • Scrum Master: Holds no direct ownership over the product content or scope. Instead, they coach the Product Owner on how to effectively manage the Product Backlog, draft clear user stories, and refine items for upcoming sprints.

2. Schedule, Milestones, and Timeline

  • Project Manager: Owns the macro-level timeline. They track critical path milestones, define task dependencies across multiple teams, and are accountable to executive management if a delivery deadline is missed.
  • Scrum Master: Owns the micro-level iteration cadence (sprints). They do not assign tasks or dictate schedules. Instead, they facilitate Sprint Planning, ensuring the team commits to a sustainable pace of predictable delivery.

3. Budget and Financial Accountability

  • Project Manager: Fully owns the project’s financial performance. They forecast costs, track actual spend against the budget, manage vendor contracts, and seek approval for capital expenditures.
  • Scrum Master: Has zero financial accountability or budget ownership. Their focus is entirely operational—maximizing value and efficiency through team performance rather than managing corporate balance sheets.

4. Issue Resolution and Risk Management

  • Project Manager: Focuses on long-term, macro-level risks (e.g., market shifts, organizational changes, vendor failures). They maintain formal risk registers and coordinate executive-level mitigation plans.
  • Scrum Master: Focuses on immediate, tactical impediments. They own the removal of daily “blockers”—such as technical hurdles, broken tools, or communication gaps—that slow down the development team.

5. Team Governance and Task Assignment

  • Project Manager: Operates with a directive or orchestrating leadership style. They often assign work packages, manage resource utilization, and hold individuals accountable for specific task deadlines.
  • Scrum Master: Operates as a servant-leader and coach. They have no direct authority over team members and do not assign tasks. They empower the team to self-manage, collaborate, and decide collectively how to accomplish the work.

Summary of Success Metrics

  • The Project Manager succeeds when the project is delivered on time, within budget, and according to specifications.
  • The Scrum Master succeeds when the team becomes highly self-managing, continuously improves, and predictably delivers increments of high value.

Gap Analysis in Agile Projects, Detailed Breakdown

In Agile projects, gap analysis shifts from a heavy upfront documentation exercise to a dynamic, continuous evaluation of the difference between your product’s current capabilities and your user’s actual needs.

Instead of building massive compliance checklists, Agile teams break gaps down into functional, team-level increments embedded directly into product development loops.

🛠️ How Gap Analysis Maps to Agile Artifacts

Agile doesn’t use a standalone “Gap Analysis Report”. Instead, gaps are converted directly into standard Agile artifacts to keep the delivery team moving:

  • The Epic Level (Strategic Gaps): Large operational or technical gaps (e.g., “System lacks multi-factor authentication”) are captured as Epics.
  • The User Story Level (Functional Gaps): Epics are sliced down into smaller, testable User Stories that represent a single increment of closing that gap (e.g., “As a user, I want to receive an SMS verification code to secure my login”).
  • The Backlog (Prioritisation): Identified gaps are estimated, given a business value, and ranked directly alongside feature requests in the Product Backlog.

📋 The 4-Step Agile Gap Process Breakdown

Agile teams continuously execute gap analysis iteratively through four distinct stages:

1. Define the Current State (Where We Are Now)

  • Action: Evaluate the existing performance or architecture using live metrics, user research, and current automated test results.
  • Agile Tool: Review system metrics, customer churn data, or velocity charts during Retrospectives. Avoid vague complaints; stick strictly to measurable facts.

2. Envision the Desired Future State (Where We Want to Be)

  • Action: Define target benchmarks or expected system behavior.
  • Agile Tool: Leverage the Product Vision, user personas, acceptance criteria, or your team’s Definition of Done (DoD) to serve as the baseline future state.

3. Identify and Analyze the Gap (The “Why”)

  • Action: Highlight the specific differences between performance and goals, then uncover the underlying reasons.
  • Agile Tool: Run a Five Whys session or build a Fishbone Diagram during sprint planning to see if the gap is caused by legacy code (Technology), missing skillsets (People), or inefficient workflows (Process).

4. Build the Action Plan (The Bridge)

  • Action: Convert the necessary fixes into work items.
  • Agile Tool: Map the required changes directly into the Sprint Backlog as User Stories, technical spikes (research tasks), or non-functional requirements to be delivered in upcoming iterations.

⏱️ When Gap Analysis Happens in the Agile Lifecycle

Rather than an administrative phase at the very beginning of a project, gap analysis is integrated throughout standard Agile ceremonies:

  • Product Discovery: High-level gap analysis ensures the initial product backlog addresses actual target user needs instead of internal assumptions.
  • Sprint Planning: The team evaluates the gap between the sprint goal and the current codebase to pick the right stories.
  • Sprint Review / Demo: Stakeholders compare the working increment against their expectations. This immediately exposes any emerging functional or alignment gaps.
  • Retrospectives: The team conducts an internal process gap analysis to evaluate how they collaborate, uncovering process bottlenecks or technical debt.

Gap Analysis in Agile Projects, Detailed Breakdown