Continuous improvement depends on clear, well-defined change requests. Whether the request is a small enhancement, a logic correction, or a larger structural improvement, good change information allows the right people to assess, prioritise, and deliver efficiently.
Poorly defined requests create delay, rework, and misunderstanding. Well-raised changes move faster.
This guide explains how to raise a change request for data, reporting, and analytics services.
Before Raising a Change
Please first consider:
Is it already known?
Check:
- Recent Changes
- Breaking Changes Register
- Existing backlog items
- Current incidents or planned releases
The request may already be in progress.
Is it a defect, question, or change?
Use the right route:
- Question – how something works, where to find information
- Incident – something broken or unavailable
- Change – modify, improve, add, remove, or redesign something
Correct routing helps faster resolution.
What Good Change Requests Include
Please provide as much of the following as practical.
1. Clear Title
Use a short title describing the request.
Examples:
- Add Project Manager Email to Project Details
- Correct Opportunity Status Mapping
- Improve Refresh Reliability for Finance Model
- Add Customer Filter to Pipeline Dashboard
2. Business Reason
Explain why the change matters.
Examples:
- Reduces manual work
- Improves reporting accuracy
- Supports month-end process
- Needed for stakeholder decision-making
- Resolves recurring user confusion
Requests linked to value are easier to prioritise.
3. What Needs to Change
Describe the desired outcome in plain English.
Examples:
- Add a new column showing contract owner
- Reclassify closed opportunities separately from lost
- Reduce refresh failures during peak periods
- Allow filtering by operating region
Focus on the result, not the technical implementation.
4. Affected Area
Please identify where the change applies.
Examples:
- Power BI report
- DataMart view
- Dataflow
- Dashboard page
- API feed
- WordPress / KnowHow page
5. Priority / Timing Need
When is it needed?
Examples:
- Nice to have
- This month
- Before period-end
- Before audit review
- Required for programme milestone
6. Evidence (Highly Helpful)
Where possible include:
- Screenshot
- Example rows
- Current vs expected result
- Report page name
- Error message
- Calculation example
Evidence reduces back-and-forth.
Example Good Request
Title: Add Project Director to Project Dashboard
Reason: Senior leadership need ownership visibility during monthly reviews.
Change Needed: Add Project Director as filter and visible column.
Affected Area: Project Dashboard / Project Details dataset.
Needed By: Before next monthly review.
Evidence: Screenshot attached of current dashboard.
Example Weak Request
Dashboard wrong. Please fix urgently.
This creates delay because the issue is unclear.
How Requests Are Assessed
Requests are typically reviewed against:
- Business value
- Complexity
- Risk level
- Change Level classification
- Dependencies
- Delivery capacity
Not all requests will be immediate, but all should be clearer with good input.
Helpful Principles
Be specific
Clear requests move faster.
Be outcome-led
Describe what success looks like.
Be realistic on urgency
Everything cannot be urgent.
Avoid prescribing solutions too early
Describe the need first. There may be a better route.
If Unsure
If you are not certain whether something is a change, raise it anyway with the best information available. Early discussion is better than silent frustration.
Related Guidance
See also:
- Safe Data Explained
- Change Levels Matrix
- Recent Changes
- Release Calendar
- Breaking Changes Register
Final Note
Good change management starts with good requests. A few clear sentences at the start can save days later.