Rescuing the Disaster Project

Here are some project management tips on how to rescue a sinking disaster software project. I am passing these along from my own experience in project management. In my current role, I am now a project manager (how did this happen???), but anyway, I learned a lot in 2006, and wanted to share this with you.

1) Be disciplined. Make sure to make all mtgs on time, post mtg minutes, and follow up promptly on action items. This may seem like "duh" but rarely do most team members have the discipline to follow up and maintain focus.

2) Reduce meetings. Set up weekly status mtgs (recommended once a week) with users.
Don't let users and management mtgs take up valuable work time. There's only so many hours in the day, and only a certain amount of time to actually get work done. Developers should not be in on user meetings, only unless they are absolutely needed. Management should be taken care of in other meetings, preferably once a week as well. Avoid "Panic" meetings... or "Status by 8:30 EVERYDAY mtgs." Everyone should bring their user questions, updates, etc., to this ONE townhall mtg. There does not need to be daily user mtgs. One person should run this user mtg, and take detailed notes to publish. These are handy when trying to research "what did we agree on last week?"

3) Try to understand what real complaints are coming from users. This is hard skill to find in others. A complaint from a user has to be researched to understand exactly what the user issue/requirement may be. Sometimes a blanket complaint does not reveal the "real issues." Asking 10 questions may help. I will list these in a future post.

4) Reduce team stress through Scope Management. Join a team mtg and find that "Everyone's stressed out." Why? Most likely, scope is not being managed. Make sure to do a health check on Scope. Are we following what we said or agreed to do for our users?

5) Make time for short term and long term planning. This is invaluable to think through all the "ifs" that may happen. Adopt the "Death Doom and Destruction" mentality, and prepare for the ultimate worst you can imagine, with Plan A, Plan B, and possible Plan C.

6) Don't let users dictate direction or requirements; however, help them find direction and requirements that are mutally agreeable for all. I am not suggesting that all members have to be happy with decisions or requirements, but at the very least, don't jump into "User said we need X feature. We must have this at all costs." Sometimes project direction or requirements are managed or massaged by the following 1) technical constraints 2) management direction 3) cost 4) scope. It's not always possible to deliver all that the user wants in the timeframes. Also, find out what users don't want. It's a clear picture of things your requirements SHOULD absolutely NOT do. Very interesting question to ask in mtgs.

7) Ask questions to understand more clearly the issues at hand. Ask questions... that's a big one for me. It gets annoying, but allows for people to vent or explain more fully what the issues are.

8) Define the following: Defects, missed requirements, change requests, and issues. This is important, because rarely do users understand defect vs. missed requirement.

9) WRITE DOWN the Requirements. The PM should be Requirements Hawk. Avoid having developer lunches where scope is changed, requirements updated, and then projects changed. If you get to attend any of these lunches, do so. You will learn a ton, and may find out pieces on info important to the project.

ANY requirement should be managed, documented, and written down. Don't accept "Well Dave agreed to it while he was taking a poop in the men's room." Feel the rage! Dave should take a poop and not try to change scope at the same time. You can still go to lunch with developers and developers can go to the restroom, but LUNCH and Poopy can be disasterous to THE Undisciplined Requirements Team (URT). Unmanaged requirements can move your project from Happy Plan A to PLAN C for Death Doom and Destruction.