Business consultant partner

Business Consultant Partner — Production Business Standard

ENFORCEMENT RULES — READ FIRST

This standard is MANDATORY for every business deliverable. These rules cannot be overridden by tight timelines, client pressure, or "we will document it later."

Before producing any business deliverable, verify:

1. Every requirement traces back to a documented pain statement
2. Every process has a defined owner (single person, not a team)
3. Every process has documented exception handling
4. Every requirement is testable — QA can write a test case from it
5. Scope includes an explicit exclusion list (what is OUT)
6. The client's vocabulary is used throughout, not the platform's vocabulary
7. Business rules are separated from process flows as a distinct catalog
8. Implementation timeline includes assumptions, dependencies, and risks

After producing deliverable, audit for:

• Requirements written as feature lists instead of business needs
• Happy-path-only process flows (no exceptions, no escalations, no timeouts)
• Ambiguous acceptance criteria ("system should be fast," "user-friendly")
• Missing stakeholder sign-off section
• Business rules referencing specific people instead of roles
• Scope defined only by inclusion, not exclusion
• Timeline without assumptions or dependencies listed

---

THREE-QUESTION RULE — EVERY REQUIREMENT

Before writing any requirement, answer these three questions:

1. Who needs this? (Specific role — "Procurement Manager," not "users")
2. What do they need to accomplish? (Business outcome — "approve POs within 24 hours," not "approval workflow")
3. What happens if they cannot? (Business impact — "PO delays cascade to production schedule, costing $X per day")

If the answer to question 3 is "nothing significant," the requirement is a nice-to-have. Prioritize accordingly.

// WRONG — feature list masquerading as requirements
- Add dropdown for status field
- Create approval workflow with 3 levels
- Generate PDF report

// RIGHT — business needs with context
REQ-001: Procurement Manager must approve purchase orders above 5 lakh
         within 24 hours of submission.
         Impact if unmet: Production delays. Average cost: 50K/day.
         Acceptance: PO submitted at 9 AM, approver notified within 5 min,
         approval/rejection recorded with timestamp and comments within 24h.

---

REQUIREMENT QUALITY STANDARDS

Every requirement MUST be:

Specific

// WRONG
"Notifications should be timely"
"The system should handle large volumes"
"Reports should be user-friendly"

// RIGHT
"Approval notification sent within 5 minutes of submission"
"System processes 10,000 records without page load exceeding 3 seconds"
"Report renders in under 2 seconds for date ranges up to 12 months"

Testable

A QA engineer can write a test case from the requirement without asking the author for clarification.

// WRONG — untestable
"System should be intuitive"
"Approvals should be routed appropriately"
"Data should be accurate"

// RIGHT — testable
"New user completes first PO submission within 3 minutes without documentation"
"PO above 10 lakh routes to CFO. PO below 10 lakh routes to Department Head."
"Invoice total equals sum of line items x quantity + tax. Tolerance: 0."

Traceable

Every requirement connects backward to a pain statement and forward to test cases.

PAIN:   "Purchase approvals take 3-4 weeks because approvers lack context"
  -> REQ-001: "Approval package includes attached documents, requestor notes,
              budget remaining, and prior approvals for same vendor"
    -> TEST: "Approver opens notification, sees all 4 context items
             without navigating to another screen"

Prioritized (MoSCoW)

• Must Have — system does not function without it
• Should Have — significant value, can launch without it
• Could Have — nice to have, build if time allows
• Won't Have — explicitly out of scope for this phase

Never: "all high priority." If everything is priority 1, nothing is.

---

REQUIREMENT DOCUMENT STRUCTURE

Every requirement document includes these sections in this order:

1. Pain Statement

What specific business problem does this solve? Quantified where possible.

"Purchase approvals currently take 21-28 days across 6 manual handoffs.
Each day of delay on a capital PO costs approximately 50,000 in idle project time.
The approval chain has no audit trail. Two regulatory findings in the last audit
traced to undocumented approval decisions."

2. Scope — Inclusion AND Exclusion

IN SCOPE:
- Purchase order approval workflow (3 levels based on amount thresholds)
- Capital expenditure approval workflow (4 levels with board approval above 1 Cr)
- Notification to approvers via email and in-app
- Full audit trail with timestamps, approver identity, and comments

OUT OF SCOPE (explicitly excluded):
- Vendor onboarding workflow (Phase 2)
- Integration with SAP for PO creation (Phase 2)
- Mobile approval interface (Phase 2)
- Expense reimbursement workflow (separate project)

Never: scope defined only by what is included. Exclusions prevent scope creep.

3. Requirements Table

ID	Requirement	Priority	Acceptance Criteria	Pain Ref
REQ-001	PO above 10L routes to CFO	Must Have	PO for 15L submitted, CFO notified within 5 min	PAIN-001
REQ-002	Approver sees full context	Must Have	Notification shows: amount, vendor, budget remaining, documents	PAIN-001
REQ-003	Approval aging visible to admin	Should Have	Dashboard shows POs pending > 48h with approver name	PAIN-002

4. Business Rules Catalog

Separated from the process flow. Rules change more frequently than processes.

5. Assumptions

- Client IT team provides ERP API access within 2 weeks of Phase 1 kickoff
- Approval thresholds are as documented in Finance Policy v3.2
- Maximum concurrent users: 200
- All approvers have email access

6. Sign-off

Stakeholder	Role	Sign-off Date
[Name]	Finance Head
[Name]	IT Head
[Name]	Process Owner

---

BUSINESS RULE SPECIFICATION

Rule Structure — Every Rule

Field	Description	Example
Rule ID	Unique identifier	BR-001
Rule Name	Human-readable	"Capital expenditure approval threshold"
Condition	Logical condition	IF amount > 50 lakh AND category = "CAPEX"
Action	What happens when true	THEN route to CFO, MD, Board
Otherwise	What happens when false	ELSE route to Department Head only
Source	Where this rule is documented	Finance Policy v3.2, Section 4.1
Change Authority	Who can modify	CFO only
Effective Date	When it takes effect	01-Apr-2026
Review Frequency	How often re-validated	Annual, with budget cycle

Rule Anti-Patterns — Reject on Sight

// WRONG — references a person
"Route to Raj for approval"                    <- What happens when Raj leaves?

// RIGHT — references a role
"Route to Finance Head for approval"           <- Role persists. Person changes.


// WRONG — ambiguous condition
"Route to appropriate approver"                <- Who decides "appropriate"?

// RIGHT — explicit condition
"IF amount > 10 lakh THEN CFO. ELSE Dept Head" <- Deterministic. Testable.


// WRONG — conflicting rules with no priority
Rule A: IF amount > 5L, approve
Rule B: IF vendor = new, reject               <- What if amount > 5L AND vendor = new?

// RIGHT — priority ordering
Rule A (Priority 1): IF vendor = new, route to Vendor Review regardless of amount
Rule B (Priority 2): IF amount > 5L, route to CFO
Rule C (Priority 3): ELSE route to Dept Head


// WRONG — rule embedded in process description
"...and then the system checks if the amount is over the threshold
 and routes accordingly..."

// RIGHT — rule in separate catalog
Process references: "Apply BR-001 (CAPEX approval threshold)"
BR-001 maintained separately with change authority and review frequency.

---

PROCESS MAPPING

Notation Rules

• Swimlanes for cross-departmental processes. Each lane = a role, not a person.
• Start event labeled with trigger ("New PO submitted," "Invoice received via email").
• End event labeled with outcome ("PO approved and sent to ERP," "Invoice rejected and vendor notified").
• Decision gateways: every path labeled with the condition. Never an unlabeled path.
• Exception paths: visually distinct (dashed lines or separate exception lane).
• Time-based events (SLA breaches, expiry, scheduled triggers) explicitly shown. Never assumed.
• Data flow indicated alongside control flow. Not just "what happens next" but "what data moves."

Process Checklist — Verify Before Finalizing

1. Exactly one start event?
2. Every path leads to an end event? (No orphan branches)
3. Every decision gateway has labeled conditions for each path?
4. Exception path documented? (What happens when the process stalls)
5. All cross-role handoffs explicit? (Not assumed)
6. SLA for each step documented?
7. Escalation rules defined for SLA breach?
8. Can this process run as multiple instances simultaneously?
9. Data flow between steps documented? (Not just control flow)
10. Validated against a real recent case? (Not hypothetical)

// WRONG — process mapping failures
Start: "Process begins"                       <- What triggers it? Be specific.
Gateway: one path labeled "Yes," other unlabeled <- Where does "No" go?
Step 3 decision with no "No" path             <- Orphan branch.
"The approver approves the request"            <- No SLA. No escalation. No timeout.
Single lane called "Team"                      <- Which role does what?

// RIGHT
Start: "Vendor submits invoice via email"
Gateway: "Amount > 10L?" -> Yes: "Route to CFO" / No: "Route to Dept Head"
Every path terminates in a labeled end event
"Approver reviews within 48h. If no action by 48h, escalate to next level."
Swimlanes: Vendor | Procurement | Finance | Approver | System

---

EXCEPTION HANDLING — NON-NEGOTIABLE

Every process has exceptions. A process without documented exceptions is incomplete. Reject on review.

Exception Documentation Structure

For every process, document:

Field	Description
What constitutes an exception	"Vendor is travelling. Cannot provide physical signature."
Who can raise it	"Deal manager raises exception request"
Who approves it	"Regional head approves with documented justification"
Time boundary	"Exception valid for 14 calendar days from approval"
What happens on expiry	"System escalates to compliance. Exception auto-revoked."
Audit trail	"Exception approval, justification, expiry, resolution logged"

// WRONG
"Exceptions handled by manager"                <- Which manager? How? No audit trail.
"Edge cases addressed as needed"               <- Not a design. An abdication.

// RIGHT
Exception: KYC document not available within standard window
Raised by: Deal manager via exception request form
Approved by: Compliance head
Duration: 14 calendar days
On expiry: System blocks deal progression. Compliance notified.
Logged: Approver, justification, timestamp, expiry date, resolution.

---

VERTICAL-SPECIFIC DOMAIN VOCABULARY

Use ONLY these terms when working in these verticals. Platform terms (Data List, Flow, Field) are for internal use only.

Manufacturing

Platform Term	Client Term
Data List	Register / Log / Record
Data List Entry	Record / Entry / Item
Flow	Process / Workflow / Procedure
Flow Step	Stage / Step / Station
Field	Attribute / Parameter / Specification
Report	Dashboard / Report / Analysis

Domain terms: BOM, routing, work center, traveler, FAI, deviation report, NCR, CAPA, ECO, GRN, AQL.

Financial Services

Platform Term	Client Term
Data List	Register / Ledger / Pipeline
Data List Entry	Deal / Transaction / Record
Flow	Process / Workflow / Lifecycle
Report	Dashboard / Portfolio View / Report

Domain terms: LP, GP, capital call, distribution, waterfall, carried interest, NAV, management fee, subscription document, side letter, UBO, KYC/AML, NDA, IC memo, CIM, term sheet, pre-disbursement, conditions precedent.

Garment / Textiles

Platform Term	Client Term
Data List	Register / Record / Book
Data List Entry	Order / Style / Entry
Flow	Process / Workflow

Domain terms: cut plan, katta, marker efficiency, fabric consumption, AQL inspection, lab dip, strike-off, PP sample, TOP sample, B/L, LC, shipping mark.

EPC / Industrial / Energy

Platform Term	Client Term
Data List	Register / Log / Tracker
Data List Entry	Request / Authorization / Record
Flow	Process / Workflow / Approval Chain

Domain terms: CAPEX, OPEX, AFE, change order, punch list, commissioning protocol, P&ID, preservation plan, work permit, safety induction, method statement.

---

IMPLEMENTATION PLANNING

Scoping Rules — Non-Negotiable

• Phase 1 is ALWAYS one high-impact process. Not five. Not the department. One process. Weeks, not months. Builds momentum.
• Scope by exclusion. "Includes X, Y, Z. Excludes A, B, C." Exclusions prevent scope creep.
• Estimate in ranges. "2-3 weeks" not "2 weeks." Ranges communicate uncertainty.
• List dependencies explicitly. "Requires ERP API access (IT estimates 2 weeks). If delayed, timeline shifts."
• Never estimate without assumptions. Every number depends on conditions. State them.

// WRONG
"Implementation: 6 weeks"

// RIGHT
"Implementation: 4-6 weeks
 Assumptions:
 - Client provides ERP API access by Week 1
 - Approval thresholds confirmed by Finance by Week 1
 - Max 200 concurrent users
 - 3 approval levels (not 5)
 Dependencies:
 - IT team availability for integration testing (Weeks 3-4)
 Risks:
 - If ERP API delayed: +2 weeks
 - If approval levels increase from 3 to 5: +1 week"

Risk Register — Required for Every Implementation

These four risks MUST be assessed for every implementation. They occur in 80%+ of enterprise projects.

Risk	Probability	Impact	Mitigation	Contingency
Key stakeholder leaves	Medium	High	Document all decisions with rationale	Reassign to deputy with context transfer in 48h
Requirements change after build	High	Medium	Change control process. Impact assessment for every change.	Defer to Phase 2 if impact > 1 week
Data quality worse than expected	Medium	High	Data audit in Week 1 before build	Additional 1-2 weeks for cleanup
User adoption resistance	Medium	High	Involve end users in testing from Week 2	3 champion users trained first

Go-Live Checklist — Every Deployment

1. All acceptance criteria verified by client (not just delivery team)
2. Exception paths tested with realistic edge cases
3. Role-based access verified: each role sees ONLY what they should
4. Audit trail complete from trigger to completion
5. Integration error handling tested (external system down scenario)
6. User training completed for ALL roles
7. Rollback plan documented AND tested
8. Support escalation path defined
9. Performance verified at expected volume (not 5 test records)
10. Client sign-off obtained BEFORE go-live

---

CLIENT COMMUNICATION

Written Rules

• Lead with outcome. "Approval cycle drops from 3 weeks to 2 days" BEFORE "4-step workflow configured."
• Client vocabulary. "Your purchase orders" not "Data List entries."
• State assumptions. "Assumes ERP API access within 2 weeks. If delayed, timeline shifts."
• Never promise unverified. "Let me verify and confirm by [date]." Never "yes, we can do that" without checking.
• Quantify scope changes. "Adds approximately 1 week. Proceed or defer to Phase 2?"

// WRONG
"We completed the Data List configuration for the procurement module."

// RIGHT
"Your procurement approval workflow is now live. Purchase orders above 10 lakh
automatically route to the CFO. All approvals logged with timestamps."

Meeting Rules

• Open with: decisions from last meeting, what has changed, decisions needed today.
• Close with: written summary sent within 2 hours. Decisions, action items, owners, deadlines.
• Scope changes acknowledged in meeting with effort impact stated.
• No unresolved ambiguity. If unknown, assign action item with deadline.

Status Reporting Rules

• Traffic light. Green (on track), Amber (at risk + mitigation), Red (blocked + escalation needed).
• Amber/Red includes: issue, impact, mitigation, decision needed.
• Report outcomes, not activities. "3 of 5 workflows live" not "12 meetings this week."
• Never surprise the client. Deadline at risk: communicate early with revised plan.

---

FORBIDDEN PATTERNS — REJECT ON SIGHT

Pattern	Why	Fix
Requirements as feature lists	Implementation detail, not business need	Business outcome with acceptance criteria
Happy-path-only process	Fails on first real exception	Document exceptions, escalations, timeouts
"Should be fast" acceptance criteria	Untestable. Causes rework.	Specific metric: "< 2 seconds"
Timeline without assumptions	Promise, not plan	List every assumption and dependency
Unacknowledged scope creep	Erodes timeline and trust	Acknowledge with effort estimate immediately
Person-names in business rules	Breaks when person leaves	Role names. Roles persist.
Missing process owner	No accountability. Fails at handoffs.	Name one person before designing
"Yes we can do that" without verification	Creates undeliverable commitment	"Let me verify by [date]"
Scope by inclusion only	No boundary. Everything gets added.	Explicit exclusion list
Platform vocabulary in client docs	Client does not know "Data List"	Client's words. Always.
"All high priority"	Nothing prioritized	MoSCoW. Must/Should/Could/Won't
Meeting without written follow-up	Decisions forgotten	Summary within 2 hours
Deadline surprise	Destroys trust	Communicate early with revised plan
"Manager decides" exception handling	Not a design. An abdication.	Document who, what, when, audit trail
Phase 1 with 5 processes	Takes 6+ months. Momentum dies.	One process. Weeks, not months.
Tested with 5 records	Real volume has different failures	Test at expected volume

---

REVIEW CHECKLIST — RUN ON EVERY REVIEW

Pre-flight

1. Every requirement traces to a pain statement?
2. Scope defined by inclusion AND exclusion?
3. Named process owner?

Requirements Quality

4. Every requirement specific? (No "timely," "appropriate," "user-friendly")
5. Every requirement testable?
6. Every requirement prioritized (MoSCoW)?
7. Acceptance criteria present for every Must Have?
8. Client vocabulary used? (No platform terms)

Process Design

9. Exception paths documented?
10. SLAs per step?
11. Escalation rules for SLA breach?
12. Cross-departmental handoffs explicit?
13. Decision gateways labeled on every path?
14. Validated against real recent case?

Business Rules

15. Rules in separate catalog?
16. Rules reference roles, not people?
17. Conflicting rules have priority ordering?
18. Change authority defined per rule?

Implementation Plan

19. Timeline includes assumptions?
20. Dependencies listed with lead times?
21. Risk register includes 4 mandatory risks?
22. Go-live checklist complete?
23. Post-go-live support plan?

Client Communication

24. Client vocabulary throughout?
25. Business outcomes before technical details?
26. Scope changes acknowledged with effort impact?
27. Sign-off section with named stakeholders?

---

CONFIDENCE THRESHOLD

When reviewing business deliverables, score each finding 0-100. Only surface findings at 85+ confidence.

Severity levels:

• Critical — missing process owner, untestable acceptance criteria, scope without exclusions, exception handling absent. Must fix before client delivery.
• High — ambiguous business rule, person-name instead of role, missing SLA, no escalation path. Should fix.
• Medium — suboptimal process flow, missing edge case, inconsistent terminology. Consider fixing.
• Low — document formatting, section ordering, copy polish. Optional.

Verdict:

• Ready for Client — no Critical or High issues
• Needs Attention — Medium issues found
• Needs Rework — Critical or High issues found

---

This standard produces business deliverables indistinguishable from those produced by top-tier enterprise consulting firms. Every rule is testable. Follow it without exception.