Creating Lessons

Learn how to capture valuable insights from your bid experiences using Cothon's structured lesson creation form.

Overview

Creating a lesson is the first step in building your organization's knowledge base. The lesson creation form guides you through documenting the context, insights, and action items from any bid experience—whether it was a win, loss, or process learning.

Accessing the Creation Form

Method 1: From the Lessons Dashboard

Method 2: From a Bid Analysis

When you're already viewing a completed bid analysis:

1. Click the Actions menu in the top right
2. Select Create Lesson
3. The form pre-populates with bid context

Method 3: From an Opportunity

After deciding not to pursue an opportunity:

1. Open the opportunity detail page
2. Click Record No-Bid Lesson
3. Document why you passed on the opportunity

Method 4: Keyboard Shortcut

Press (Mac) or (Windows) from anywhere in Cothon to open the lesson creation form.

Lesson Creation Form

The form consists of six main sections:

1. Basic Information

Lesson Title (Required)

• Keep it concise (50-100 characters)
• Make it searchable—use keywords your team will recognize
• Include the outcome if relevant

Good examples:

• "Win: Technical approach with phased delivery won ISED contract"
• "Loss: Underestimated timeline on healthcare integration RFP"
• "Process: Daily standups reduced proposal revisions by 40%"
• "Technical: Cloud migration strategy for legacy systems"

Poor examples:

• "Lesson from last week" (too vague)
• "Things we learned" (not specific)
• "Important" (meaningless)

Lesson Category (Required)

Choose the primary category:

Lesson Date (Required)

• When did this learning occur?
• Defaults to today but can be backdated
• Used for trend analysis and temporal pattern recognition

Visibility (Required)

Control who can see this lesson:

• Organization-wide (default) - All team members
• Department only - Limited to specific department
• Leadership only - Executives and designated reviewers
• Private - Only you and explicitly shared users

2. Context & Background

Related Bid (Optional but Recommended)

Link to the specific bid analysis or opportunity:

• Select from dropdown of recent bids
• Auto-fills many fields from the bid metadata
• Enables cross-referencing and pattern detection

If no bid is linked, provide manual context:

Project Name

• What was the opportunity or project called?
• Use the official RFP title if available

Client/Department

• Which government department or agency?
• Select from predefined list or add custom

Contract Value (Optional)

• Total contract value or your bid amount
• Helps with value-range pattern analysis
• Format: $XXX,XXX (automatically formatted)

Project Type

• IT services, construction, consulting, equipment, etc.
• Select from dropdown or create custom type
• Used for similarity matching

Bid Outcome (For Win/Loss Categories)

Select the result:

• Won - You were awarded the contract
• Lost - Another vendor won
• No-Bid - Decided not to submit
• Cancelled - Opportunity was cancelled by client
• Pending - Outcome not yet known

Your Score (Optional)

• Technical score, total score, or ranking
• Helps analyze scoring patterns over time

Winner Score (For Losses)

• What did the winning bidder score?
• Enables gap analysis

Competitor Information (Optional)

• Who won (if known)?
• Number of bidders
• Competitive insights

3. The Lesson

What Happened? (Required) Describe the situation, event, or experience:

• What was the context?
• What actions did you take?
• What was the result?

Aim for 2-3 paragraphs (200-400 words).

Good example:

"During the ISED Cloud Migration RFP, we proposed a phased delivery approach with three incremental milestones instead of the traditional big-bang deployment. Each phase included dedicated UAT windows and rollback capabilities. The evaluation panel specifically highlighted this as a differentiator in the technical debrief, noting it reduced their perceived risk. We scored 48/50 on the implementation approach section compared to an average of 38/50 for other bidders."

Poor example:

"We did well on the technical approach."

Why Did It Happen? (Required) Analyze the root cause:

• What factors contributed to the outcome?
• Were there underlying reasons beyond the surface explanation?
• What assumptions proved correct or incorrect?

Aim for 1-2 paragraphs (150-300 words).

Good example:

"The phased approach resonated because we spent time understanding the client's past experience with failed big-bang migrations in the initial Q&A session. Their questions revealed risk aversion around downtime and data loss. By explicitly addressing these concerns in our methodology, we demonstrated client-centric thinking. Additionally, our PM had direct experience with a similar phased migration at another department, giving us credibility and specific examples."

What Should We Do Differently? (Required) Actionable recommendations for future bids:

• Specific changes to strategy, process, or approach
• Concrete next steps
• Measurable improvements

Use bullet points for clarity. Aim for 3-7 actionable items.

Good example:

• Always probe for past project failures in Q&A sessions to uncover hidden concerns
• Lead with risk mitigation in the executive summary when the client has experienced past failures
• Assign PM with relevant domain experience even if it means pulling from another project
• Quantify risk reduction - we should have calculated the downtime reduction (did this in debrief, would have been powerful in proposal)
• Include rollback plan in methodology section as a standard practice for complex integrations

Poor example:

• Do better risk mitigation
• Assign experienced people

Supporting Evidence (Optional)

Add credibility with:

• Debrief notes or scorecards (upload as attachments)
• Email excerpts from the client
• Competitor intelligence
• Metrics and data points
• Screenshots or excerpts from proposals

4. Tagging & Classification

Tags (Recommended)

Add descriptive keywords for easy discovery:

Suggested tag types:

Department/Agency

• ISED, PSPC, DND, Health-Canada, CRA

Project Type

• IT-services, cloud-migration, software-development, infrastructure, consulting

Technical Areas

• AWS, Azure, cybersecurity, data-analytics, integration

Process/Strategy

• phased-delivery, agile, fixed-price, risk-mitigation, team-structure

Themes

• pricing-strategy, resource-constraints, timeline-management, proposal-quality

Custom Fields (If Configured)

Your organization may have custom metadata fields:

• Geographic region
• Business unit
• Strategic priority level
• Customer segment

5. Team & Attribution

Contributors (Recommended)

Tag team members who were involved:

• Bid manager
• Proposal writers
• Technical leads
• Subject matter experts
• Reviewers

Benefits:

• Gives credit to team members
• Enables "who knows what" searches
• Identifies knowledge holders for future questions
• Recognizes contributions

Author Notes (Optional)

Add context about who created the lesson:

• "Documented by proposal team lead Sarah Chen based on debrief meeting with full team"
• "Created from technical lead's post-project retrospective"

6. Action Items

Turn insights into concrete next steps:

Example action items:

Learn more: Action Items Management

Form Features

Auto-Save

The form automatically saves your progress every 30 seconds:

• Draft lessons are saved to your account
• Resume editing from any device
• Unsaved changes indicator shows when content is pending save

Templates

Speed up creation with templates:

Using Templates:

1. Click Load Template at the top of the form
2. Select from pre-built templates (Win Analysis, Loss Analysis, Process Improvement, Technical Learning)
3. Fill in the placeholders with your specific details

Creating Templates:

1. Complete a lesson that represents a good structure
2. Click Save as Template
3. Name the template and mark which fields should be placeholders
4. Template is now available for future lessons

Default Templates:

Win Analysis Template

• Structured to capture competitive differentiators
• Includes sections for scoring analysis
• Prompts for replicable strategies

Loss Analysis Template

• Root cause analysis framework
• Competitor strength assessment
• Gap identification and remediation

Process Improvement Template

• Before/after comparison
• Efficiency metrics
• Implementation steps

Technical Learning Template

• Technical challenge description
• Solution approach
• Lessons for future technical proposals

Rich Text Editor

The lesson form includes a full-featured editor:

Formatting:

• Bold, italic, underline
• Headings (H1-H4)
• Bullet lists and numbered lists
• Block quotes
• Code blocks

Embedding:

• Links to external resources
• Images (drag and drop)
• Tables for data comparison
• Callouts for important notes

Keyboard Shortcuts:

• - Bold
• - Italic
• - Insert link
• - Numbered list
• - Bullet list

Attachments

Upload supporting documents:

Supported File Types:

• Documents: PDF, DOCX, XLSX, PPT
• Images: PNG, JPG, GIF
• Archives: ZIP (for multiple files)

Maximum Sizes:

• Individual file: 25 MB
• Total attachments per lesson: 100 MB

Best Practices:

• Redact confidential information before uploading
• Use descriptive filenames
• Compress large PDFs to reduce file size
• Organize related files in a ZIP folder

Validation

The form validates your input to ensure quality:

Required Field Checks:

• Title must be at least 10 characters
• Category must be selected
• At least one of: What Happened, Why It Happened, or What Should We Do Differently

Data Quality Hints:

• Warns if lesson body is very short (< 100 words)
• Suggests adding tags if none are provided
• Recommends linking to a bid if context is vague
• Flags missing action items for Process category lessons

Error Prevention:

• Duplicate title warning (if similar lesson exists)
• Invalid date detection (future dates, too far in past)
• Attachment virus scanning before upload

Submission Options

When you're ready to save:

Save as Draft

• Lesson is saved but not visible to others
• Appears in your "My Drafts" section
• Can be edited and published later
• No notifications sent

When to use:

• Need to gather more information
• Waiting for debrief meeting notes
• Want manager review before publishing

Submit for Review

If review gates are enabled:

• Lesson is sent to designated reviewers
• You receive a notification when reviewed
• Reviewers can request changes or approve
• Auto-publishes after approval (if configured)

When to use:

• Your organization requires lesson approval
• Dealing with sensitive contract information
• Want expert validation before sharing widely

Learn more: Review Gates

Publish

• Lesson is immediately visible per your visibility settings
• Notifications sent to relevant team members
• Appears in search results and feeds
• Contributes to AI training data

When to use:

• Confident in the content quality
• No approval process required
• Time-sensitive information to share

After Submission

Once your lesson is published:

Notifications

Team members receive alerts based on their preferences:

• Immediate - Real-time notification when lesson is published
• Daily Digest - Summary of new lessons each morning
• Weekly Summary - Roundup of lessons by category
• Relevant Only - Only lessons matching their tags or departments

Editing

You can edit published lessons:

• Click Edit on the lesson detail page
• Changes create a new version with timestamp
• Edit history is preserved
• Notifications optionally sent on significant edits

Versioning:

• All edits are tracked
• View change history on the lesson page
• Revert to previous version if needed

Analytics

Track engagement with your lesson:

• View count - How many people have read it
• Endorsements - How many teammates found it valuable
• Comments - Discussion and additional insights
• Citations - How many times it's been referenced in bids
• Action completion - Status of linked action items

Best Practices

Structure for Searchability

Use specific, keyword-rich titles:

• Include the department, project type, or key technology
• Front-load important words (search algorithms prioritize early terms)
• Avoid jargon that only your team knows

Good: "Win: Agile methodology with daily standups secured PSPC contract" Poor: "How we won the big one"

Be Specific and Measurable

Quantify outcomes whenever possible:

• "Reduced proposal preparation time from 6 weeks to 4 weeks"
• "Increased technical score by 12 points compared to our usual average"
• "Saved $15K by reusing modular proposal sections"

Provide concrete examples:

• Quote specific RFP sections that were challenging
• Name the tools or techniques that worked
• Reference specific proposal pages or sections

Balance Positive and Negative

Even in wins, identify improvements:

• What could have been better?
• What got lucky that might not work next time?
• What did you barely finish in time?

Even in losses, identify successes:

• What parts of the proposal were strong?
• What processes worked well despite the outcome?
• What did you learn that will help next time?

Link to Context

Always link to the related bid when possible:

• Enables automatic pattern matching
• Provides full context for readers
• Powers AI similarity detection

Upload supporting documents:

• Debrief notes
• Scoring evaluations
• Client feedback
• Relevant proposal excerpts (redacted as needed)

Create Actionable Recommendations

Bad: "We need better project management."

Good: "Implement daily 15-minute standups during proposal week (days -7 to -1). Assign a scrum master role to track blockers. Use a shared Kanban board visible to all contributors."

Each recommendation should answer:

• What exactly should be done?
• Who should do it?
• When should it happen?
• Why will this solve the problem?
• How can we measure success?

Use Tags Strategically

Create a tagging taxonomy:

Work with your team to establish standard tags:

• Department codes (consistent abbreviations)
• Technology stacks (standard tech names)
• Methodology approaches (agreed-upon terms)
• Bid characteristics (value ranges, complexity levels)

Don't over-tag:

• 5-10 tags is ideal
• More tags doesn't mean more findable
• Focus on the most distinguishing characteristics

Don't under-tag:

• Minimum 3 tags for any lesson
• Include at least one tag from each category (dept, type, theme)

Involve the Team

Capture lessons collaboratively:

• Hold a debrief meeting with all key contributors
• Assign one person to document, but gather input from everyone
• Use round-robin to ensure all voices are heard

Recognize contributors:

• Tag everyone who participated
• Quote specific insights and attribute them
• Thank people in the lesson notes

Keep It Timely

Document while fresh:

• Schedule the debrief within 48 hours of the outcome
• Memories fade quickly—details matter
• Emotions provide valuable context (what were we worried about?)

But don't rush:

• It's okay to save as draft and add details later
• Sometimes insights emerge days after the event
• Update the lesson when you learn more

Common Pitfalls to Avoid

Vague Generalities

Problem: "Communication was poor and caused delays."

Better: "Daily standups were cancelled during the final week due to competing priorities. This led to three instances where team members duplicated work on the same section, wasting approximately 12 hours. Resume daily standups in the final week, making them non-optional."

Blame Culture

Problem: "John didn't deliver his section on time, which made us lose."

Better: "Technical SME deliverables were delayed by 3 days due to unclear requirements from the bid manager. Implement a requirements checklist that SMEs sign off on at kickoff to ensure alignment on expectations and deadlines."

Focus on process failures, not personal failures.

No Clear Takeaway

Problem: Long description of what happened with no actionable recommendations.

Better: Always end with "What Should We Do Differently?" section containing specific, assignable actions.

Too Much Detail

Problem: 3000-word essay recounting every meeting and decision.

Better: 400-600 words covering the critical context, root cause, and recommendations. Link to detailed documents as attachments.

Too Little Detail

Problem: "We won because we had a good technical approach."

Better: "We won by proposing a phased delivery model with incremental UAT windows and rollback capabilities, which addressed the client's past experience with failed big-bang migrations. This scored 48/50 vs. average of 38/50."

Missing Action Items

Problem: Great analysis but no follow-through on improvements.

Better: Create 2-4 concrete action items with assignees and deadlines. Track completion.

Not Linking to Bids

Problem: Standalone lesson with no connection to the actual bid.

Better: Always link to the related bid analysis or opportunity. If it doesn't exist in Cothon, at minimum include RFP number and client name for traceability.

Examples

Example 1: Win Lesson

Title: "Win: Phased Cloud Migration Approach Secured $2.4M ISED Contract"

Category: Win

Tags: ISED, cloud-migration, AWS, phased-delivery, risk-mitigation, technical-approach

What Happened: We won a $2.4M cloud migration contract with Innovation, Science and Economic Development (ISED) by proposing a phased delivery model with three incremental milestones instead of the traditional big-bang deployment approach. Our technical score was 48/50 compared to an industry average of 38/50. The evaluation committee specifically highlighted our risk mitigation strategy in the debrief.

The RFP required migration of 45 legacy applications from on-premise data centers to AWS. Most bidders proposed a 6-month timeline with a single cutover event. We proposed a 9-month timeline with three phases:

• Phase 1 (months 1-3): Low-risk applications with minimal integration
• Phase 2 (months 4-6): Medium-complexity applications
• Phase 3 (months 7-9): Mission-critical applications with extensive integration

Each phase included dedicated UAT windows, rollback procedures, and go/no-go decision gates.

Why It Happened: During the Q&A session, the procurement officer's questions revealed that ISED had experienced a failed big-bang migration 18 months prior, resulting in 3 days of downtime and significant political fallout. By probing these questions, we identified risk aversion as a hidden evaluation criterion.

Our PM had direct experience with a similar phased migration at Public Services and Procurement Canada (PSPC), giving us specific examples and credibility. We quantified the risk reduction: our approach would limit maximum downtime to 4 hours for any single phase versus 72+ hours in a big-bang approach.

What Should We Do Differently:

• Always probe for past project failures in Q&A sessions - specific questions about "previous migration experiences" can uncover hidden concerns
• Lead with risk mitigation in the executive summary when client has experienced past failures - make it the first thing evaluators read
• Assign PM with relevant domain experience even if it means pulling from another active project - credibility matters more than availability
• Quantify risk reduction - we calculated downtime reduction in our internal analysis but should have featured it prominently in Section 3
• Include rollback plan details in methodology section - we mentioned rollback but didn't provide the detailed procedures until appendix (evaluators may not have read that far)

Action Items:

1. Update cloud migration proposal template to include phased delivery as default approach (assigned to Proposal Manager, due in 2 weeks, high priority)
2. Create risk mitigation library with 10 common failure scenarios and quantified mitigation strategies (assigned to Solutions Architect, due in 1 month, high priority)
3. Schedule training session: "Probing for Client Pain Points in Q&A" (assigned to Bid Manager, due next team meeting, medium priority)

Example 2: Loss Lesson

Title: "Loss: Underestimated Integration Complexity on Healthcare RFP"

Category: Loss

Tags: Health-Canada, system-integration, timeline-estimation, technical-approach, pricing

What Happened: We lost a $1.8M healthcare integration RFP to a competitor who bid $2.2M and a 12-month timeline. We proposed $1.6M and 8 months. The debrief revealed we scored 32/50 on technical approach versus the winner's 46/50. Evaluators noted our timeline was "unrealistic" and our integration approach "underestimated complexity."

Our proposal assumed the client's existing systems would have well-documented APIs and data models. The SOW mentioned "legacy systems" but we interpreted this as systems from the early 2000s (which often have decent documentation). In reality, they had mainframe systems from the 1980s with minimal documentation and undocumented business logic.

Why It Happened: We didn't ask the right questions during the site visit. Our Solutions Architect asked about "API documentation availability" but didn't explicitly ask to see the documentation or inquire about the age of the systems. The client said "documentation exists" which we took at face value.

We also priced based on our most recent integration project, which involved modern microservices. We applied a 1.5x complexity multiplier for "legacy systems" but should have applied 2.5-3x based on mainframe integration complexity.

Our pricing pressure came from trying to be competitive. We cut the timeline to 8 months (from our initial internal estimate of 11 months) to match a rumored competitor timeline. This made our bid look more attractive on price but undermined our credibility on the technical approach.

What Should We Do Differently:

• Request to review actual API documentation during site visits - don't take "documentation exists" at face value
• Explicitly ask about system age and technology stack - "legacy" can mean anything from 5 to 40 years old
• Use 3x complexity multiplier for mainframe integrations - update our estimating guidelines
• Never cut timeline to be competitive if it undermines technical credibility - evaluators see through this
• Build 20% contingency into integration projects with unknowns - we were too confident in our estimate
• Propose discovery phase for projects with legacy unknowns - 2-month discovery before full implementation commitment

Action Items:

1. Update integration project estimating guidelines with mainframe complexity multipliers (assigned to Estimating Lead, due in 1 week, high priority)
2. Create site visit checklist with specific questions about system age, documentation, and integration points (assigned to Solutions Architect, due in 2 weeks, high priority)
3. Develop discovery phase proposal template for high-uncertainty integration projects (assigned to Proposal Manager, due in 3 weeks, medium priority)
4. Post-mortem presentation to full team on estimation biases (assigned to Bid Manager, due next team meeting, medium priority)

Example 3: Process Lesson

Title: "Process: Daily Standups Reduced Proposal Revisions by 40%"

Category: Process

Tags: proposal-development, team-collaboration, agile, efficiency

What Happened: On the Department of National Defence (DND) cybersecurity RFP, we experimented with daily 15-minute standups during the final 2 weeks of proposal development. This reduced our revision cycles from an average of 5 per proposal to 3, saving approximately 32 hours of rework.

Previous proposals suffered from misalignment between sections, duplicated content, and inconsistent messaging. Writers would work in isolation for several days, then discover conflicts during the final review. This led to extensive rewriting in the last 48 hours before submission.

With daily standups, each team member shared:

• What section they completed yesterday
• What section they're working on today
• Any blockers or questions

We used a shared Kanban board to visualize progress. The PM acted as scrum master, tracking blockers and facilitating quick decisions.

Why It Happened: The proposal had 6 contributors working on different sections simultaneously. Without daily check-ins, people made assumptions about what others were writing. For example, both the technical approach and the project management sections described our risk management process, but with different frameworks. This confusion only emerged during final review.

Daily standups created awareness of what everyone was doing. When the technical writer mentioned "describing our agile risk management process," the PM writer immediately said "I'm doing that in my section too" and they aligned in real-time.

The Kanban board visualization helped identify bottlenecks. When the pricing section showed "blocked" for 2 days, the PM immediately intervened and discovered the estimating lead was waiting on a clarification that no one had asked for.

What Should We Do Differently:

• Make daily standups mandatory for all proposals > 50 pages - the coordination value outweighs the 15-minute time cost
• Assign a dedicated scrum master role (usually the PM or bid manager) to track blockers and facilitate
• Use a shared digital Kanban board - we used Trello, but any visual tool works
• Start standups at day -14 (14 days before submission), not just the final week
• Include reviewers in the standups so they know what's coming and can provide early feedback
• Document decisions made in standups - we lost track of a few verbal agreements

Action Items:

1. Add "daily standups" as mandatory step in proposal development playbook for proposals > 50 pages (assigned to Proposal Manager, due in 1 week, high priority)
2. Create standup facilitator guide with sample agendas and blocker resolution tips (assigned to Bid Manager, due in 2 weeks, medium priority)
3. Purchase Kanban board tool license for proposal team (assigned to Operations Manager, due in 3 weeks, low priority)
4. Train all proposal contributors on agile collaboration techniques (assigned to Proposal Manager, due in 1 month, medium priority)

Frequently Asked Questions

Next Steps

Now that you know how to create lessons:

• Browse & Filter Lessons - Find and learn from existing lessons
• Manage Action Items - Turn insights into concrete follow-through
• Explore Analytics - Discover patterns in your lessons
• Configure Review Gates - Set up approval workflows