Download Templates for Project Management | FREE Upgrades & Additions
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.
BRD vs FRD, Business Requirements vs Functional Requirements
The primary difference between a Business Requirement Document (BRD) and a Functional Requirement Document (FRD) is that the BRD focuses on “why” a project is needed (business objectives), while the FRD details “how” the system will work to meet those needs. The BRD serves stakeholders and leadership, whereas the FRD guides developers and technical teams.
Key Differences at a Glance:
BRD (Business Requirements Document):
Goal: Defines business objectives, goals, and high-level needs.
Key Content: Business problem, scope, ROI, high-level project goals.
FRD (Functional Requirements Document):
Goal: Translates business needs into detailed technical functionalities.
Focus: “How” the system will perform to meet requirements.
Audience: Developers, Testers, Technical Team, Business Analysts.
Key Content: Feature descriptions, user interactions, system workflows, data requirements, UI mockups.
How They Work Together: The BRD is created first to get approval for the project, while the FRD is developed based on the approved BRD. The FRD ensures the project is actionable, testable, and feasible. In Agile, these are often combined into smaller artifacts like User Stories.
Mark Whitfield is a highly experienced, SC-cleared Senior Project Manager and IT professional with over 31 years of experience in both public and private sectors, specializing in software development, cloud migration, and IT systems delivery.
He is currently associated with Capgemini (since 2016) and runs a project management resource website, PROject Templates.
Joined Capgemini in 2016 having worked at ascending points in software development lifecycle projects for over 31 years
Key Qualifications & Experience:
Roles: Senior Project Manager, Engagement Project Manager, Delivery Manager, and former programmer.
Methodologies: PRINCE2 Practitioner, skilled in both Waterfall and Agile (SCRUM) approaches.
Sector Experience: Extensive experience in finance and banking, including ATM software swap-outs, cloud migration (Azure, AWS, Power Platform), and POS monitoring systems.
Background: Graduated in Computing in 1990; worked as a developer (COBOL, SQL, Tandem / HPE NonStop) before transitioning to project management.
PRINCE2 Practitioner, skilled in both Waterfall and Agile (SCRUM) approaches
Professional Highlights:
Delivered major projects for clients such as Barclays, Bank of England, HSBC, Royal Mail Group, UK & Welsh Government, Heathrow, and Jaguar Land Rover.
Led complex IT infrastructure projects and business transformations.
Maintains mark-whitfield.com, offering over 200 project management templates, trackers (RAID, budget, benefit, cost etc.), and many plans for Agile / Waterfall projects including 30+ Plan On a Page (POaP) and MS Project MPP examples (click on Blog above for a summary).
Provides specialized templates for PRINCE2 7th edition and MS Project (MPP).
December 2022 – C&CA UK’s Communications & Engagement Award Winner – Cloud & Custom Applications – Capgemini UKNovember 2017 – Advanced Engagement Management Course – Level 2 ExamJune 1990 – Higher National Diploma in Computer Studies, Distinction
As of 2026, AI is transforming project management by automating scheduling, risk management, and reporting. The best AI courses for project managers (PMs) focus on practical application, generative AI, and AI governance.
Top AI Courses and Certifications for Project Managers
PMI Certified Professional in Managing AI (PMI-CPMAI) (PMI)
Summary: The premier certification for managing AI projects from start to finish, including data prep and model deployment.
Best For: Advanced specialists managing AI projects.
Prioritization in AgileScrum is the systematic process of ordering Product Backlog items to maximize value delivery. These techniques are generally categorized by their primary focus: customer satisfaction, business value and economics, or collaborative consensus.
Category 1: Customer-Centric Frameworks
These methods prioritize features based on how they impact the end-user’s experience and satisfaction.
Kano Model: Categorizes features into three main types: Basic Needs (expected essentials), Performance Features (linear satisfaction), and Excitement Needs (unexpected “delighters”).
User Story Mapping: Visualizes the entire user journey to identify the most critical paths and “skeletal” features needed for a Minimum Viable Product (MVP).
Opportunity Scoring: Uses customer research to find gaps where importance is high but current satisfaction is low, identifying high-potential opportunities.
Category 2: Economic & Quantitative Models
These data-driven techniques use formulas to balance value against implementation costs or risks.
Weighted Shortest Job First (WSJF): Prioritizes tasks by dividing the Cost of Delay (value, urgency, and risk reduction) by Job Size (effort). The goal is to deliver the most value in the shortest time.
RICE Scoring: Calculates a score based on Reach (number of users), Impact, Confidence (certainty in estimates), and Effort.
Cost of Delay (CoD): Measures the economic impact or potential revenue loss of not delivering a feature within a specific timeframe.
Category 3: Stakeholder & Team-Based Consensus
These collaborative methods are used to reach agreement among diverse stakeholders or team members.
MoSCoW Method: A qualitative technique that buckets items into Must-Have, Should-Have, Could-Have, and Won’t-Have for a specific release cycle.
100-Dollar Test: Participants are given a hypothetical $100 to “spend” on features, revealing what they value most through resource allocation.
Priority Poker: A gamified, collaborative approach where team members anonymously vote on an item’s priority level to remove bias and foster discussion.
Category 4: Structural & Visual Matrixes
These tools help teams visualize trade-offs, typically using 2×2 grids.
Value vs. Effort Matrix: Plots tasks on two axes to identify Quick Wins (high value, low effort) and Major Projects (high value, high effort) while avoiding “thankless tasks”.
Risk/Value Matrix: Balances potential business rewards against technical or project risks to decide which high-value but high-risk items to tackle early.
Stack Ranking: A “forced ranking” method where every item has a unique, linear position (1 to N), preventing the “everything is high priority” trap.