Friday, January 16, 2009

CYA - the hidden tax on projects

How much of our daily activities are spent with CYA activities? half? sounds crazy, but in many development groups CYA is the primary focus and directly promoted by Sr. Management. What type of activities am I talking about? Any that are primarily done to ensure that you have a log to prove that you are doing your job and any potential blame belongs to someone else. 

How does management promote this? When the focus is on blame instead of problem solving and delivery…when the focus is on discussing why things are not getting done rather then on what's getting in the way and how to remove the obstacles....

How much time is spent on CYA? It’s sometimes hidden, but it’s definitely exponential in growth. Once one person starts, it spreads like wild fire and emails, bug tickets, memos, meetings and more meetings….  When the focus is moved from problem solving to tracking and blaming the costs of running a project increase in relation to real progress..WHAT? what is it that you said? how else can you effectively manage a project if not assigning tasks, bugs, etc. to people and monitoring the results?  It's in the how it's done and your intention of doing it which starts to move the needle from making progress to CYA.  Let’s look at some examples:

Bug Tracking – when the goal is to assign the bug to someone else, a cold hand off without you knowing what the other person’s priorities are, workload or if there is enough information for the person to actually respond/address the issue…..a clear toss over the wall.

Email - #1 CYA tool – sending emails informing others of issues, upcoming tasks, Sr. Management concerns, etc….’gee – I told Bill about this a month ago, he should have handled it by know….’

How do we control it? With or without management – we need to focus on NOT giving into the blame game and CYA activities. Don’t contribute, don’t pass the buck, don’t directly respond to direct CYA activities, don’t point fingers – FOCUS ON SOLVING THE PROBLEM – be part of the team and realize you either fail or succeed with the team.


  1. Sometimes management doesn't have to promote these activites to have them up and running all over the place. It's enough to have a couple of people in the team who think first how to cover their butts with some "protective" emails, records in different systems (e.g. bug tracker) etc.

    Then it's a role for management to cut these action out. Unfortunately most of the time managers, even when they're aware of the situation, do nothing.

  2. Another issue is that changing or removing processes or controls seems to be a lot harder than creating new ones (at least at my organization.) Perhaps we need the corporate equivalent of "sunset legislation."