in the end, even if weak signals are caught, documented and discussed, it doesn’t amount to anything if no action is changed. if a project is lagging, will top-level management actually change the release data (what happens if this release date is contractually set?)? will management actually bring in more resources to solve the problems that are occupying to much time/resources within the project?

i have been to status meetings and said that my project is doomed and hasn’t budged in weeks/months due to the fact that 3rd party software hasn’t been shipped/configured, due to the fact that i am putting out fires in other builds/software, or other reasons. i’ve seen others be as honest as i was. but nothing happened. management says to just keep working on what you have, knowing full well nothing will change by the next status update.

recognizing weak signals is easy. actually force management to do their job, and have them manage stuff. project managers should [often] go around the team lead and talk to developers directly. department directors should skip their project managers and go to the developers directly.

i would be interested to see you write an article about what to do once weak signals are captured and recognized.

in the end, even if weak signals are caught, documented and discussed, it doesn’t amount to anything if no action is changed. if a project is lagging, will top-level management actually change the release data (what happens if this release date is contractually set?)? will management actually bring in more resources to solve the problems that are occupying to much time/resources within the project?

i have been to status meetings and said that my project is doomed and hasn’t budged in weeks/months due to the fact that 3rd party software hasn’t been shipped/configured, due to the fact that i am putting out fires in other builds/software, or other reasons. i’ve seen others be as honest as i was. but nothing happened. management says to just keep working on what you have, knowing full well nothing will change by the next status update.

recognizing weak signals is easy. actually force management to do their job, and have them manage stuff. project managers should [often] go around the team lead and talk to developers directly. department directors should skip their project managers and go to the developers directly.

i would be interested to see you write an article about what to do once weak signals are captured and recognized.

1. Maturity: The IT industry is still not mature enough, compare it to the construction industry that is thousands of years old.
2. Quality of the Programmers: The quality of the programmers is definitely not even remotely comparable to the quality of programmers until the early 90s. Programmers right now work with the mentality of it works, and if it doesn’t, nobody’s gonna be hurt. Which leads me to my next point:
3. The IT Industry is still not taken seriously: Not by the top management that consider IT as an expense, not by the programmers (reason mentioned above), and not by the IT managers themselves who try their best to get the biggest budget and spend it all to get an even bigger budget next year. Even a mistake in the IT industry that costs millions of dollars is considered to be a bug (you can’t expect programmers to be perfect is what you hear in this case) and is forgivable (it’s like nursing babies), while a wrong calculation in construction with the same disastrous effects can be the subject of newspapers of weeks. An example was the Y2K bug (how many billions were spent because someone made a decision of using 2 digits). Accountability is low in IT.
4. IT Managers just don’t like Project Managers, and vice versa. Unless you’re the project manager and the IT manager at the same time, don’t expect to get anything done without some politics involved.

PS: I published an article on why IT projects fail offering a different perspective than mine.

1. Maturity: The IT industry is still not mature enough, compare it to the construction industry that is thousands of years old.
2. Quality of the Programmers: The quality of the programmers is definitely not even remotely comparable to the quality of programmers until the early 90s. Programmers right now work with the mentality of it works, and if it doesn’t, nobody’s gonna be hurt. Which leads me to my next point:
3. The IT Industry is still not taken seriously: Not by the top management that consider IT as an expense, not by the programmers (reason mentioned above), and not by the IT managers themselves who try their best to get the biggest budget and spend it all to get an even bigger budget next year. Even a mistake in the IT industry that costs millions of dollars is considered to be a bug (you can’t expect programmers to be perfect is what you hear in this case) and is forgivable (it’s like nursing babies), while a wrong calculation in construction with the same disastrous effects can be the subject of newspapers of weeks. An example was the Y2K bug (how many billions were spent because someone made a decision of using 2 digits). Accountability is low in IT.
4. IT Managers just don’t like Project Managers, and vice versa. Unless you’re the project manager and the IT manager at the same time, don’t expect to get anything done without some politics involved.

PS: I published an article on why IT projects fail offering a different perspective than mine.