Prioritization Models

The room was on the second floor of a three story building near the Greenbelt in Boise.  On the outside of the was a small tag with the word Naboo in a sans-serif font.  Obviously a Star Wars fan had been involved in the naming convention.  Chris sat directly across the table, Scott across and to my right.  In front of Chris was a copy of my resume and a set of questions.  I couldn’t exactly see if he was following the script but at one point he asked me how I prioritize.

It’s a good question.  This wasn’t my answer.  But for anyone who ever does need an answer, here’s a good review.

According to Greg MeKeown the word priority was singular for the first 500 years of its existence.  Of course those are the same 500 years where English had taken a back seat to French and we ended up with all the wonderful French words for food (beef, poultry, veal, etc.).  So we could chide Greg for being disingenuous–it’s hard to innovate in a format that is being oppressed–but instead let’s give his quote credence and believe that the word priority should only mean one first thing.  How do we prioritize?

When I was first on the other side of the interview table I was handed a script of questions that included the exact question, “how do you prioritize?”  Sometimes I got thoughtful responses, and other times I got people who basically told me they knew how to read a calendar.  The “I look at the calendar and see what’s next” is not an effective method as it tends to involve the least amount of thought.  The calendar should be an input, but not the single source of decision-making.

When I’ve been asked to teach about prioritization techniques I’ve generally taught that there are seven variations I find useful.  This list is not all-inclusive, but does cover different perspectives to accommodate different leadership styles.  Prioritization systems also have to be easy to articulate.  I’ve found that they need to be communicated to encourage buy-in from stakeholders.  It’s not uncommon for someone to hear me say that “we prioritized based upon XXX technique due to [specific factors that justify the technique].”

Here are the seven models (in no particular order) with brief explanations:

  • Proximity to mission (requires a mission statement)
  • Prioritize for momentum (Dave Ramsey’s technique)
    • This method involves understanding team dynamics and motivation.  It should be used when the team needs a win.  Pick something they can be successful at quickly and build on that success going forward.  It’s nicknamed the Dave Ramsey Technique because of Ramsey’s advocation for it in debt reduction.
  • Pareto Prioritizing based upon value
  • Prioritize based upon expert judgement
    • When information is scarce and a judgement has to be made quickly we often find ourselves relying upon what we may summarize as instinct.  It turns out, it’s not instinct, but the ability of our brains to leverage what we know in complex situations.  Sometimes it’s the only explanation that we can give and it’s the best one depending on the situation.
  • Prioritize based upon proximity towards goal
    • This method references Eliyahu Goldratt’s work on the Theory of Constraints.  In his book, The Goal, Goldratt demonstrates the how identifying and focusing the organization’s efforts at its bottlenecks leads to the most efficient outcome.  The goal, of course, is to make money.
  • Prioritize based upon Maslow’s Hierarchy of Needs
    • This technique is team centric and has limited application outside of military settings where leadership is responsible for the total workforce.  In situation where the total workforce is the leader’s responsibility using Maslow’s Hierarchy is perfectly appropriate in making decisions.
  • Prioritize based upon disruptions (variance) from an ideal flow
    • When an ideal flow system is defined and deviations are identified the instances in the system with the largest deviation determine the priority for improvement.  This method requires quantifiable information and is generally used with those trained in six sigma techniques.

While this list is not designed to be all inclusive it does present a list of easily articulable techniques that fit in most situations.

A word of caution.  If you’re going to apply a technique that’s unpopular always give a reassessment date.  “Team, we had to prioritize for this development cycle based upon [proximity to the goal] and we’ll reassess this method in 30 days.”  Prioritization is a key part of stakeholder management.  Projects will move forward as long as the people are committed, and often times how the tasks are chosen that’s just as important as what tasks are chosen.

Ignoring Stakeholders While Upgrading

When the United States Army isn’t deployed fighting a war, they’re supposed to be training for it.  As a part of the Executive Branch they are required by law to account for its use of authorized funding.  As the fiscal times reported in March of 2015 the DoD can’t account for $8,500,000,000,000.  One of the areas where the Army has tried to improve its accountability is in its training management system.  In 2014 the Digital Training Management System (DTMS) received a major upgrade that turned it into a thoroughly embarrassing debacle within the Army.

Once released the new website lasted for just a few hours before software issues caused the site to go down for maintenance for several weeks.  Although released in October, problems were so bad that the Army withheld its press release touting the new features until January 12th of 2015.  Attention to detail was so low that when it did publish the article the press release stated it was published in 2014 because Mike Casey (the author) didn’t remember to change the date to 2015.  This lack of attention to detail during the project development lifecycle doesn’t begin or end with a delayed and miss dated press release.

While the aforementioned press release mentions how the program serves commanders in conducting training management it fails to identify which level of commander.  My personal opinion is that it serves commanders at BDE level and higher who would have a difficult time gathering training information on their more than 1000+ formations without the use of an automated tool such as DTMS.  

The command level that is the least served by the software is at the company level, the lowest level of command, where all of the required data entry occurs.  A company of approximately 100 individuals requires two full time personnel to manage the automated system.  Lower level stakeholders seem to have been neglected throughout the process.  

Other errors that affect lower level stakeholders include:

  • A non-intuitive interface requiring a full 40 hours of training before use
  • No back-button after saving an event requiring full navigation through the home screen to edit the next event.
  • Built on Microsoft Silverlight, a technology that forces the site to be run on older versions of Internet Explorer and one that has been abandoned by its creator, Microsoft
  • Limited resources to address issues found through feedback (some recommendations are years old with no resolution)
  • Unable to upload documents en masse (feature is listed as an option and fails upon execution)
  • Unable to make adjustments to the personnel assigned to the unit causing miscalculations of averages and aggregate data by including individuals no longer with the unit or misassigned
  • Exports to poorly designed formats
  • Exports UserID from database in Excel but hides the column with the UserID
  • Website susceptible to URL code injection
  • Higher echelons have more control over the data but are least familiar with it making it easy for them to misalign personnel and accidently delete crucial records with no easy method of restoration (no undo button) causing repeated efforts at lower levels to repair the mistake.

    A bad system is a good thing to learn from.  These issues are indicators of a project management team that failed to assess the project’s complexity and overlooked key stakeholders.  My role in the project was at the lowest command level where we were told to utilize the new system only to watch it go down for several weeks due to implementation issues.  Since then we’ve made efforts to assert ourselves as stakeholders using the appropriate feedback mechanisms only to have our perspective marginalized in the process.

    It’s a bit easier to see how the DoD can’t account for $8,500,000,000,000 when they fail to implement good project management practices while updating their training management system.