"The project is Red" seems less accountable and clear compared to "I have low confidence that I will hit the date listed."
The core of your question presumes that:
- Personal accountability is the goal (or at least a desirable outcome).
- A person's confidence in something is an accurate measure of project status.
- Feelings are an objective measurement.
I think the presumptions are, at best, solving the wrong problem. I assume the underlying problem is really "Why is my project not currently within tolerance?"
If you want to communicate effectively about your project, be clear and concise. If a project is out of tolerance, always inspect project and organizational processes first. "Accountability" is generally a poor substitute for good processes or efficient dynamics.
Red, Yellow, and Green
Red, yellow, and green are often used simply because they are very visual, and because they correspond to traffic light signals that most people are already familiar with. This makes the cognitive load low.
A sea of green means everything's okay. A few red dots draw attention to problem areas. A sea of yellow or red indicate a project that's badly off-track.
Accuracy Doesn't Depend on Encoding
Can people misrepresent the status of a project? Sure. Even if you aren't using color codes, how many projects have 60% of tasks at 80% completion? Are those numbers any more honest than the color codes? Even if they are, what does that actually mean? Is it within the expected range of values, or not?
Red, yellow, and green are no more (or less) honest than any other metric. But as long as everyone agrees on what the colors mean, they communicate more efficiently about the urgency of a status.
Personally, I'd pay more attention to a work package that's flashing Yellow Alert! than something marked 63.2% complete, plus or minus 3%, with an 85% confidence level of 6.8% schedule slippage. YMMV, I suppose.
Saying "the project schedule is out of tolerance by six weeks" is more objective than saying "Joe doesn't feel confident that he can embiggen his widget by next Tuesday." The first is useful information about the status of the project, while the second is either a way to blame Joe for something that may represent a broader process problem, or perhaps even to blame him for not drinking the project-approved Kool-Aid.
If your immediate follow-up question is "Why isn't Joe confident that he can embiggen the widget before the Gantt chart says it should be embiggened?," then at least you're trying to investigate a process problem that has the potential to impact the project.
If that's not the point of measuring the confidence of task performers, then it basically amounts to scapegoating anyone who isn't buying into the defined management targets. Would you rather Joe say "Rah! Rah! I feel absolutely, positively confident that my widget will be embiggened by next Tuesday!" even though no one's even sourced a widget supplier yet? You're either encouraging him to lie, or holding him responsible for something outside his control. Either way, it can't end well for ol' Joe unless he bails on the project before it implodes in fiery failure.
Focusing on the project's process and overall progress is generally more constructive than blaming individuals. If you're worried that individuals will be motivated to pass the buck, you might want to spend more time thinking about why they are motivated to avoid responsibility on the project than on trying to hold their toes to the fire.
In my experience, if you fix the project dymanics, and the project usually fixes itself. Your mileage will vary.