Project Management/2012 Q1: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "== Background == In Q4 of 2011 the project management initiative team was kicked off to evaluate how Mozilla internally plans and prioritizes proj...")
 
Line 25: Line 25:


== Next Steps ==
== Next Steps ==
# Gather requirements
# Evaluate tools (existing and new)
# Narrow tool choices
# Select tool

Revision as of 23:56, 20 December 2011

Background

In Q4 of 2011 the project management initiative team was kicked off to evaluate how Mozilla internally plans and prioritizes projects to ensure the highest possible success rates. It was determined that a majority of our projects require multiple teams to complete those projects and the company was growing at such a rapid rate that transparency and clear priorities were required to be able to achieve our goals. A short-term solution was put in place, but it was in no way a system that could be sustainable. Project and program managers in the company already use a number of non-connected spreadsheets and wiki pages to aggregate their projects and adding another spreadsheet to the mix was not going to magically resolve the issue.

Long-Term Proposal Overview

The project management initiative team has discussed that the long-term solution will have to be a mix of tools, process, and a slight cultural shift. Everyone agrees that the intention is not add additional work to everyone's already-full plate, but instead augment their current tool set with something that includes the following features:

  • Easy-to-use
  • Accessible
  • Web-based
  • Cross platform and mobile-friendly
  • Resource management
  • Timeline management
  • Project prioritization
  • Project submission process
  • Links and other project meta data
  • Private and public views
  • Data visualization and dashboard tools
  • Scrum/Agile abilities
  • Integrates with existing tools (Bugzilla, Github, SVN, wikis)
  • Provides instant benefit for everyone involved!

In summary, the future tool must be easy-to-use and provide the minimal amount of features to provide instance benefit to the entire organization.

Next Steps

  1. Gather requirements
  2. Evaluate tools (existing and new)
  3. Narrow tool choices
  4. Select tool