Ground Hog Day Project

AntiPattern Name: GroundHogDayProject

Type: Organizational

Problem: Periodically, meetings are held which seem to discuss the same things over and over and over again. At the end of said meetings, decisions are made that 'something must be done'. After a week/month the meeting is repeated - the project goes no further forward.

Context:

• Multiple projects having to work together to produce an uber framework
• Disparate teams working on a project - possibly distributed geographically
• Architects/politics that don't appreciate the technical problems inherent in the project but responsible for decisions
• Poor leadership
• Poor understanding of requirements but no acknowledgement that requirements need to be defined or a different process needs to be followed

Forces:

• Deadlines in other projects (see context)
• ArchitectsDontCode but have to make decisions

Supposed Solution:

• Have a meeting with most of the stake holders.
• Be careful not to involve all of them because you might end up with a workable solution.
• Ensure no minutes are taken in the meeting and definitely don't produce a task list.
• Don't plan to follow up anything that may have slipped through and been decided
• Ignore forces/context in related projects; they are not important to this project.

Resulting Context:

• Nothing is done.
• After a while people will realize that they need to meet again to work out what to do.
• Anger and frustration
• CultureOfBlame

Design Rationale: We've got to get something done.

Related AntiPatterns: AnalysisParalysis, ArchitectsDontCode, DesignByCommittee, YetAnotherMeetingWillSolveIt, LeadingRequest

Applicable Positive Patterns:

AntiPatternCategory: Management - because ultimately a failure to produce anything is a management failure.

-- ChanningWalton

There are three candidate applicable positive patterns I can think of, notional - these are ill formed as yet.

Manage to output - If you're observing the output - what you're getting - the non-progress of the GroundHogDayProject is obvious. You're getting more and more time spent in discussion. You're not getting direction, decisions, artifacts, etc. This is a management pattern. The description above "... discuss the same things over and over again ..." identifies an output - discussion. Because the observers lack positional authority, the meeting doesn't change.

Advance the State of Computation - Any activity in a project should Advance the State of the Computation just as with any line in a program. So for each project activity including meetings you should be able to identify a before state, an after state, and why the difference between the two represents progress.

Very true - I think that looking at the differential in state before and after the meeting may be illuminating. I will probably find that there is no difference. Furthermore, whilst there may be a difference, if there is a lack of follow up or commitment on the part of those that have agreed to do something, then the project may slide back again to the pre-meeting state after a few days or weeks. -- ChanningWalton

Note that a GroundHogDayProject may, in fact, produce results with each meeting if the point of the project is to spend time and money without changing anything. This happens sometimes. This is a task / activity kind of thing.

Information Radiators - Put information on the wall, somewhere obvious and accessible. This can be output information, state of the computation information, or a mere meeting record, inventorying meetings, attendees, and time spent. This is a social engineering kind of thing, producing effects through people's innate reactions to the information.

Information Radiators are good so long as there is sufficient buy in from management to actively use them - but that's a completely different anti pattern, not sure which yet. -- ChanningWalton

-- JamesBullock

---

CategoryAntiPattern CategoryProject