Stakeholder & Risk Management in IT

The two disciplines most underestimated by technical founders. Building great software means nothing if stakeholders aren’t aligned or if risks kill the project. Directly applicable to NOTQIN pilots and DigiTPME client engagements.

---

Part 1: Stakeholder Management

What is a Stakeholder?

Freeman (1984): “Any group or individual who can affect or is affected by the achievement of the organization’s objectives.”

Types in IT/tech projects:

• Internal: founder, engineering team, domain experts
• External direct: clients, users, investors, partners
• External indirect: regulators (CNDP, CBAM authorities), competitors, media, community

Stakeholder Analysis — Power/Interest Matrix

         HIGH INTEREST
              │
HIGH POWER    │    LOW POWER
              │
   MANAGE     │    KEEP INFORMED
   CLOSELY    │
   ──────────────────────────────
   KEEP       │    MONITOR
   SATISFIED  │    (minimal effort)
              │
         LOW INTEREST

Quadrant	Strategy	Example
High Power, High Interest	Manage closely — deep involvement, frequent updates, ask for input	Factory director for NOTQIN pilot, pharmacy owner in SijilPharma beta
High Power, Low Interest	Keep satisfied — regular updates, avoid surprises	ENSA Berrechid director (academic partner), CNDP regulator
Low Power, High Interest	Keep informed — newsletters, shared docs, transparency	Team members, beta users, research collaborators
Low Power, Low Interest	Monitor — minimal effort, watch for changes	General public, indirect competitors

Stakeholder Register

For every significant project engagement, maintain a stakeholder register:

Stakeholder	Role	Interest	Power	Current Attitude	Desired Attitude	Engagement Strategy
Factory Director	Decision-maker	Reduce energy costs	High	Skeptical	Champion	Monthly ROI report, on-site demo
Plant Manager	Operator	Reduce alert fatigue	Medium	Curious	Advocate	Dashboard walkthrough, quick wins
IT Manager	Gatekeeper	Security, integration	High	Resistant	Neutral	Security documentation, API docs
AMEE Representative	Validator	Compliance coverage	Medium	Supportive	Partner	Regulatory alignment review

Communication Planning

For each stakeholder group, define:

• What: what information do they need?
• Why: why does it matter to them?
• When: frequency of communication
• How: format (report, dashboard, meeting, email, WhatsApp)
• Who: who communicates from your side

Communication matrix example (NOTQIN pilot):

Stakeholder	Content	Frequency	Format	Owner
Factory Director	Energy savings, ROI, CBAM status	Monthly	1-page PDF report	Ahmed
Plant Manager	Anomalies detected, alerts	Weekly	Grafana dashboard + email	System automated
IT Manager	System health, security events	Monthly	Technical report	Ahmed
Pilot Sponsor (AMEE)	Pilot progress, compliance coverage	Quarterly	Formal report	Ahmed

---

Part 2: Risk Management in IT Projects

What is Risk?

Risk = Probability × Impact

A risk is an uncertain event that, if it occurs, affects project objectives (scope, schedule, cost, quality).

Risk vs Issue:

• Risk: uncertain future event (may or may not occur)
• Issue: a risk that has materialized; it’s happening now

The Risk Management Process (PMI PMBOK)

1. IDENTIFY
   → Brainstorm with team, review lessons learned, use checklists
   → Techniques: SWOT analysis, 5 Whys, fishbone diagram, expert interviews

2. ANALYZE
   → Qualitative: rate by probability (H/M/L) and impact (H/M/L)
   → Quantitative: Monte Carlo simulation, Expected Monetary Value (for critical projects)

3. PRIORITIZE
   → Risk matrix: plot P × I to find top risks
   → Focus effort on high-probability + high-impact risks

4. PLAN RESPONSES
   → Select response strategy per risk

5. MONITOR & CONTROL
   → Track risks throughout project
   → Identify new risks as project progresses
   → Update risk register regularly

Risk Response Strategies

Strategy	When to use	Example
Avoid	Eliminate the risk by changing plan	Skip a feature that introduces security risk
Mitigate	Reduce probability or impact	Write automated tests to reduce probability of regression
Transfer	Shift risk to third party	Cloud hosting provider takes on infrastructure risk, SLAs
Accept (active)	Plan a contingency if risk occurs	”If the factory data feed is unreliable, fall back to manual CSV upload”
Accept (passive)	Do nothing; absorb the loss if it occurs	Minor UI bugs that don’t affect core functionality

Note: you can only exploit opportunities (positive risks) — treat upside risks with: Exploit, Share, Enhance, Accept.

Risk Matrix

         IMPACT
         Low    │ Medium │  High
         ───────┼────────┼──────────
HIGH     Yellow │ Orange │   RED
PROB.    ───────┼────────┼──────────
MEDIUM   Green  │ Yellow │  Orange
         ───────┼────────┼──────────
LOW      Green  │ Green  │  Yellow

---

IT-Specific Risk Categories

1. Technical Risks

Risk	Probability	Impact	Mitigation
Third-party API changes (ONEE, Claude API)	Medium	High	Abstract behind interface, versioned adapters
Database migration failure	Low	Critical	Backup + rollback plan, staging migration first
Security breach (data exfiltration)	Low	Critical	Encryption, access control, audit logs, pen test
Performance degradation under load	Medium	High	Load testing before go-live
Technical debt accumulation	High	Medium	Allocate 20% of each sprint to debt reduction

2. Integration Risks (especially relevant for IoT)

Risk	Mitigation
PLC/sensor firmware incompatibility	Test in lab before field deployment
MQTT broker overload	EMQX HA cluster, backpressure handling
Network unreliability at factory floor	Store-and-forward edge buffer
Clock synchronization issues	NTP sync + Sparkplug B birth messages
Data format inconsistency across machines	Schema validation at ingestion layer

3. External/Business Risks

Risk	Probability	Impact	Mitigation
Key client cancels pilot	Medium	High	Multiple pilots in parallel, contractual commitments
CBAM regulation delayed or changed	Medium	Medium	Build generic energy monitoring, CBAM report as module
Competitor releases similar product	Medium	Medium	Speed + local knowledge advantage, relationships
Regulatory non-compliance (CNDP Loi 09-08)	Low	Critical	Legal review for patient data processing
Currency risk (MAD/EUR for CBAM reporting)	Low	Low	Quote CBAM data in tCO₂, convert at report time

4. Human/Team Risks

Risk	Mitigation
Key person risk (you’re the only one who knows the system)	Document architecture, record onboarding videos, knowledge transfer sessions
Contributor disappears mid-project	Bounded deliverables, clear contracts, milestones
Scope creep from enthusiastic client	Change control process, signed scope document
Founder burnout	Operating rule: one active project per quarter

---

The Risk Register (your 05_Team/Coordinator OS/05 — Risk Register)

Columns to maintain:

Field	Description
Risk ID	Unique identifier (R001, R002…)
Category	Technical / Business / External / Human
Description	Clear one-sentence description of the uncertain event
Probability	H / M / L (or 1–5)
Impact	H / M / L (or 1–5)
Risk Score	P × I
Owner	Who monitors this risk
Response Strategy	Avoid / Mitigate / Transfer / Accept
Response Actions	Concrete steps taken
Status	Open / Closed / Materialized
Residual Risk	Risk remaining after mitigation

---

Part 3: IT Governance Frameworks

ITIL v4 (IT Infrastructure Library)

The most widely adopted IT service management framework. Provides best practices for delivering IT services.

4 Dimensions:

1. Organizations and People
2. Information and Technology
3. Partners and Suppliers
4. Value Streams and Processes

Key ITIL concepts:

• Service: a means of enabling value co-creation without the customer managing costs and risks
• Incident: unplanned interruption or degradation of service → MTTR (Mean Time to Resolve)
• Problem: root cause of one or more incidents → post-incident reviews
• Change: addition, modification, removal of anything that has an effect on IT services

ITIL 4 Service Value Chain:

Plan → Engage → Design & Transition → Obtain/Build → Deliver & Support → Improve

Relevant when selling NOTQIN as a managed service. Clients will expect ITIL-compatible SLAs, incident response, and change management.

ISO/IEC 27001 — Information Security Management

Already in your PRD list (PRD — ISO 27001 Quarterly Evidence Exporter).

Key concepts:

• ISMS: Information Security Management System
• Risk assessment: identify, analyze, evaluate information security risks
• Controls: technical and organizational safeguards (Annex A: 93 controls)
• CIA Triad: Confidentiality, Integrity, Availability

Certification path for DigiTPME:

1. Gap analysis (current state vs standard)
2. Risk assessment
3. Implement missing controls
4. Internal audit
5. External certification audit (by Bureau Veritas, SGS, or CERTI MAROC)

Moroccan SME clients increasingly require their SaaS vendors to be ISO 27001 certified. Plan for certification when revenue justifies the investment (~MAD 150,000 + internal effort).

COBIT (Control Objectives for Information and Related Technologies)

Framework for IT governance and management. Five principles:

1. Meeting stakeholder needs
2. Covering the enterprise end-to-end
3. Applying a single, integrated framework
4. Enabling a holistic approach
5. Separating governance from management

Relevant if selling to banks, insurance companies, or large Moroccan enterprises with formal IT audit requirements.

---

Contracts and Legal Risk in Tech Projects

SaaS Contract Essentials

Clause	What to include
Scope of service	Exactly what is included (features, SLA, support)
SLA (Service Level Agreement)	Uptime guarantee (e.g., 99.5%), response times
Data ownership	Client data belongs to client, not you
Data processing	Who processes what data, under what legal basis
Liability cap	Your maximum liability = 12 months of fees paid
Acceptable use	Client cannot use platform for illegal activities
Termination	Notice period, data export upon termination
Intellectual property	You retain IP of platform; client owns their data
Confidentiality (NDA)	Both parties protect each other’s confidential info
Governing law	Moroccan law (Casablanca Commercial Court)

Pilot Contract Specifics (NOTQIN)

• Define clearly: what constitutes “pilot success”
• Who pays for sensor hardware?
• Who is responsible for physical installation?
• Data rights during pilot (you want to use it for model improvement — get explicit consent)
• Conversion path: what happens after pilot (pricing, terms)

---

RACI Matrix — Clarifying Responsibilities

R = Responsible (does the work) A = Accountable (owns the outcome) C = Consulted (provides input) I = Informed (kept up to date)

Rule: one A per task (prevents “shared accountability = no accountability”).

Example for DigiTPME diagnostic deployment:

Task	Ahmed	Collaborator	Client DG	Client IT
Discovery interviews	R/A	C	C	I
Diagnostic platform build	A	R	I	I
SME questionnaire completion	I	I	R/A	C
Report generation	R/A	C	I	I
Recommendations presentation	R/A	I	R	C
Implementation sprint	R	R	A	R/C

---

Conflict Management in Tech Projects

Thomas-Kilmann Conflict Model — 5 styles based on assertiveness vs cooperativeness:

Style	Assertiveness	Cooperativeness	When to use
Competing	High	Low	Safety-critical decisions, principled disagreements
Collaborating	High	High	Complex problems where both parties’ insights are needed
Compromising	Medium	Medium	When time-pressured, temporary agreements needed
Avoiding	Low	Low	Minor issues, when it’s not your battle
Accommodating	Low	High	When you’re wrong, or when maintaining relationship > winning

In tech project contexts:

• Technical disagreements: Collaborate (both parties have knowledge)
• Scope creep from client: Compete (defend the bounded scope)
• Team conflict over approach: Collaborate, then Compromise
• Minor process disagreements: Accommodate

---

See Also

• Modern Management Overview
• Agile & Scrum
• Digital Transformation Frameworks
• Coordinator OS/05 — Risk Register
• Coordinator OS/08 — Decision Log
• NOTQIN Pilot Playbook
• ISO and Governance
• Partnership Strategy