Guidelines for Elevating and Lowering Priorities for Tasks and Projects
The implementation of a prioritization scheme is, for an organization, a simple step towards correcting systemic software-development-issues. Those problems demand an institution have rules about placing items into various preference categories. Yet, those guidelines do not tell a company how or when to promote an element to a higher level or demote it to a lower one. That business could use its instincts to elevate and drop one, but it might feel shaky about making such decisions, using only hunches. An organization can be confident it is making defensible choices, by using the rules described below.
Guidelines
An institution should apply, to an item’s promotion and demotion, the same restrictions it administers to an element’s entry.
A company can change the properties of listings to ones reflecting their reality, and it can reclassify them to mirror those new attributes, unless resources have already been assigned to them.
A business can re-categorize its eligible entrants, if it has, in its restricted groupings, one or more open spots.
If an organization can regroup them, it uses the previously laid out rules to determine the unit in which each one belongs.
Those items are processed by that institution, starting with the highest priority and moving downward.
An institution orders the elements in that group, it works through the listings in that collection, it moves any remaining entrants (all slots have been filled) to the next lowest level, and repeats this process at that tier, stopping at the lowest one.
A company automatically adds any item in the basement to that lot (no need for ordering or considering availability).
If a unit has restricted space, then a business orders the entrants that fill its slots, using the following heuristics.
Those with required dates are preferred to ones without one
Closer required dates are given priority over ones that are further away
A larger benefit of completion ranks higher than a smaller one does
Those with a more sizeable cost of delay come before those with a tinier one
A bigger scope is preferred over a less hefty one
Older items come before younger ones
A large benefit of completion is preferred over close dates, if the close-timetable item has a moderate or smaller price of delay
A sizeable deferment-bill is prioritized over a significant benefit, unless the required date of the deferred element is very far away
A big cost-of-delay and a hefty value are given a higher rank than an enormous scope, unless that breadth has a much closer timeline and the price of waiting is moderate or larger
An item with a significant domain is preferred over one with an old age
Curated Content and Authors
Petr Travkin discusses what DataOps is, how it is similar to DevOps, and how it differs.
Donald Farmer describes the principles of data architecture.
Dan Ports, Irene Zhang, and others talk about a scalable, replicated transactions system using the zero-coordination principle.
We wrote an article that describes how data and domain knowledge contribute to the development of a strategy.
We penned a column that argues that software development projects fail for the same reasons ones in other domains do.
Meera Rao is a consultant who has worked all over the world. She specialized in operations and security, and she is very involved in the Java community.
Endnotes
This issue does not cover all of the details an organization requires to implement a prioritization scheme. Those specifics are addressed in future versions and blog posts. If an institution wants them, subscribe to this newsletter and read this blog. If a company wants general information about strategy, read Strategy Construction Journal. If it needs content on systemic software-development-problems, peruse Software Construction Journal and follow ExperTech Insights on Twitter.
Check us out, if this content is appealing.