aigroup-workflow 1.0.0 → 1.1.0

package/skills/jarvis/engineering-team/business-growth/sales-engineer/references/poc-best-practices.md

@@ -1,277 +0,0 @@
-# Proof of Concept (POC) Best Practices
-
-A comprehensive guide for Sales Engineers planning, executing, and evaluating proof-of-concept engagements.
-
-## POC Planning Methodology
-
-### 1. Pre-POC Qualification
-
-Not every deal warrants a POC. Qualify before committing resources:
-
-**POC-Worthy Indicators:**
-- Deal value justifies 80-200+ hours of SE and engineering time
-- Customer has an identified champion who will actively participate
-- Clear decision timeline with POC as a defined evaluation step
-- Budget is allocated or allocation process is underway
-- Technical stakeholders are available for the evaluation period
-
-**POC Red Flags:**
-- "Free trial" request with no commitment to evaluate
-- No identified decision-maker or budget owner
-- Competitor has already been selected; POC is for validation only
-- Customer expects production-grade environment for extended period
-- No defined success criteria or evaluation framework
-
-### 2. Scope Definition
-
-The most critical success factor is a well-defined scope. An uncontrolled scope leads to extended timelines, unmet expectations, and lost deals.
-
-**Scope Elements:**
-- **Use cases:** 3-5 specific scenarios to validate (not "everything")
-- **Integrations:** Which systems must connect during the POC
-- **Data:** What data will be used (sample, synthetic, production subset)
-- **Users:** Who will access the POC environment and in what roles
-- **Duration:** Fixed timeline with clear milestones
-- **Success criteria:** Measurable, objective criteria for each use case
-
-**Scope Control Tactics:**
-- Document scope in writing with customer sign-off
-- Define what is explicitly out of scope
-- Create a change request process for scope additions
-- Set a maximum number of use cases per complexity tier
-
-### 3. Timeline Planning
-
-**Standard 5-Week Framework:**
-
-| Week | Phase | Focus | Key Activities |
-|------|-------|-------|---------------|
-| 1 | Setup | Foundation | Environment, data, access, kickoff |
-| 2-3 | Core Testing | Validation | Primary use cases, integrations, workflows |
-| 4 | Advanced Testing | Edge cases | Performance, security, scale, administration |
-| 5 | Evaluation | Decision | Scorecard, review, recommendation |
-
-**Timeline Adjustments by Complexity:**
-
-| Complexity | Duration | Use Cases | Integrations |
-|-----------|----------|-----------|-------------|
-| Low | 3 weeks | 2-3 | 0-1 |
-| Medium | 5 weeks | 3-5 | 2-3 |
-| High | 6-8 weeks | 5-8 | 4+ |
-
-**Timeline Rules:**
-- Never exceed 8 weeks. Longer POCs lose momentum and stakeholder attention.
-- Front-load the most impressive capabilities to build early momentum.
-- Schedule stakeholder checkpoints at the end of each phase.
-- Build 20% buffer into each phase for unexpected issues.
-
-### 4. Resource Planning
-
-**SE Allocation:**
-
-| Activity | Hours/Week (Medium Complexity) |
-|----------|-------------------------------|
-| Environment setup and configuration | 15-20 (Week 1 only) |
-| Use case execution and testing | 20-25 |
-| Stakeholder communication | 3-5 |
-| Documentation and reporting | 3-5 |
-| Issue resolution | 5-8 |
-
-**Engineering Support:**
-- Allocate dedicated engineering support for complex integrations
-- Establish an escalation path for blocking issues
-- Pre-schedule engineering availability during Core Testing phase
-- Request customer IT support for integration access and credentials
-
-**Customer Resources:**
-- Technical sponsor for daily communication
-- Business stakeholders for use case validation
-- IT/Security for environment access and compliance review
-- End users for usability feedback (if applicable)
-
-## Success Criteria Definition
-
-### Writing Effective Success Criteria
-
-Each criterion must be:
-- **Specific:** Clearly defined with no ambiguity
-- **Measurable:** Quantifiable metric or clear pass/fail
-- **Agreed:** Documented and signed off by both parties
-- **Relevant:** Tied to a business outcome or technical requirement
-- **Time-bound:** Evaluated within the POC timeline
-
-### Success Criteria Categories
-
-**Functionality Criteria:**
-- "System processes [X] transactions per hour without errors"
-- "Workflow automation reduces manual steps from [Y] to [Z]"
-- "Report generation completes within [N] seconds for [M] records"
-- "All [X] defined use cases completed successfully"
-
-**Performance Criteria:**
-- "API response time <200ms at p95 under [N] concurrent users"
-- "Batch processing completes [X] records in under [Y] minutes"
-- "System maintains performance with [N]x expected data volume"
-
-**Integration Criteria:**
-- "Bidirectional sync with [System X] operates within [Y] minute latency"
-- "SSO integration with [IdP] supports all required authentication flows"
-- "Data import from [Source] completes with <1% error rate"
-
-**Usability Criteria:**
-- "New users complete [task] within [N] minutes without assistance"
-- "Admin configuration for [scenario] requires fewer than [N] steps"
-- "Stakeholder satisfaction rating >= 4.0/5.0"
-
-### Anti-Patterns in Success Criteria
-
-- **Too vague:** "System performs well" (what is "well"?)
-- **Too many:** More than 15 criteria dilutes focus and extends timeline
-- **Unmeasurable:** "Users like the interface" (how do you measure "like"?)
-- **Biased toward feature count:** "Must have Feature X" instead of "Must solve Problem Y"
-- **Moving target:** Criteria that change mid-POC without formal agreement
-
-## Stakeholder Management
-
-### Stakeholder Map
-
-| Role | Priority | Engagement Strategy |
-|------|----------|-------------------|
-| Decision Maker | High | Executive briefings, ROI summaries |
-| Champion | Critical | Daily communication, progress updates |
-| Technical Evaluator | High | Hands-on access, deep-dive sessions |
-| End User | Medium | Usability testing, feedback sessions |
-| IT/Security | High | Compliance reviews, architecture sessions |
-| Procurement | Low-Medium | TCO documentation, reference connections |
-
-### Engagement Cadence
-
-- **Daily:** Champion check-in (10 min, Slack/email)
-- **Weekly:** Progress report to all stakeholders (written summary)
-- **Phase transitions:** Formal review meeting with demo of progress
-- **Final:** Executive presentation with scorecard results and recommendation
-
-### Managing Stakeholder Expectations
-
-1. **Set clear boundaries:** Define what will and will not be demonstrated
-2. **Communicate early and often:** No surprises; surface issues immediately
-3. **Document everything:** Meeting notes, decisions, change requests
-4. **Celebrate wins:** Highlight successful milestones to maintain momentum
-5. **Address concerns immediately:** Delays in resolution erode confidence
-
-## Evaluation Frameworks
-
-### Weighted Scorecard Model
-
-The evaluation scorecard provides an objective, comparable assessment:
-
-| Category | Weight | Score (1-5) | Weighted Score |
-|----------|--------|-------------|----------------|
-| Functionality | 30% | | |
-| Performance | 20% | | |
-| Integration | 20% | | |
-| Usability | 15% | | |
-| Support | 15% | | |
-| **Total** | **100%** | | |
-
-**Scoring Scale:**
-- 5: Exceeds requirements - superior capability demonstrated
-- 4: Meets requirements - full capability with minor enhancements possible
-- 3: Partially meets - acceptable but notable gaps remain
-- 2: Below expectations - significant gaps that impact value
-- 1: Does not meet - critical failure for this category
-
-**Decision Thresholds:**
-- Weighted average >= 4.0: **Strong Pass** - proceed to procurement
-- Weighted average 3.5-3.9: **Pass** - proceed with noted conditions
-- Weighted average 3.0-3.4: **Conditional** - requires further evaluation or negotiation
-- Weighted average < 3.0: **Fail** - does not meet requirements
-
-### Go/No-Go Decision Framework
-
-The go/no-go decision should be based on multiple factors, not just the scorecard:
-
-**Go Indicators:**
-- Scorecard score >= 3.5
-- All must-have success criteria met
-- Champion and decision-maker both express positive sentiment
-- No unresolved critical technical blockers
-- Clear implementation path identified
-
-**No-Go Indicators:**
-- Scorecard score < 3.0
-- Critical success criteria failed without clear resolution
-- Decision-maker expresses significant concerns
-- Multiple unresolved technical blockers
-- Competitive alternative clearly preferred by evaluators
-
-**Conditional Go Indicators:**
-- Scorecard score 3.0-3.5 with clear path to improvement
-- 1-2 minor success criteria not met but with workarounds
-- Mixed stakeholder sentiment that can be addressed
-- Blockers identified but resolution path confirmed with engineering
-
-## Common POC Failure Modes
-
-### 1. Scope Creep
-**Symptom:** Customer continuously adds requirements during the POC.
-**Prevention:** Written scope agreement with change request process.
-**Recovery:** Renegotiate timeline or defer additions to Phase 2.
-
-### 2. Champion Absence
-**Symptom:** Champion becomes unavailable or disengaged mid-POC.
-**Prevention:** Identify a backup champion. Schedule regular touchpoints.
-**Recovery:** Escalate to decision-maker. Demonstrate value already achieved.
-
-### 3. Data Issues
-**Symptom:** Customer data is unavailable, poor quality, or incompatible.
-**Prevention:** Request sample data before kickoff. Prepare synthetic data.
-**Recovery:** Use synthetic data for core testing. Document data requirements for implementation.
-
-### 4. Environment Problems
-**Symptom:** POC environment is unstable, slow, or inaccessible.
-**Prevention:** Use a dedicated, pre-configured environment. Test before kickoff.
-**Recovery:** Have a backup environment. Communicate honestly about delays.
-
-### 5. Moving Goalposts
-**Symptom:** Evaluation criteria change mid-POC, often influenced by competitor demos.
-**Prevention:** Get written sign-off on criteria before starting. Reference agreement when changes arise.
-**Recovery:** Agree to evaluate new criteria as addendum, not replacement. Highlight what has already been validated.
-
-### 6. Extended Timeline
-**Symptom:** POC drags beyond planned duration without clear progress.
-**Prevention:** Set hard deadlines in the agreement. Schedule decision meetings in advance.
-**Recovery:** Force a checkpoint. Present results to date and ask for a go/no-go with current evidence.
-
-### 7. Technical Blockers
-**Symptom:** Unexpected technical issues prevent completion of key use cases.
-**Prevention:** Conduct technical discovery before committing to POC. Have engineering on standby.
-**Recovery:** Escalate immediately. Provide transparent status updates. Offer alternative approaches.
-
-## POC Documentation
-
-### Required Artifacts
-
-| Document | When | Owner |
-|----------|------|-------|
-| Scope agreement | Pre-POC | SE + Customer |
-| Environment setup guide | Week 1 | SE |
-| Progress reports | Weekly | SE |
-| Phase review presentations | Phase transitions | SE |
-| Issue log | Ongoing | SE |
-| Final evaluation report | Week 5 | SE + Customer |
-| Lessons learned | Post-POC | SE |
-
-### Final Report Template
-
-1. **Executive Summary** - POC objectives, approach, and outcome
-2. **Scope and Success Criteria** - What was tested and how
-3. **Results Summary** - Success criteria outcomes with evidence
-4. **Evaluation Scorecard** - Weighted scores across all categories
-5. **Issues and Resolutions** - Problems encountered and how they were addressed
-6. **Recommendation** - Go/No-Go with rationale
-7. **Implementation Considerations** - Next steps, timeline, and resource needs
-
----
-
-**Last Updated:** February 2026

package/skills/jarvis/engineering-team/business-growth/sales-engineer/references/rfp-response-guide.md

@@ -1,189 +0,0 @@
-# RFP/RFI Response Guide
-
-A comprehensive reference for Sales Engineers responding to Requests for Proposal (RFP) and Requests for Information (RFI).
-
-## RFP Response Best Practices
-
-### 1. Pre-Response Assessment
-
-Before investing time in a response, conduct a thorough bid/no-bid assessment:
-
-**Bid Criteria Checklist:**
-- Do we have a pre-existing relationship with the customer?
-- Is there an identified champion or sponsor?
-- Do our capabilities align with >70% of requirements?
-- Is the deal size justified against the response effort?
-- Do we understand the competitive landscape?
-- Is the timeline realistic for our solution?
-
-**Red Flags for No-Bid:**
-- No prior customer engagement (blind RFP)
-- Requirement language mirrors a competitor's product
-- Timeline is unrealistically short
-- Must-have requirements fall outside our platform
-- Budget is undefined or misaligned with our pricing
-
-### 2. Response Organization
-
-**Executive Summary (1-2 pages):**
-- Lead with business outcomes, not features
-- Reference the customer's specific challenges
-- Quantify value proposition with relevant metrics
-- State confidence level and key differentiators
-
-**Solution Overview:**
-- Map directly to the customer's stated requirements
-- Use the customer's language and terminology
-- Include architecture diagrams for technical sections
-- Address integration with existing systems
-
-**Compliance Matrix:**
-- Mirror the RFP's requirement numbering exactly
-- Use consistent coverage categories: Full, Partial, Planned, Gap
-- Provide clear explanations for each response
-- Include roadmap dates for "Planned" items
-
-### 3. Coverage Classification
-
-| Status | Score | Definition | Response Approach |
-|--------|-------|------------|-------------------|
-| Full | 100% | Current product fully meets requirement | Describe capability with evidence |
-| Partial | 50% | Met with configuration or workaround | Explain approach and any limitations |
-| Planned | 25% | On product roadmap | Provide timeline and interim solution |
-| Gap | 0% | Not currently supported | Acknowledge gap and propose alternatives |
-
-### 4. Priority-Weighted Scoring
-
-Not all requirements are equal. Weight them by business impact:
-
-- **Must-Have (3x weight):** Core requirements that are deal-breakers. Gaps here typically result in disqualification.
-- **Should-Have (2x weight):** Important requirements that influence the decision significantly.
-- **Nice-to-Have (1x weight):** Desirable but not critical. Often used as tie-breakers.
-
-### 5. Response Writing Tips
-
-**Do:**
-- Answer the question directly before elaborating
-- Use the customer's terminology, not internal jargon
-- Provide specific examples, case studies, and metrics
-- Include screenshots or architecture diagrams where relevant
-- Cross-reference related answers to avoid redundancy
-- Proofread for consistency across sections (multiple authors)
-
-**Avoid:**
-- Marketing fluff or vague language ("best-in-class", "world-class")
-- Answering a question you were not asked
-- Contradictions between sections
-- Overselling capabilities you do not have
-- Ignoring the question format (tables vs. narrative)
-
-## Bid/No-Bid Decision Framework
-
-### Decision Matrix
-
-| Factor | Weight | Score (1-5) | Weighted |
-|--------|--------|-------------|----------|
-| Technical fit | 25% | | |
-| Relationship strength | 20% | | |
-| Competitive position | 20% | | |
-| Deal value vs effort | 15% | | |
-| Strategic importance | 10% | | |
-| Win probability | 10% | | |
-| **Total** | **100%** | | |
-
-**Scoring Guide:**
-- 5: Strong advantage
-- 4: Slight advantage
-- 3: Neutral / competitive parity
-- 2: Slight disadvantage
-- 1: Significant disadvantage
-
-**Decision Thresholds:**
-- Score >= 3.5: **Bid** - proceed with full response
-- Score 2.5 - 3.4: **Conditional Bid** - proceed with executive approval
-- Score < 2.5: **No-Bid** - decline or submit information-only response
-
-### Effort Estimation
-
-Estimate the total effort required and compare against deal value:
-
-| Response Component | Typical Effort (hours) |
-|-------------------|----------------------|
-| Requirements analysis | 4-8 |
-| Technical writing | 16-40 |
-| Architecture diagrams | 4-8 |
-| Demo preparation | 8-16 |
-| Internal review | 4-8 |
-| Final formatting | 2-4 |
-| **Total** | **38-84 hours** |
-
-**Rule of thumb:** The response effort should not exceed 2% of the deal value.
-
-## Compliance Matrix Structure
-
-### Standard Format
-
-```
-| Req ID | Requirement Description | Priority | Compliance | Response | Evidence |
-|--------|------------------------|----------|------------|----------|----------|
-| R-001  | SSO via SAML 2.0       | Must     | Full       | Native SAML 2.0 support... | Config guide |
-| R-002  | Custom reporting        | Should   | Partial    | Standard reports + API... | API docs |
-```
-
-### Section Organization
-
-Organize requirements by category for clarity:
-
-1. **Functional Requirements** - Core features and capabilities
-2. **Technical Requirements** - Architecture, APIs, performance
-3. **Security & Compliance** - Authentication, encryption, certifications
-4. **Integration Requirements** - Third-party systems, data flows
-5. **Support & SLA** - Support tiers, response times, uptime
-6. **Vendor Qualifications** - Company size, financials, references
-
-## Common Pitfalls
-
-### 1. The Wired RFP
-**Symptom:** Requirements language matches a competitor's product feature list.
-**Response:** Focus on outcomes over features. Highlight areas of differentiation. Ask clarifying questions that expose broader needs.
-
-### 2. Feature Checklist Syndrome
-**Symptom:** RFP is a massive feature checklist with no context about business problems.
-**Response:** Group features by business outcome. Add context in your response that demonstrates understanding of the underlying need.
-
-### 3. Scope Creep in Response
-**Symptom:** Team keeps adding content that was not requested.
-**Response:** Assign a response manager to enforce scope. Answer what was asked, provide references for additional information.
-
-### 4. Inconsistent Messaging
-**Symptom:** Multiple authors provide contradictory information.
-**Response:** Assign a single editor for final review. Create a response style guide. Use consistent terminology throughout.
-
-### 5. Overcommitting on Gaps
-**Symptom:** Marking "Planned" items as "Full" to improve scores.
-**Response:** Never misrepresent coverage. Planned items with firm timelines and interim workarounds are better than lies discovered during POC.
-
-## RFP Response Timeline Management
-
-### Typical Response Timeline
-
-| Day | Activity |
-|-----|----------|
-| Day 1 | Receive RFP, conduct initial review, assign team |
-| Day 2-3 | Bid/no-bid decision, questions submission |
-| Day 4-7 | Requirements analysis, coverage assessment |
-| Day 8-14 | Draft responses, architecture diagrams |
-| Day 15-17 | Internal review, quality check |
-| Day 18-19 | Final edits, formatting, executive review |
-| Day 20 | Submission |
-
-### Time-Saving Strategies
-
-1. **Maintain a response library** - Reusable answers for common requirements
-2. **Pre-built architecture diagrams** - Template diagrams for common integration patterns
-3. **Standardized compliance language** - Pre-approved language for security and compliance sections
-4. **Question templates** - Standard clarifying questions for common ambiguities
-
----
-
-**Last Updated:** February 2026