Six Thinking Hats

Let me put on the White Hat first—the hat of pure facts and data. Picture a neutral observer with a clipboard, no opinions, just what happened. From what you describe, the missed deadline is a fact. The back-and-forth on scope is a fact. But what we don’t know yet is the cost of that flexibility versus the cost of a wrong build.

Ask yourself: How many days did the scope changes actually add? Did any of them prevent a rework that would have taken longer? Do you have a record of which features were added, dropped, or changed, and the reason behind each? Without that, you’re guessing.

The White Hat doesn’t judge—it gathers. So before we decide if locking earlier was the mistake, let’s pull the timeline, the change log, and the team’s velocity data. Then we’ll know if the flexibility was a safety net or a trap. What does your data actually say about where the time went?

Great question — let’s put on the White Hat first, focusing purely on facts and data, not feelings. What do we actually know? Strict roles with rubrics give you measurable, comparable outcomes per student, which can reduce bias because criteria are explicit and applied uniformly. However, research on cooperative learning (e.g., Johnson & Johnson) shows that rigid roles sometimes reduce organic problem-solving and can mask free-riding if rubrics reward individual output over process. Self-organization, on the other hand, often boosts ownership and peer accountability, but without structure, assessment becomes murkier—you may rely on subjective impressions of participation, which invites bias. Look at your past classes: do students with louder voices dominate self-organized groups? Do quiet but capable students get overlooked? Also check your school’s grading policy—does it require individual accountability? If yes, strict rubrics make that easier to defend. My advice: don’t choose one wholesale. Use a hybrid—define clear outcome criteria (what good collaboration looks like) but let groups choose their internal roles and process. That way you grade the product and a brief self/peer reflection, not your guess about who did what. This reduces bias while preserving autonomy. Would you like to explore the Yellow Hat next to weigh the benefits of each option more concretely?

Let me guide you through the White Hat first — the hat of pure facts and data, like a calm accountant who only reads spreadsheets. Put it on and ask: What is your current gross margin on this client? If your margin is 30%, a 20% discount eats most of your profit, leaving only 10% before overhead. What is the exact revenue this client generates monthly? What does the longer contract — say two years instead of one — actually lock in? Calculate the total lost revenue over that period versus the cost of acquiring a new client to replace them if they leave. Also check: does this client pay on time, require extra support, or buy add-ons? The White Hat doesn't judge — it just lays out the numbers. If the discount drops you below your break-even point, no amount of goodwill pays the rent. But if it keeps you at, say, 15% margin and guarantees cash flow for 24 months, the math might support it. Write down the figures before you let any emotion in. That is the first step — get the raw data on the table, then we can put on the Red Hat and talk about how it feels.