Often organizations can find themselves under a mountain of requests and they can’t see the forest from the trees. It’s overwhelming and management may not know where to start – so they don’t, and what ends up happening is the organization becomes short sighted. Meaning that priorities are a reaction to today’s biggest issue, efforts are directionless, and most requests are escalated up the management change.

The source of the problem stems from lack of vision, and the corporate objectives that come as a result.

To get a grip on priorities you have to start with having a vision – even if it’s just a simple one line statement of where you’re aiming at; it’s the step to narrowing a blurry view into a focused one by getting everyone pointed in the same direction.

In essence all a vision is, is a statement of where you aim to be. Without one, there is no direction – you can move fast, but moving fast in a circle results in moving no where.

From that vision, define your corporate objectives or goals. These are specific, measurable, achievable, realistic, and time bound (aka S.M.A.R.T goals).

For example:

• Increase delivery time of widgets by 10% over the next 12 months.
• Decrease customer complaints by 5% over the next quarter.
• Decrease network outages to less than 5 minutes by 06/01/13.

As a corporation you only need 2 to 5 of these; each organization underneath you will have nested objectives that support your top level goals. And now that these have been defined, you have the various projects that support each of these objectives.

So go back to your endless laundry list of requests, priorities, enhancements, and projects and first determine which ones are supportive of the goals in your organization. If they do not support the goals, then you have to simply put them aside – even if they’re good ideas.

What’s left requires evaluating if projects have an executive sponsor. If a project is unsupported, you’re taking a huge risk by investing any effort in such a thing. There may be ROI, and it may support the goals, but without executive sponsorship the chances that the project will be successful is highly doubtful. This is because the project will then hinge it’s success purely on the ability for all the teams involved to function by consensus; and of course all serious projects come to serious forks in the road where differences in opinion will deadlock the project – an executive sponsor can make those tough decisions.

Another reason why executive sponsorship is needed is because if each team involved doesn’t have their portions of the project as deliverables as part of their performance plan, there’s no incentive for them to put in the effort. In fact, putting in any time, takes away from projects they are on the hook for.

Lastly, if an executive finds out you spent a large amount of money and it didn’t pay off, now you’re in deep water with no one to support you.

Ok, now you have a list of projects that are aligned to the goals of the corporation, and have the executive sponsor to back it. You still will have a list of projects that require more resources than you have, the next step is to evaluate the potential Return On Investment (ROI).

The ROI comes in the simple and tangible form of quantitative, and the difficult to measure qualitative. Projects that have more quantitative ROI are the ones you want to go after, as they’re easier to measure the actual results (increased revenues, cost savings, etc…). Versus the qualitative ROI which is almost impossible to measure, and even more difficult to actualize.

Of the quantitative ones you want to evaluate the actual potential ROI, how easy it is to actualize that ROI, and how you’re going to actualize the ROI (projects that don’t require anything to actualize are the best, e.g. switching to a lower cost vendor).

Here are some things to think about. If you reduce the time it takes to do something, what’s the return? From a financial and quantitative perspective the answer is none.

The return is when you see the impact to the bottom line – now saving time definitely has qualitative benefits, but the point here is as high as an ROI is, you need to assess how capable your management organization is at being able to actualize the ROI.

E.g. does it entail reducing overhead, reducing headcount, restructuring the organization, etc… Say that project can save $50M, but costs $100M – your ROI 50% in one year. Compare that to a project that costs $100, and saves you $100/yr, this has a 100% ROI.

So keep a relative perspective in mind as well; smaller projects may not have the huge total numbers of bigger projects, but their ROI is much easier to actualize and therefore lower risk.

The bottom line is you need to rank projects by ROI- giving extra points to projects with more quantitative than qualitative, giving extra points to the ROI ratio, and extra points to ease of ROI actualization.

You can only calculate ROI if you have the (I)nvestment portion, so you pick off the top x projects until all your resources are booked for whatever time frame you’re working with.

Using this formula will help you get a grip on priorities and get your organization executing on a path that will allow the organization to achieve its goals.

Our company HR/Finance Exec had heard about the Agile transformation we’re currently undergoing, and tomorrow we’re doing a company BBQ – so jokingly she asked:

Does agile mean we will release the food as it is cooked?

So I thought I’d take a lighthearted stab at explaining the Agile/Scrum approach if it were to be applied to a BBQ. To keep it digestible to someone who is unfamiliar with s/w development I kept is simple by omitting things like the various meetings (planning, retrospective, and scrum meetings), various roles, that the Sprints are equal length, that you probably wouldn’t map out in detail that many Sprints, etc…

The core theme was the prioritization aspect of it, and that the Product Owner has a goal or desired outcome with each Sprint.

Response:

The team that’s committing to the work agrees to what they’ll deliver in fixed time increments.

Product Vision: For everyone to gather together, socialize while eating BBQ’d burgers and hot dogs, and feel a heighted sense of unity.

Release 1: 06/14/11. Release goal: to eat hot dogs and burgers

Sprint 1: (the day prior) 5pm – 8pm

• Priority 1: Get meat
• Priority 2: Get buns
• Priority 3: Get salad
• Priority 4: Get snacks
• Priority 5: Get drinks

Sprint 2: 11:00am – 11:30am

• Priority 1: Burger Stuff –  Chop up tomatoes, lettuce, onions
• Priority 2: Marinade anything that needs marinating
• Priority 3: Prep salad

Sprint 3: 11:30am – 12:00pm

• Priority 1: Light BBQ
• Priority 2: Begin cooking meat
• Priority 3: Set up tables
• Priority 4: Deploy salad
• Priority 5: Deploy snacks
• Priority 6: Deploy drinks

Sprint 4: 12:00pm – 01:00pm

• Priority 1: Serve food
• Priority 2: Consume food

Sprint 5: 01:00pm – 01:30pm

• Priority 1: Clean up BBQ grill
• Priority 2: Dispose of trash
• Priority 3: Put everything away
• Priority 4: Lie down on floor from feeling too full

Each Sprint focuses on the next bucket of the most valuable priorities, in that if they’re not done, the lower priority items aren’t of much value (e.g. in sprint 1, there’s no point in getting drinks if there’s not going to be any meat because that’s a stated objective in the vision).

The person deciding the priorities is the Product Owner. After each Sprint, they’d be re-prioritizing what goes into the next Sprint based on the throughput data they gathered in the prior Sprint. Anything that didn’t get done, could go back into an unprioritized bucket, or moved into the next Sprint if that’s one of the next most valuable things.

Scenario: At the end of Sprint 2, prepping the salad priority didn’t complete for whatever reason.

Example reprioritization decision 1:

• The Product Owner can decide that we have to keep moving forward as cooked meat directly supports the product vision, not salad. Salad’s a lower nice-to-have priority. Burgers and Hotdogs deliver maximum value so we can’t compromise that user experience.

Example reprioritization decision 2:

• The Product Owner could decide that you can’t have a BBQ without a salad. So going into Sprint 3, the Product Owner may re-prioritize by moving the prepping of the salad into there, and pulling out snacks and drinks (salad = healthy, healthy customers are better for profitability).

The Product Owner is empowered with enough authority to make these priority decisions, however they’d be accountable to the business for the results.

So after the release is complete, the Product Owner would measure if they achieved the heightened sense of unity and use that to strategize on Release #2 (the next company BBQ).