10 signs that your project is in trouble... and 10 signs it's in good health

(I am on vacation, so I am publishing posts which are more philosophical than technical)

Your project is presumably on a path to failure when:

1) in meetings, team leads keep saying "we are making progress" without giving much detail, and don't mention difficulties and problems to be solved

2) the words "agile", "soa", "abstraction", "cloud" - or name your favorite methodology or buzzword - are used more often than "analysis", "design", "code review", "automation", "test"

3) everybody around is trying to impose his view about a technology/product even without ever having used it

4) the architects don't have a clue about what the developers are doing, anyway they don't have time for irrelevant details

5) the developers are afraid to talk to the architects because last time they did it they had to scrap 2 weeks of work and do it all over again

6) you come to know that your code has been (or not been, or the wrong version has been) delivered only because a tester insults you in the corridor, and not because your automated tests have been run and failed

7) when you say "sequence diagram" (or state, or class, or deployment, or component...), people look at you with a puzzled or horrified expression

8) the number of emails in your inbox, apart from the invitation to social events and meetings, equals the number of technical emails you have sent

9) it takes a day to restart a server or DB because nobody knows who is in charge

10) you must buy hardware with your own money in order to be able to work

11) after a major delivery failure, all what your manager has to say is "the sun keeps shining" and "it's ok to fail" rather than "let's analyze what went wrong"

12) for months in a row, nobody can troubleshoot a system until a specific person arrives at office

13) despite a huge delay in the project, at 3 pm on Friday the office is empty

14) somebody is seriously trying to make management believe that Methodology X or Product Y  is the solution to all problems; and management listens to him

15) the main objective of a meeting is to schedule another meeting

16) components are defined as "delivered" while running on a developer box

17) environments point to each other and nobody seems to care as long as things seem to work

18) tests are done manually, with a single happy path


Your project is presumably healthy if:

1) architects are seen often discussing with developers

2) business analysts and audit persons walking on the development floor are treated with great respect and can freely ask questions to the developers

3) developers are equipped with highly performing machines

4) new environments can be created in minutes, with automation scripts

5) configuration is strictly under control, in a sort of Configuration Management DB accessible to everyone, and changes are strictly controlled

6) the walls are not covered with slogans but with diagrams

7) your manager asks you regularly to show him the progress of your work

8) if you are found bullshitting or finger-pointing other developers, people frown at you; people compliment you if you find a solution, and are eagerly interested to know about it

9) everything is automated, no manual operation - apart the click of a button - is required to make a delivery from your CMS running all the conceivable tests

10) if any part of any system goes down, some sort of alert is sent within minutes

11) emails are sent in due time for any event of public interest, such as a new release or a code freeze or a new environment or a configuration change

12) "I'll do it" is the motto

13) People are not afraid to say "I don't know", and other people are happy to teach them

14) A meeting is preceded with an email containing a list of topics to be discussed; it ends only when all the topics have been addressed and all decisions have been made; someone takes minutes and distributes them to all concerned people, and the material produced in the meeting is archived and published

15) the delivery and testing process is defined and in place, and developers stick to a rigorous TDD approach



(ok the number 10 has not been respected... pardon me for being Agile)