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.

The community has shown its strength and value. Twitter’s management was a very active and valuable participant in that community. Their actions have increased my trust in their decision making and I will be more tolerant of future decisions they may make when I don’t agree with them.

A security issue was discovered. The issues was brought to the attention of the OAuth folks. They quickly discussed the issue with key customers (Google, Twitter, Yahoo, Plaxo, others). They worked as community to come up with a short term solution. They short term solution was distributed to broader customer group. The solution was implemented. A major risk was adverted.

The official post is here http://blog.oauth.net/2009/04/22/acknowledgement-of-the-oauth-security-issue/.

I am more confident in the OAuth community and its ability to provide a very important solution to the API ecosystem. I also have to give a major amount of credit to the Twitter team for their actions, they took a lot of heat at a time when they are being scrutinized by everyone.

Negative press here http://www.techcrunch.com/2009/04/22/twitter-oauth-temporarily-disabled-leaves-developers-hanging/

Twitter’s post issue post on the problem and why they handled it the way they did http://blog.twitter.com/2009/04/whats-deal-with-oauth.html

The OAuth more the OpenID is critical to the growth and opportunities API’s provide online. The success of OAuth and its adoption are critical to data portability. Hopefully the events will increase the development communities confidence and accelerate its adoption.