Project Management/2011 Q4/Meetings/Background Info

Overview

The Webdev Web Productions Teams was formalized in 2011 to help drive technical projects from ideation to completion and ensure projects are as successful as possible. The Web Product Engineer (WPE) role was created as the technical project manager (TPM) on new Webdev projects. Almost all of these new projects required coordination of the engagement, webdev, QA, infrasec, and IT groups. The creation of the WebProd team has been a success, but it also exposed a number of issues that got worse as the company was rapidly growing. The number of projects initiated were increasing and it became impossible to launch everything requested given the resource constraints in all the groups required for any given project. Once WebProd realized that not everything was possible, they set out to develop a method to get priorities documented for all projects. This was a difficult task because each group requesting projects could prioritize their own projects, but they would not have visibility into other groups. The cross-group and Mozilla-wide visibility into everyone's projects leads to groups like IT, InfraSec, and QA to be over utilized and unable to commit to all of their requests.

Probing question: How would groups like IT, QA, or InfraSec know what projects are priorities given most of Mozilla needs their services to launch a product and none of the project requesters know everything that IT, QA, and InfraSec are being asked to do?

Project Prioritization

Chris More on the Web Productions team introduced a proposal in Q3 of 2011 to help prioritize projects that are based on how projects support top-level Mozilla goals, their level of difficulty, and the lifespan of the project. The method is a simple ROI tool that helps balance goals and quick wins while helping remove the emotions of prioritizing a group's own projects. This proposed process is something that should be collectively with all stakeholders and everything should agree on the results so the focus can be turned toward execution.

This proposed processed has not been collectively used, but only has been piloted within the WebProd team. The following is the steps on how to set up the prioritization spreadsheet and how to work through the process.

Set up

1. Decide on a number of specific broad values or goals that are most important to the organization. These can include legacy goals and new ones for the specific planning period. There should be roughly 3-5 of these goals that cover all of the major priorities of the organization. It is also important to make sure these goals are distinct, real, and clear to everyone. If the goals for the organization are already created, then this step is already done.
   1. Example values:
      1. "Maximize Firefox"
      2. "Establish Credible Apps and Identity Systems"
      3. "Advance Boot to Gecko"
      4. "Grow Mozilla"
2. As a group, give each one of the goals a value weight from 1% to 100% that defines the relative importance of each goal. For example, if "Advance Boot to Gecko" is the highest goal, then you could give it a weight of 40%. If "Grow Mozilla" is lower, give it a weight of 10%. The idea here is that the sum of all the assigned value weights must add up to exactly 100%. This is usually the hardest part of this exercise, because so many people feel passionate about some specific goals more then others. It helps to have representatives for each of the goals so when the final numbers are created, everyone has voiced their opinion, and everyone is on the same page. These value weights should be locked in for a period of time as adjustments to these numbers after moving forward will slow down the process.
3. Gather a list of all major projects from the entire organization. Some of the projects may be more internally focused or system improvements that may not fit well into this priority process. Generally, each group should allot a certain amount of bandwidth for internal projects and they should not interfere with projects important to the overall organization. The purpose of this proposed process is mainly for projects that support the growth and health of the organization.

How it works

1. A cross-functional team meets to discuss prioritization of major projects and the spreadsheet template is pre-filled with goals, value weights, and proposed projects from the set up steps above.
2. For each major project:
   1. The owner or group leader explains to the team the importance of the project and why it needs to be done for this specific planning cycle. This is almost like a sales pitch since it will take general consensus for the project to get prioritized right.
   2. After a particular project is discussed. The entire team decides on a rank for that projects per goal. The rank values are unbalanced odd numbers 1, 3, 5, and 9. Seven (7) is purposely skipped so that it is very obvious what is the ranked the highest. For example if "Project A" does not support "Maximize Firefox" well, it would get a low rank of 1. If "Project A" is to get the Mozilla's name in front of millions of new people, it may have a rank of 9 for "Grow Mozilla". Repeat this discussion for each of the goals of the organization and store these in each goal column.
   3. The group will then decide on the "Level of Effort" (LOE) for this specific project based on a variety of factors. This number should be between 1% and 100% where 1% the easiest project and 100% is a very large project. The numbers for the LOE do not have to be unique for all of the projects.
   4. If this project is a permanent and does not have a short lifespan, then assign a value of "1" to this project in lifespan column. If this project is will have a short life, assign a value of "0". This column will put weight on permanent solutions of equal importance.
3. Repeat the steps above for each major project.

Calculations

1. For each major project:
   1. Multiple the group's rank against the pre-defined value weight numbers for each goal defined. Add up all of the calculated factors for a given project which will give you a new column that defines the overall impact of this project. The number will be higher for projects that support more goals concurrently or highly support any one goal.
   2. Divide the total impact number from above by the LOE value and add this to the lifespan column's value.
   3. The resulting value from the previous calculations should be stored in an ROI column.
   4. Repeat these calculations for all the major projects.
   5. Transpose the project name and project ROI on to another sheet and sort by the ROI column.

Results

The resulting list should be a prioritization list based on how well project support organizational goals while balancing how difficult it would be to complete. What we have found out with this type of prioritization is that there are usually thee tiers in the ROI list.

1. Projects that have high impact and are easy.
2. Projects that have high impact but are more difficult to complete.
3. Project with lower impact.

A strategy could be to focus on the middle tier projects, but leave enough bandwidth for the top tear since they are usually quick wins. The bottom tier of projects usually can be reduced in scope or re-focused to make them a more likely candidate to be completed during a future planning cycle. Simple and high impact projects naturally filter up to the top, very expensive or low impact projects move down the list. If the cross-functional team did a good job on setting up the goals, value weights, and ranking the projects, you should have a list of priorities that everyone agrees on. Since this was done by committee and with a bit of simple math, it removes the emotions and discussions of why one project is ranked higher then others.

It is important to note that that projects don't have to be sequentially executed down the list, but it is a good exercise to go through to help flesh our what we are doing and why. The ROI is a good exercise to help focus the organization on what is most important, but it doesn't mean that reality has to follow it exactly. The process in of itself is most of the value will be gained.

A side benefit of this process is that if group's project is low on the list and they know how the above prioritization works, the next time a project is generated, the group may actively adjust the project ahead of time to ensure it gets prioritized. Overtime, projects will become more focused and have a higher impact, which will result in a more difficult time prioritization and many would argue it is a good problem to have.

Value Matrix Spreadsheet

The following is a sample of what the spreadsheet could look like and how it can be used. Please note that the values for the weights and the rank of the projects are completely arbitrary and were just generated for a proof-of-concept.