Red flag No. 3: Meetings have been scheduled without concern for team member availability
When a project or team leader arbitrarily schedules meetings that are in conflict with other important, already standing meetings, you know your project is doomed. Doing so ensures that vital team members will be absent, thereby undercutting the purpose and effectiveness of your meeting.
The solution is simple: Spend a little time before scheduling project meetings to learn the current calendars of important attendees. More important, find the handful of common availabilities, and pick a timeslot. Don't go too far in allowing participants to vote between multiple timeslots -- this can lead to bad feelings from those whose proposed timeslots get turned down. Instead, be authoritative and pick a time you know everyone can live with. You can adjust afterward if necessary. Also be sure to publicize your team's standing meeting times so that others don't accidentally schedule over it.
Also, hint to the wise: Schedule meetings before lunch, if possible. People are generally more productive and more likely to show up earlier in the day. Meetings after lunch often have to fight the slugglishness of full bellies and compete with the priorities and dramas earned during the first half of the day. Meetings held just after lunch or at the very end of the workday can be the least attended and least productive.
Red flag No. 4: Users have had little (to no) early involvement
Everyone taking even a basic IT class in college is taught to involve users early when launching any project or decision-making process. That's why it is so surprising to see large and complex projects almost entirely completed before users are brought in to provide their advice. I've seen many large, evolving projects completely derailed because users tell leaders that a particular process hasn't been done that way for a long time and the new process doesn't work either.
Make sure real users, or their advocates, are invited to the project from the get-go. You cannot have them in too early. The more involvement you have from users, the greater your chance of success. If your project covers multiple departments, make sure to have a user representative from each department. Also be sure the users that have been invited to participate are open to the project's objectives and feel they can voice their real opinion. Involving users earlier typically results in faster and better acceptance if problems develop or unpopular process changes are necessary.
Vendors are notorious for trying to keep the cost of a project down by underselling the hardware necessary for optimum results. Vendors often offer a "bare minimum" spec and the recommended hardware buy. Smart project leaders will go beyond even the recommended hardware specs; if something happens, at least the vendors and your customers won't be pointing their fingers at penny-wise, pound-foolish hardware purchase decisions. Also, make sure all purchased hardware and software is compatible and tested with each other. You don't want either side pointing fingers early if something goes wrong.
Sometimes the devil is in the details when it comes to purchasing technology. For instance, if a vendor says it has great experience with MySQL running on Linux, be careful about requiring MySQL to run on Windows. The vendor may say they can do it, but may not have much experience in doing so. If you deviate from what the vendor recommends, make sure you get the vendor's acceptance in writing. Plus, it never hurts to check with past customers who shared a similar configuration to learn the good and bad of how things went if they deviated, even slightly, from the recommended specs.