Mass Anxiety in the I.T. Department
I'm not a qualified psychologist by any definition, but I played a doctor once during a skit at DaVita. That should give me just enough credibility to declare these disorders as real and legitimate causes for concern in the I.T. workplace. I've seen these ailments at a few places..
Systems Hoarding
Cause: The firm has grown in a way which prevented qualified geeks (those who actually wrote the code or deployed the technology) from reaching any position of authority.
Symptoms: Without any architectural oversight, "solutions" are added to the core system without technical evaluation - and integration becomes an afterthought. A common reaction to the firm's problem du jour is to just buy another "solution", without regard to the capacity already present in the current system.
Without any fount of technical inventory at the executive table, there's nobody who can utter the most important words in I.T. ("We already have everything needed to do that."), at the most crucial point: a project's initial suggestion.
Prognosis: Ultimately, the firm will realize an obvious abundance of duplicitous & overlapping "solutions". Without first-hand knowledge of how the systems relate to each other, those who wield the power will be unable to identify the most effective cuts and will fear shutting anything down. The firm will often cut I.T. payroll instead, releasing their technical knowledge to the winds and making the problem worse.
Beta Blocking
Cause: Managers or leaders fear that - by allowing direct communication between those who code the application and those who will actually use it - they will loose control of the project or fail to provide value.
Symptoms: The subject concentrates on complete and polished release candidates of their design, instead of allowing end users and developers to share draft ideas (alphas) and prototype designs (betas) with each other.
They practice shuttle development, in which they meet with the client (who may also be another beta blocker on their end), translate requirements to the developers, and then translate developer questions back to the client.
Prognosis: The product will suffer delays after the UAT (User Acceptance Testing) phase; as those who actually need to use the application on a day-to-day basis revolt. The interface or database design does not match the user's preferences, "literal" business process or workflow. In other words: "This isn't the way we do that!" and/or "why didn't anyone ask us?"
Application Publication Anxiety (APA)
Cause: The client or developer has a fear of web rejection by their peers - or the usership at large - and will manifest additional reasons for delay, sometimes even after the original design has been fully completed and tested.
Symptoms: Continually tweaking every feature or program element to an undefinable perfection. Delaying the application's release for installation of yet another newly-conceived enhancement. Obsessing on the most efficient way segments of code can be written to protect against unrealized threats of security or scalability. Developers, future clients & even loved ones become frustrated with the victim's continual tweaking - but never actually publishing - the project. In some cases, the victim will abandon the project entirely rather than release it, switch attention to another new project, and repeat the development process over again.
Prognosis: Rather than locking down feature sets for the first and subsequent releases, the application's desired state will always exceed it's realized state. It may never be released for real use - without adequate & timely pressure from external forces (financial, competitive, etc).
This was a public service, to help you spot the signs of dysfunction and make corrections as soon as possible. In the immortal words of another qualified medical professional, Dr. Barry Rumack: "Good luck, we're all counting on you".