Reports Of Accomplishment

These are the usually Sugar-Coated, vague and non-commital, say what the manager wants to hear reports.

Usually instituted by a manager who likes to do his job at the keyboard and desk. He is most comfortable with Emails and Voice Mail, because they free him from making immediate, personally accountable decisions. He can not be expected to know what is going on in the here and now, for the time lag introduced by Email, Voice Mail and ReportsOfAccomplishment insulate him from any knowledge of the present.

Some people like this kind of manager, because it allows them to do whatever they want, as long as the report says what the manager wants to hear.

Not to be confused with ReportsOfCompletion?, the ReportsOfAccomplishment is an interim report which does not have to answer the question "Does it Work". It uses such vague terms as "meeting schedule" and "50% complete while utilizing only 45% of the scheduled man-hours".

Reports of accomplishment are accountability documents. Since a manager is not intended to be an active participant in producing working code, as in the case of one managing programmers, the manager must rely on others to not only produce that code, but to give honest, accurate reports. If the report contains an estimate, it should be one based on what one has done toward the intended end represented by facts, not upon "what the reporter thinks the recipient wants to hear". Unrealistic or dishonest reports are a BadThing. Reports should not be skewed because a manager may not want to hear reports with "bad news". It is foolishness to believe that a manager prefers a report which brings "good news" which is misrepresentative of the real situation. If there is to be criticism of "sugar-coated, vague and non-commital, reports", the criticism should not neglect to involve the reporter as one of the contributors to a dysfunctional process. While it is true that those who honestly portray failings and shortfalls are rarely rewarded for their honesty, it is part of the fabric of success-orientation to expect honesty rather than deceit as agents of achievement. In success-oriented programming, ReportsOfAccomplishment are replaced by Celebrations of Success, when completed artifacts are released in working order. This is the highest form of accomplishment; successful completion and delivery, not of a report, but of an intended result. Reports are still needed in the midst of the process, but these should be recognized as documents spelling out progress, not accomplishment. The more detailed and artifact-specific the facts are, the more useful they are to the manager in recommending and providing appropriate resources and manpower.

Please remember that there are multiple levels of management and not all are going to be able to sit with the development team on a day by day basis. Reports of accomplishment give some insight into what is happening on the project to these upper levels. Giving "sugar-coated, vague and non-commital, reports" will give the team some direct access to upper management when things go bad, but this is not a good thing. Status reporting is not a sign of a dysfunctional environment and early and accurate reporting of difficulties is often a key to project success.