How We Work on Projects

The practical approach to managing projects at Kyndof—from costume design for K-pop comebacks to internal system improvements

개요

Projects at Kyndof span two very different worlds: high-stakes costume design for major K-pop artists, and internal operations improvements that make the company run better. Despite these differences, our project approach follows consistent principles that work for both domains.

This page explains how we actually run projects—not abstract theory, but the day-to-day practices that turn ideas into delivered results. Whether you're coordinating a comeback costume package or building a new internal tool, these frameworks guide the work.

Understanding our project methodology helps you:

• Navigate from idea to execution without getting lost in process
• Know when to be rigorous vs. when to move fast
• Coordinate effectively across teams and departments
• Avoid common failure patterns while maintaining momentum

Two Worlds of Projects

Kyndof operates in fundamentally different project domains that require adapted approaches:

Client-Facing Projects (Costume Design)

Client projects center on delivering custom costumes for K-pop artist comebacks, concerts, and performances. These projects have hard, immovable deadlines—the comeback date doesn't shift because we need more time. The stakes are extremely high: costumes appear in music videos, broadcast performances, and marketing materials seen by millions.

Key characteristics:

• Fixed deadlines - Comeback dates set months in advance, zero flexibility
• High visibility - Work appears in music videos and broadcast performances
• Client-driven scope - Requirements come from artist teams and management companies
• Quality non-negotiable - Costumes must be perfect; "good enough" doesn't exist
• Fast iteration - Design feedback cycles measured in hours, not days

These projects demand exceptional execution discipline, rapid decision-making, and flawless quality control. There's no room for "we'll fix it in post"—the costume must be right when it leaves our studio.

Internal Projects (Systems & Operations)

Internal projects improve how Kyndof operates: better tools, streamlined processes, enhanced capabilities, and organizational development. Unlike client work, these projects have flexible timelines and serve internal stakeholders who understand the business context and constraints.

Key characteristics:

• Flexible timelines - Can adjust schedule based on priorities and resources
• Iterative delivery - Can ship incrementally and improve over time
• Learning objectives - Often exploring new approaches or validating hypotheses
• Internal stakeholders - Users who understand tradeoffs and participate in development
• Continuous evolution - Systems improve gradually rather than launching "finished"

Internal projects allow more experimentation, iterative refinement, and learning-focused approaches. We can ship 80% solutions and iterate, test hypotheses, and adapt based on usage patterns.

The RABSIC Framework

Every Kyndof project operates through the RABSIC accountability framework. This isn't bureaucratic overhead—it's how we ensure clarity about who does what while preventing the chaos of unclear responsibility.

RABSIC defines six distinct roles in every decision or project:

R - Responsible

The person who does the actual work and delivers the output. They execute tasks, make tactical decisions within their scope, and produce deliverables. Projects can have multiple Responsible parties, but one person serves as primary Responsible coordinating the work.

Example: For a costume project, the lead designer is Responsible for creating the design. For an internal tool, the developer is Responsible for building it.

A - Accountable

The single person who owns the outcome and has final approval authority. There is always exactly one Accountable party per project—this is non-negotiable. The Accountable person doesn't necessarily do the work, but they own the result and make final calls on scope, quality, and completion.

Example: For client projects, the Creative Director is typically Accountable. For internal systems, the CTO is Accountable for technical projects.

B - Backup

The person who steps in if the Responsible party is unavailable. Backups don't participate in day-to-day work—they're insurance against key-person risk. When the primary Responsible is sick, on vacation, or overloaded, the Backup takes over.

Example: The senior designer serves as Backup for the lead designer on costume projects. The senior developer backs up the primary developer on technical projects.

S - Support

People who actively help the Responsible party complete the work. Support doesn't mean cheerleading from the sidelines—it means rolling up sleeves and contributing. Support shares the workload, provides resources, removes blockers, and assists execution.

Example: Production team members Support costume projects by sourcing materials and coordinating with manufacturers. Operations team members Support internal projects by gathering requirements and testing.

I - Informed

People who receive updates after decisions are made. This is passive notification—they don't provide input or approval, just awareness. Informed parties get told what happened so they can adjust their own work or stay aligned.

Example: Marketing team is Informed about costume completion so they can plan photoshoots. The CEO is Informed about internal system launches to maintain awareness.

C - Consulted

People whose expertise or input is sought before decisions are made. This is two-way communication—Consulted parties provide advice, raise concerns, and influence direction. However, Consulted doesn't mean veto power; the Accountable party makes the final call.

Example: Stylists are Consulted on costume designs to ensure alignment with overall concept. Department heads are Consulted on operational changes affecting their teams.

How RABSIC Prevents Common Problems

Problem: Decision Paralysis

Without RABSIC: Everyone thinks someone else will decide, so nobody acts. With RABSIC: The Accountable party has clear authority and responsibility to make the call.

Problem: Blame Shifting

Without RABSIC: When things go wrong, everyone points fingers. With RABSIC: Accountable owns the outcome; Responsible owns the execution. Blame is unambiguous.

Problem: Over-Collaboration

Without RABSIC: Every decision involves everyone, meetings multiply, progress stalls. With RABSIC: Only Consulted parties participate in decisions; Informed parties just receive updates.

Problem: Single Points of Failure

Without RABSIC: Key person unavailable means project stops. With RABSIC: Backup role ensures continuity when primary Responsible is unavailable.

Project Types and RABSIC Patterns

Different project types follow predictable RABSIC patterns:

Client Costume Projects

Role	Typical Assignment
R	Lead Designer (primary), Pattern Maker, Seamstress
A	Creative Director
B	Senior Designer
S	Production Coordinator, Material Sourcer
I	Client Team, Marketing Team
C	Client Stylist, Artist Management

The Creative Director (A) owns the outcome and approves final delivery. The Lead Designer (R) creates the design and coordinates execution. Client Stylist (C) provides input during design phase. Client Team (I) receives updates as work progresses.

Internal System Projects

Role	Typical Assignment
R	Lead Developer (primary), Designer, QA Tester
A	CTO or Department Head
B	Senior Developer
S	Operations Team, Power Users
I	CEO, Affected Department Heads
C	Department Representatives, Domain Experts

The CTO (A) owns the outcome and approves scope/quality. The Lead Developer (R) builds the system and coordinates implementation. Department Representatives (C) provide requirements and feedback. Affected teams (I) receive updates on progress.

Process Improvement Projects

Role	Typical Assignment
R	Process Owner (primary), Team Leads
A	CEO or Operations Director
B	Senior Manager
S	Affected Team Members
I	All Staff
C	Department Heads, Key Stakeholders

The Operations Director (A) owns the outcome and approves new process. The Process Owner (R) designs and implements the change. Department Heads (C) provide input on impact to their teams. All staff (I) receive training and updates.

Daily Project Practices

Morning Sync (15 minutes)

Every project team does a quick morning sync covering:

• What did I complete yesterday?
• What am I working on today?
• What's blocking me?

This isn't a status report meeting—it's a coordination tool. Teams share information, identify blockers, and adjust daily plans. For distributed teams, async updates in Slack work fine; co-located teams sync in person.

Weekly Review (30 minutes)

Once a week, project teams review progress against plan:

• Are we on track for milestones?
• What risks materialized this week?
• What decisions need escalation?
• What help do we need?

The Accountable party attends weekly reviews to make decisions and remove blockers. Consulted parties join when their input is needed. Informed parties can skip—they'll get the summary.

Milestone Validation

At each milestone, explicit validation confirms the work is complete and meets quality standards. Validation isn't rubber-stamping—it's critical review with specific acceptance criteria.

For costume projects, milestone validation includes:

• Design approval from client stylist
• Sample garment fit check
• Final garment quality inspection
• Client acceptance before delivery

For internal projects, milestone validation includes:

• Feature completeness check
• Testing and QA signoff
• User acceptance from stakeholders
• Documentation review

Decision Documentation

Significant project decisions get documented with context, alternatives considered, and rationale. This prevents relitigating decisions and provides future reference when people ask "why did we do it this way?"

Decision documentation includes:

• Context - What situation prompted this decision?
• Alternatives - What options did we consider?
• Decision - What did we choose?
• Rationale - Why did we choose it?
• Consequences - What are the implications?

The Librarian agent manages decision documentation, ensuring decisions are captured in the knowledge graph for future reference.

Resource Coordination

Projects compete for limited resources: designer time, developer capacity, production resources, and budget. Effective resource coordination prevents conflicts and maintains portfolio health.

Capacity Planning

Teams track capacity in weekly increments, accounting for:

• Existing project commitments
• Vacation and time off
• Administrative and operational work
• Buffer for unexpected urgent work

When new projects request resources, capacity planning shows whether we can say yes or need to adjust priorities.

Priority Frameworks

When multiple projects need the same resources, priority determines allocation:

1. Client commitments - Paying clients with fixed deadlines get priority
2. Strategic initiatives - CEO/CTO-sponsored strategic work comes next
3. Operational maintenance - Keeping systems running is non-negotiable
4. Improvement projects - Nice-to-have enhancements wait until capacity exists

This hierarchy is explicit and transparent—everyone knows how priorities work, reducing conflict and enabling faster decisions.

Resource Conflicts

When resource conflicts arise, the Orchestrator agent escalates to leadership:

• What projects are competing?
• What's the impact of delaying each option?
• What's the strategic priority?

Leadership makes the priority call, and teams adjust plans accordingly. No silent competition, no political maneuvering—just explicit prioritization.

Quality Standards

Quality expectations vary dramatically between project types:

Client Project Quality

Client projects demand perfection:

• Zero defects in delivered costumes
• Exact specification match (color, fit, details)
• Flawless craftsmanship
• On-time delivery with no excuses

We inspect every garment multiple times, conduct fit checks with models matching artist measurements, and maintain quality control checklists covering hundreds of details. Client work accepts no shortcuts—it's done right or not delivered.

Internal Project Quality

Internal projects balance quality with pragmatism:

• Core functionality must work reliably
• User experience should be intuitive and efficient
• Documentation must enable self-service
• Performance should be acceptable, not perfect

Internal projects can ship 80% solutions and iterate. If a tool is usable but not polished, we ship it and improve based on usage. Pragmatic quality lets us move faster and learn more.

Communication Patterns

Status Updates

Projects publish regular status updates through Notion and Slack:

• Weekly for active projects with broad stakeholder interest
• Milestone-based for longer-term internal initiatives
• Daily for high-stakes client work approaching deadlines

Updates include progress summary, upcoming milestones, blockers needing attention, and decisions requiring input. The Back-Writer agent publishes updates automatically based on project state.

Escalation Paths

When projects hit blockers requiring decisions beyond team authority, clear escalation paths move fast:

1. Team → Responsible - Team members escalate to primary Responsible
2. Responsible → Accountable - Responsible escalates to Accountable for decisions
3. Accountable → Leadership - Accountable escalates to CEO/CTO for strategic calls
4. Leadership → Board - Leadership escalates to Board for governance matters

Each escalation includes context, options, and recommendation. Escalation isn't failure—it's the correct process for decisions requiring higher authority.

Feedback Loops

Projects establish feedback loops with stakeholders:

• Client projects: Daily check-ins during active design, immediate feedback on samples
• Internal projects: Weekly user testing sessions, monthly usage analytics reviews

Fast feedback loops catch issues early when they're cheap to fix. Slow feedback leads to expensive rework or failed projects.

Project Failure Patterns (and How to Avoid Them)

Unclear Accountability

Pattern: Everyone thinks someone else is responsible; nobody drives the project forward. Fix: Assign explicit RABSIC matrix at project start with exactly one Accountable party.

Scope Creep

Pattern: Project gradually expands beyond original scope; timeline and budget explode. Fix: Document scope boundaries explicitly; require Accountable approval for scope changes.

Resource Overcommitment

Pattern: Team members spread across too many projects; nothing completes on time. Fix: Enforce capacity planning; limit concurrent project assignments per person.

Silent Risks

Pattern: Team knows about risks but doesn't escalate; risks materialize and cause crisis. Fix: Maintain visible risk register; review in weekly syncs; reward early escalation.

Stakeholder Neglect

Pattern: Team executes in isolation; delivers solution that doesn't meet stakeholder needs. Fix: Engage Consulted parties during design; validate with Informed parties before completion.

Premature Closure

Pattern: Project declared "done" but missing key deliverables, documentation, or handoff. Fix: Use explicit closure checklist; require Accountable signoff on completion.

Tools We Use

Notion

Primary project management platform:

• Project database with status tracking
• Task breakdown and assignment
• Documentation and specifications
• Client communication records

Slack

Real-time communication and updates:

• Project channels for team coordination
• Status update bot notifications
• Quick decision-making conversations
• File sharing and feedback

GitHub

Technical project management:

• Code repository and version control
• Issue tracking for bugs and features
• Pull request reviews
• Technical documentation

Knowledge Graph

Organizational memory:

• Decision documentation with full context
• Entity relationship tracking
• Historical project patterns
• Lessons learned capture

The Librarian agent manages knowledge graph updates, ensuring project learnings feed organizational intelligence.

---

관련 문서

• Project Lifecycle - Detailed phases and gates
• Active Projects - Current initiatives
• RABSIC Framework - Complete accountability model
• Decision Making - Major decisions and context