1. Pick the best projects and prioritize them.

Maintain a single list of committed and uncommitted projects. Not one list for this department and another list for another department. If the projects require resources outside of just the department that has initiated it, then it goes on the list. It gets prioritized just like all the rest. Every company will prioritize but in the end it’s the resources to do the work that become the critical factor.
• The list should be prioritized from 1 through however many you have.
• Be realistic with your team creation and assignments to each project.
• Don’t commit to projects unless the resources are there to deliver them.
• Be realistic about your expectations and the impact on other projects.

2. Creates teams and give them the autonomy to get things done.

Each Project should have a clear objective and success criteria. Don’t worry about the details; give the team the autonomy to figure it out. Check in regularly.
• Each Project should have an objective or mission statement.
• Each Project should have milestones i.e., mock ups, working prototype, etc.
• Each Project should have quantifiable success criteria.
• Each Project should have and end date, nothing lasts forever.

3. Don’t be afraid to stop, change direction, or slow down a project.

If you have milestones and success criteria you are better able to measure the progress of a project. Combine that with regular group check-in (think 5 minute status meetings) and you are better equipped to make decisions like ending projects that have failed to meet expectations or reallocate and slow down others.
• Your process should include regularly schedule, quick, check-ins.
• At anytime anyone in the team should be able to answer, are we on track or not.
• It’s an opportunity to identify issues early and help the team overcome challenges.

4. No what done looks like and stop when it’s done.

Many times a project has met its milestones and has achieved all or some of its success criteria and yet it still continues to roll on. Stop it. Recognize that you are done and you may not have achieved what you thought you would. It’s OK. It’s time for a Post-Mortem with your team, what went well, what could be done better next time, and what wasn’t completed and why. Use this information to start the process all over again, put it back in the prioritization list. Remember, you may have only achieved 70% of what you set out to achieve and maybe that was enough.
• Track to your milestones, don’t continue after you have hit your last one.
• Make Post-Mortems part of the process and evaluate the finished project.
• Evaluate and prioritize “finishing” against all your other projects.

The above can apply to many types of projects. Agile Programming and more traditional Waterfall processes generally enforce the above concepts. The differences lie in the details. Agile is strong on speed, flexibility, and autonomy and best fitted to small teams that are centrally located. It is commonly used for developing web products where iterations and feedback are quick. The waterfall is less real-time, but can handle very large and dispersed teams, it generally takes longer, communication is more formalized and there are generally more artifacts like Business Cases and Specifications.