Shynlee04 Idumb V2 Multi Aspect Assessment

Skill: Multi-Aspect Assessment

Evaluate requests, proposals, or decisions from multiple dimensions to ensure holistic understanding before proceeding.

When to Use This Skill

Trigger this skill when:

• Making technical decisions or architecture choices
• Choosing between multiple solutions or technologies
• Proposing significant changes or features
• Evaluating third-party integrations or dependencies
• Designing systems or user experiences
• Considering migrations or refactors

Do NOT use when:

• Decision is trivial and low-impact (e.g., variable naming)
• Previous assessment exists and context hasn't changed
• Decision is already validated and approved

Assessment Framework

The 8 Assessment Aspects

Always evaluate across these 8 aspects (add/remove based on context):

Step 1: Identify Relevant Aspects

Not all aspects apply equally. For each proposal:

Proposal: [Description]

Relevant Aspects: [Select from 8 aspects above]
- [Aspect 1] - Why relevant?
- [Aspect 2] - Why relevant?
- [Aspect 3] - Why relevant?
- [Aspect 4] - Why relevant?

Less Relevant: [Aspects with minimal impact]
- [Aspect] - Reason it's less relevant

Step 2: Score Each Aspect

For each relevant aspect, use this scoring rubric:

Score 1 (Critical Risk): Major blocker, significant downside
Score 2 (Concern): Moderate issue, needs mitigation
Score 3 (Neutral): Neither good nor bad
Score 4 (Benefit): Positive impact, minor benefit
Score 5 (Major Benefit): Significant advantage, strong positive

Assessment Template:

## [Aspect Name]: [Score 1-5]

**Summary:** [One-sentence summary]

**Pros:**
- [Positive outcome 1]
- [Positive outcome 2]

**Cons:**
- [Negative outcome 1]
- [Negative outcome 2]

**Risks:**
- [Risk 1] - [Mitigation strategy]
- [Risk 2] - [Mitigation strategy]

**Recommendation:** [What to do about this aspect]

Step 3: Identify Trade-Offs

Look for conflicts between aspects:

Trade-Off Matrix:

Aspect A (Score X) vs Aspect B (Score Y):
- [Describe conflict]
- [Which one wins? Why?]
- [How to mitigate the loser?]

Aspect C (Score X) vs Aspect D (Score Y):
- [Describe conflict]
- [Which one wins? Why?]
- [How to mitigate the loser?]

Step 4: Weigh by Priorities

Not all aspects are equally important. Context matters:

Aspect Priorities (Context-Dependent):

High Priority (Must excel):
- [Aspect] - [Why critical in this context]

Medium Priority (Important):
- [Aspect] - [Why important in this context]

Low Priority (Nice-to-have):
- [Aspect] - [Why less important in this context]

Weighted Score Calculation:
- [Aspect]: [Raw Score] × [Weight] = [Weighted Score]
- Total Weighted Score: [Sum]

Step 5: Generate Recommendations

Based on assessment, provide clear guidance:

## Assessment Summary

**Proposal:** [Description]
**Overall Assessment:** [Positive/Neutral/Negative]
**Weighted Score:** [Number]/[Max Possible]

### Key Findings

**Strengths:**
- [Major advantage 1]
- [Major advantage 2]

**Weaknesses:**
- [Major concern 1]
- [Major concern 2]

**Trade-Offs:**
- [Trade-off 1] - [Resolution]
- [Trade-off 2] - [Resolution]

### Recommendations

**Go/No-Go:** [Recommendation with confidence level]

**If Go:**
- [Critical mitigation 1]
- [Critical mitigation 2]
- [Success criteria]

**If No-Go:**
- [Alternative 1]
- [Alternative 2]
- [What would make this viable?]

**If Conditional:**
- [Condition 1] - Must be met before proceeding
- [Condition 2] - Must be met before proceeding
- [What changes if conditions are met?]

Common Assessment Patterns

Pattern 1: Technical Decision with Business Implications

Proposal: "Use Redis for caching"

**Relevant Aspects:** Technical, Performance, Operational, Business

## Technical: Score 4
**Summary:** Solid technical fit, moderate complexity

**Pros:**
- Proven technology, mature ecosystem
- Excellent performance for read-heavy workloads
- Rich feature set (pub/sub, data structures)

**Cons:**
- Additional infrastructure to manage
- Requires operational expertise
- Data eviction strategy complexity

**Risks:**
- Single point of failure - Mitigate: Use Redis Cluster
- Cache stamping attacks - Mitigate: Rate limiting, cache invalidation strategy
- Memory exhaustion - Mitigate: Monitoring, auto-scaling

**Recommendation:** Proceed with Redis, invest in operational expertise

## Performance: Score 5
**Summary:** Major performance improvement

**Pros:**
- Sub-millisecond latency for cached data
- Reduces database load significantly
- Scales horizontally with cluster

**Cons:**
- Cache warm-up time on cold starts
- Network latency for distributed deployments

**Risks:**
- Cache invalidation bugs - Mitigate: Comprehensive testing, gradual rollout

**Recommendation:** Cache is critical, prioritize performance

## Operational: Score 2
**Summary:** Operational burden is significant concern

**Pros:**
- Good monitoring and observability tools
- Active community, good documentation

**Cons:**
- Requires 24/7 operations coverage
- Backup/restore complexity
- Upgrade management for cluster

**Risks:**
- Operational team overwhelmed - Mitigate: Managed Redis service, training

**Recommendation:** Consider managed Redis service to reduce ops burden

## Business: Score 3
**Summary:** Neutral business impact

**Pros:**
- Reduced database costs (operational savings)
- Better user experience (business value)

**Cons:**
- Infrastructure costs (Redis service)
- Training costs for operations team

**Risks:**
- ROI uncertain - Mitigate: Pilot in one region, measure impact

**Recommendation:** Validate ROI with pilot before full rollout

### Trade-Offs

Performance (5) vs Operational (2):
- Redis provides major performance benefits but adds operational complexity
- Performance wins - user experience is critical
- Mitigate operational burden with managed service

### Priorities

High Priority: Performance (user experience is key)
Medium Priority: Technical (feasibility)
Low Priority: Business (ROI uncertain)

### Weighted Score

Performance: 5 × 1.0 = 5.0
Technical: 4 × 0.5 = 2.0
Business: 3 × 0.3 = 0.9
Operational: 2 × 0.5 = 1.0
**Total: 8.9/10**

### Recommendations

**Go/No-Go:** Go (Confidence: 70%)

**If Go:**
- Use managed Redis service (AWS ElastiCache, etc.) to reduce operational burden
- Pilot in one region to validate ROI
- Invest in monitoring and alerting
- Establish cache invalidation strategy before launch

**Success Criteria:**
- 50% reduction in database load
- 90% cache hit rate
- Sub-100ms latency for cached queries
- < 5 minutes mean time to resolution (MTTR) for Redis issues

Pattern 2: User Experience with Security Trade-Offs

Proposal: "Add social login (Google, GitHub)"

**Relevant Aspects:** User Experience, Security, Technical, Business

## User Experience: Score 5
**Summary:** Major UX improvement, reduces friction

**Pros:**
- No password management for users
- Fast login with one click
- Familiar, trusted login flow

**Cons:**
- Loss of control over login experience
- Dependency on third-party providers

**Risks:**
- Provider downtime blocks login - Mitigate: Keep email/password fallback

**Recommendation:** Social login significantly improves UX

## Security: Score 2
**Summary:** Security concerns require careful implementation

**Pros:**
- Delegates authentication to OAuth providers (Google's security expertise)
- No password storage (reduces risk of password breaches)
- Strong security practices enforced by providers

**Cons:**
- Third-party dependency (trust in provider security)
- OAuth implementation vulnerabilities (CSRF, token leakage)
- Provider data access (privacy concerns)

**Risks:**
- OAuth implementation bugs - Mitigate: Use mature OAuth libraries, security audit
- Provider data harvesting - Mitigate: Minimal scopes, privacy policy disclosure

**Recommendation:** Proceed with caution, thorough security review required

## Technical: Score 4
**Summary:** Well-supported, moderate complexity

**Pros:**
- Standard OAuth 2.0 protocol
- Mature libraries for all major frameworks
- Extensive documentation and examples

**Cons:**
- Integration complexity (multiple providers)
- Token management (access tokens, refresh tokens)
- User account linking complexity

**Risks:**
- Token expiry/refresh bugs - Mitigate: Robust token management, comprehensive testing

**Recommendation:** Use proven OAuth library, don't implement OAuth from scratch

## Business: Score 4
**Summary:** Strong business value, clear ROI

**Pros:**
- Higher conversion rates (fewer drop-offs at login)
- Reduced support requests (password reset issues)
- Access to user data from providers (optional, valuable)

**Cons:**
- Dependency on provider terms of service
- Potential costs (OAuth provider limits)

**Risks:**
- Provider API changes - Mitigate: Stay updated on OAuth spec, multiple providers

**Recommendation:** Business value is clear, proceed

### Trade-Offs

User Experience (5) vs Security (2):
- Social login improves UX but introduces security complexity
- UX wins - user onboarding is critical
- Mitigate security with thorough review and testing

### Priorities

High Priority: User Experience (onboarding is key)
Medium Priority: Security (cannot compromise on security)
Low Priority: Business (assumed value)

### Weighted Score

User Experience: 5 × 1.0 = 5.0
Business: 4 × 0.5 = 2.0
Technical: 4 × 0.5 = 2.0
Security: 2 × 1.0 = 2.0
**Total: 11.0/15**

### Recommendations

**Go/No-Go:** Conditional Go (Confidence: 65%)

**Conditions:**
1. Security audit of OAuth implementation before production
2. Keep email/password login as fallback (no social-only login)
3. Minimal OAuth scopes (only essential data)
4. Privacy policy disclosure of data collection

**If Conditions Met:**
- Start with Google (largest user base), add GitHub later
- Use mature OAuth library (passport, auth0, etc.)
- Comprehensive testing of token lifecycle
- Monitor for provider issues, have fallback ready

**Success Criteria:**
- 30% increase in sign-up conversion
- < 5% of users choose email/password fallback
- Zero security vulnerabilities in OAuth implementation
- < 1% login failure rate due to provider issues

Pattern 3: Strategic Architecture Decision

Proposal: "Refactor monolith to microservices"

**Relevant Aspects:** Technical, Operational, Business, Maintainability, Strategic

## Technical: Score 3
**Summary:** Technical complexity increases significantly

**Pros:**
- Independent scaling of services
- Technology diversity (right tool for each service)
- Fault isolation (one service doesn't bring down everything)

**Cons:**
- Distributed system complexity
- Network latency and reliability
- Data consistency challenges

**Risks:**
- Service dependencies become unmanageable - Mitigate: Service mesh, API governance
- Distributed transactions complexity - Mitigate: Eventual consistency, saga pattern

**Recommendation:** Only proceed if technical team has distributed systems expertise

## Operational: Score 2
**Summary:** Operational burden increases dramatically

**Pros:**
- Granular monitoring and observability
- Independent deployments

**Cons:**
- Multiple services to monitor, debug, and operate
- Deployment complexity (orchestration needed)
- Increased infrastructure costs

**Risks:**
- Operational team overwhelmed - Mitigate: Automation, managed services, training
- Debugging across services - Mitigate: Distributed tracing, structured logging

**Recommendation:** Strong operations team is prerequisite

## Business: Score 2
**Summary:** Business case is unclear for most organizations

**Pros:**
- Potential for faster time-to-market (independent deployments)
- Better alignment with business domains (domain-driven design)

**Cons:**
- Higher development costs (more coordination)
- Slower initial development (infrastructure setup)
- Opportunity cost (not building features)

**Risks:**
- ROI not realized - Mitigate: Pilot with one service, measure impact

**Recommendation:** Only proceed if there's clear business case

## Maintainability: Score 2
**Summary:** Maintainability may degrade without strong discipline

**Pros:**
- Smaller codebases per service (easier to understand)
- Clear ownership boundaries

**Cons:**
- More places to look for bugs
- Service boundaries must be maintained
- Refactoring across services is harder

**Risks:**
- Service boundaries leak (tight coupling) - Mitigate: Strong API governance, testing
- Team coordination overhead - Mitigate: Conway's Law awareness, team structure alignment

**Recommendation:** Requires strong engineering culture and discipline

## Strategic: Score 3
**Summary:** Strategic fit depends on organization

**Pros:**
- Aligns with domain-driven design principles
- Enables autonomous teams
- Future-proofs for scale

**Cons:**
- Vendor lock-in to microservices ecosystem
- Harder to reverse back to monolith
- Mismatch if team size is small

**Risks:**
- Microservices for wrong reasons - Mitigate: Clear criteria for when to use microservices

**Recommendation:** Only use microservices if organization meets criteria

### Trade-Offs

Technical (3) vs Operational (2):
- Technical benefits don't justify operational burden
- Neither wins - both are concerns

Business (2) vs Strategic (3):
- Strategic benefits don't justify business costs
- Neither wins - both are concerns

### Priorities

High Priority: Business (must have ROI)
Medium Priority: Strategic (must align with goals)
Low Priority: Technical, Operational, Maintainability (supporting aspects)

### Weighted Score

Strategic: 3 × 0.6 = 1.8
Business: 2 × 1.0 = 2.0
Technical: 3 × 0.3 = 0.9
Operational: 2 × 0.3 = 0.6
Maintainability: 2 × 0.3 = 0.6
**Total: 5.9/15**

### Recommendations

**Go/No-Go:** No-Go (Confidence: 85%)

**Why No-Go:**
- Business case is unclear
- Operational burden is significant
- Technical complexity is high
- ROI is uncertain

**When to Reconsider:**
1. Organization has 50+ developers (microservices scale with team size)
2. Services have clear domain boundaries (DDD)
3. Independent scaling needs are clear (performance issues)
4. Strong operations team exists (24/7 coverage)
5. Business value is measurable and significant

**Alternative:**
- Modular monolith with clear boundaries
- Extract services when there's clear need
- Delay microservices until organization grows

**What Would Make This Viable?**
- Clear business case with measurable ROI
- Proven operational team with distributed systems expertise
- Services have clear domain boundaries with low coupling
- Independent scaling requirements are critical
- Organization is large enough to justify overhead

Assessment Templates

Quick Assessment (5-10 minutes)

Use for low-impact decisions or initial screening:

**Proposal:** [Description]

**Relevant Aspects:** [List]

**Quick Scores:**
- [Aspect]: [Score 1-5] - [One sentence reason]
- [Aspect]: [Score 1-5] - [One sentence reason]

**Overall:** [Go/No-Go/Conditional] - [One sentence reason]

Comprehensive Assessment (30-60 minutes)

Use for high-impact decisions or architecture choices:

[Full assessment as shown in patterns above]

Comparative Assessment (Compare 2-3 options)

Use when choosing between alternatives:

**Option A:** [Description]
**Option B:** [Description]
**Option C:** [Description]

**Comparison Matrix:**

| Aspect | Option A | Option B | Option C | Winner |
|--------|----------|----------|----------|--------|
| [Aspect] | [Score] | [Score] | [Score] | [Option] |
| [Aspect] | [Score] | [Score] | [Score] | [Option] |
| [Aspect] | [Score] | [Score] | [Score] | [Option] |

**Total Scores:**
- Option A: [Score]
- Option B: [Score]
- Option C: [Score]

**Recommendation:** [Option with best fit] - [Reasoning]

Common Mistakes to Avoid

❌ Only assessing technical aspects
→ Must consider business, UX, security, operations, etc.

❌ Ignoring trade-offs
→ Every decision has trade-offs. Identify and address them.

❌ Weighting all aspects equally
→ Context determines priority. Weight aspects by importance.

❌ Scoring without justification
→ Always explain why you gave a score. Scoring is a conversation starter.

❌ Not considering context
→ Same proposal may have different scores in different contexts.

❌ Making recommendations without mitigation
→ If there are concerns, propose mitigation strategies.

❌ Binary thinking (go/no-go only)
→ Conditional decisions are common. Define conditions clearly.

Integration with Other Skills

Use before:

• gap-analysis - Assessment reveals gaps to investigate
• research-workflow-planner - Assessment informs research scope

Use after:

• intent-clarification - Assessment clarifies intent further

Use in parallel with:

• gap-analysis - Assessment reveals gaps across multiple aspects

Success Criteria

Multi-aspect assessment is successful when:

• ✓ All relevant aspects have been evaluated
• ✓ Trade-offs have been identified and addressed
• ✓ Recommendations are clear and actionable
• ✓ Stakeholder understands the implications
• ✓ Decision is made with full understanding of consequences
• ✓ Risks have mitigation strategies

Outcome

After using this skill:

• Request has been evaluated holistically
• Trade-offs are understood and addressed
• Clear recommendation with confidence level
• Mitigation strategies for identified risks
• Stakeholder alignment on implications

Never make important decisions without multi-aspect assessment. This skill prevents single-minded thinking and uncovers hidden risks.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.