PMO Prioritization – Project Descriptions should be Effective, Relevant … and Short!

Next year, our PMO will be taking a run at improving “transparency” for project prioritization – a clearer process for getting projects approved and scheduled. Here’s a key building block – what is the most effective way to describe a project? There is a certain amount of art and style in getting this right; most PMOs feature some sort of central database listing candidate projects; typically, the various screens, views, reports, etc. are designed for “short and sweet” descriptions.

Note that we’re talking about a super-terse description for a long list of projects; if you need to write a richer Project Proposal document, check this out.

Think about how the typical project prioritization conversation happens; even when we are only talking about one functional area of the business (say, Supply Chain Planning, Marketing, or Finance), there will probably be a list of 10 to 20 projects that need to be compared, balanced, sorted – prioritized. It’s a tall order to expect folks to evaluate 20 long descriptions in a reasonable (i.e. short) amount of time; these conversations get easier when each of the projects is given a terse, yet effective, synopsis – just enough for the reader to line up the projects in priority order.

In the typical PMO database, there are four important fields to consider:

Project Name: keep this short and to the point, you don’t need a lot of detail – that’s what the next three fields are for! A nice guideline is to keep it to less than 50 characters (less than 30 would be better). Remember, this will be used as a title for presentations, documents, shared folders, etc.

Good Form: Weekly Regional Demand Forecast

Needs Improvement: Improved Cut/Fill Functionality. RF based vs. having the LTO going to the Lead Station.

Too much detail – can’t see a document file name like this!)

Important Guidelines:

1. No fluff words like “enhancements”, “phase 2”, “updates”, “improvements”. If we are talking about one specific area of functionality, name it. If we’re talking about a batch of requests / improvements / changes all grouped together, identify what area of the system or business process is primarily affected. Over the months there can and will be many opportunities for “enhancements” – we’ll need to differentiate.
2. No sentences – this will be the Title for documents, presentations etc. during a life of this project. Use proper capitalization, no period at the end
3. Use the Project Name and only the Project Name as the title for documents, presentations etc.

Description: (”What“) Enter a short description of what this project will do – implement a system, add a report, change some screens, decommission some servers, whatever. We don’t need a book here; this is just the 10-second explanation of what the project is about. Nothing too technical either – more of a business explanation. Think of this as the 30-second elevator speech that you would use to describe this project to someone.

Good Form: Implement new process and systems changes to support a more detailed demand forecast for select products, going down to the regional and weekly level

Remember if you feel the urge to write tons of text to explain this project – well, that’s good, but it doesn’t go here! That’s what the Project Proposal is for.

Objective: (”How“) This is where you get a bit more detailed; what specific tasks / deliverables will this project put in place? Again, not a book; try a few bullet items that are clear and concise

Good Form: 1) Design and document new demand forecast process 2) Upgrade supply chain planning software to latest version 3) Convert current data and feeds for first (test) customer 4) Conduct user training 5) Develop repeatable project spec for conversion of subsequent customers (separate projects)

Benefit: (”Why“) What is the expected business benefit to be realized with this project? This does not have to be a hard-dollar, fully justified cost/benefit analysis; just a simple yet relevant, meaningful statement of why we need to do this – and not in technical terms!

Good Form: Regional forecasts expected to drive down transfer costs. Weekly forecasts expected to better match production to demand. Repeatable process will be copied to other customers, and deliver consistent demand forecasts for all products

Remember, a decent PMO will feature a variety of tools that pull these names and descriptions from the database (MS Excel, MS Project, etc.). As the prioritization process improves, we need decent descriptions such that we can easily comprehend a large number of projects in a short amount of time.

Again, there is some art to this, but it gets easier with practice. If you’re not sure the project description, objective, and benefit is not clear – test it on someone who does not have detailed understanding of what this is about. They should be able to pick up the general meaning without asking too many detailed questions.