7 minus 1 reasons why technology/engineering teams should work on projects

Here are 6 reasons that should be used to justify, prioritize and classify projects engineering teams work on. The 7th item is not a valid reason to be used.

1. Deliver products, features and services as driven by business priorities (#product)
2. Improve time to market (#speed)
3. Improve quality of experience (#quality)
4. Improve efficiencies and reduce costs (#cost)
5. Provide security and protect privacy (#security)
6. Continue to be able to survive, do business and operate (#survival)
7. Not a reason: Do not do it for vague “strategic” reasons that can’t be supported by one or more of the above six. (#invalid)

#Speed, #quality and #cost improvements are directly measurable. The results of the #product are measurable and its delivery is measurable as a binary. (E.g. was the feature delivered or not.) #Security fixes are measurable as binary. (E.g. Was the flaw fixed or not?) #Security upgrades can be compared to product upgrades.

Why a vague “strategic” reason is not a valid justification:

Organizations sometimes categorize projects as strategic and in alignment of the company’s mission, vision and value and use that as the primary reason to justify them. We do not support this as a valid reason, because it is too often misused as a way to work on pet projects or projects that someone in a position of power believes in but is unable to defend rationally.

Note that #survival is not the same as maintenance. Maintenance as a broad category is not listed here as a valid reason because maintenance is commonly misused as a bucket for holding on to projects that the organization should reconsider. Projects that can be well-defended as maintenance should qualify under the #survival category if it can be established that not doing them would prevent the organization from continuing to be able to do business. In other words, #survival is the small essential set of truly necessary maintenance projects. Using a stronger word like survival instead of maintenance can help avoid it being used too broadly.

We suggest tagging the projects and other initiatives your engineering teams are working on using these tags (#product #speed #quality #cost #security or #survival) as described above. In most cases, if more than one tag applies, tag it using the primary reason for doing the project. Only in exceptional cases should you tag the same project with multiple tags. By being strict about the reason, you will have greater clarity on why the project is being done.

This post is mirrored at LinkedIn and Medium.