Independent Efficiency Management Process (IEMP)
[V 0.9 - beta / comments are welcome]
- The terminology is not yet aligned to commonly used business or standards organization terminology (like e.g. ISO). This will happen after the process definition has finalized.
Basic Processing Requirements
- Protect System Operation
- System Remains Operative
- no changes / only non-critical changes applied (during analysis)
- Prioritized & Controlled Changes System Remains Operative
- System Participants (if existent) Remain Operative
- have minimal time investment
- have minimal theory involvement
- System Remains Operative
Negotiated Processing Requirements (Negotiation Phase)
Define / Negotiate Processing Rules & Goals (e.g. customer Decides)
- Limit Directness (optional)
- Designate Mediator
- communicates results to Participants (e.g. Team Members)
- ensures minimal disruption of productivity.
- Designate Mediator
- Limit Scope (optional)
- e.g. "Exclude Kernel Code"
- Limit Visibility (optional)
- e.g. Leadership and Administration
- e.g. "no public analysis"
- company internal group of recipients (semi-public analysis)
- e.g. Leadership and Administration
Analyst Independency
- Granted (from Customer)
- Independent from Administration and Supervision
- Operation based on defined Processing Requirements
- Gained (from Process/Method)
- Independent from Personal Relations
- Written Conversation within Public System Resources.
- Publicity promotes Straightness (of participants)
- Distance ensures Strictness (of analyst)
- [Personal Relations can lead to emotional barriers, which can reduce strictness]
- Required (from Skill set)
- Independent From Domain Knowledge
- Manager (Analyst) must have low amounts of Domain Knowledge
- [Barrier Detection and Removal is essential]
- [Domain Knowledge hinders detection of barriers during System-Teach-In]
- Independent from Full Detail
- Ability to gain Domain Knowledge abstractly within small timeframe
- Ability to immediately inhibit non-relevant details
- Reduced Complexity
Introductive Overall Analysis
- Isolate Subsystems
- Specify Verification Roles
- Specify Verification Contexts
- Extract/Define System Goals
- Questionnaire & Interview
- Review System Documentation (website etc.)
- Extract/Define System Prime
Directives
- Generic Directive: "Achieve System Goals"
- Questionnaire & Interview
- Review System Documentation (website etc.)
- [e.g. Corporate Ethics]
- Specify Global Requirements
- Derive from Goals
- Verify against Prime Directives
Define Ideal Structure
For Each Subsystem
- Requirements Specification
- Define Subsystem Goals
- Derive Subsystem Requirements
- Verify against Global Requirements
- Create Verification Material
- Comparison Table for Basic Requirements
- Evaluation Template for Extended Requirements
- Create Fictional Verification
/ Fictional Product
- Verification of a Fictional Product (Full Requirements Compliancy)
- Fictional Product Documentation (e.g. Manuals, Website)
Subsystem Verification
For Each Subsystem
- Select Possible Candidates (or Competitive Subsystems)
- Apply Basic Verification (Comparison Table)
- Reduce Candidates
- Apply Extended Verification (Evaluation Template)
- File Issues, limited SWOT profile
- Strengths & Weaknesses
- Opportunities & Threats
- File Issues, limited SWOT profile
- Final Subsystem (the existent one, or the newly selected)
- Apply Final Verification
- File Issues, full SWOT profile
- Strengths & Weaknesses
- Opportunities & Threats
- File Issues, full SWOT profile
System Transformation
- Define Transformation
- Detect Technical Barriers
- Reduce Barriers (assistance: Domain Experts
- Detect Non-Technical Barriers (legal,
personal, financial, ... )
- Reduce Barriers (assistance: System Lead, Mediators)
- Detect Technical Barriers
- Arrange Issues
- Assign Priorities
- Define Group of Issues
- Define Dependencies
- Define Sequence
- Execute Transformation