Any project with an estimated timeline longer than two weeks should have a solid, detailed project plan. If you are presented with a project that does not, create your own. Besides forcing everyone to consider all the tasks and tactics, doing so will force them to come up with realistic timetables. A detailed project plan is far better than your "best guess" or a gut feeling.
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.
Sign up for MIS Asia eNewsletters.