Project Management

Project Management Central

Please login or join to subscribe to this thread
When a requirement should become it's own Project
Department Heads at my company were asked to develop OKRs for our strategic goals. The primary outputs from this ask should have been an OKR roadmap with a rough timeline of the related projects over the next year or 2, each project having a high-level charter.
Some did well with the assignment and produced an OKR roadmap with about 4-6 projects over the next 2 years.

Some folks struggled with the concept of a project vs. things I would consider milestones within a project. As a result, their OKR roadmaps listed 10-12 'projects' for things like "Submit application" or "launch marketing campaign" as 'projects' for their OKR.
Now my job is to go in and explain the difference between a true project and these 'milestones' they have listed out.

Any helpful tips on how to explain these differences?

Sort By:
Kelsey, well it is in the eye of he beholder.

For some those are big fish, for others small fish.
When Kennedy asked to take a man on the moon, it was a milestone for him, for NASA it was a huge program.

So may be the assignment was not clear enough. I could see 'launch marketing campaign' as a perfect project on its own.
And if you only have 4-6 initiatives for 2 years, they may be rather programs than projects (my gut feeling).

In general, I prefer small projects. If the team or sponsor or project manager or customer changes, I think a new project should be defined and chartered.

You might explain the function of each in your particular environment. How are they used in practice? After all, OKRs are one way to break down elements of a project, that others call different things.

A project is an over-arching effort that includes the goals, requirements, objectives, schedule, and Key Performance Indicators for some desired end result, and those elements of a project serve different purposes.

While a milestone is a date used to plan and assess schedule performance, there may be some element of it that justifies spinning off its own sub-project. That would happen if it can be managed mostly independently with limited interface points to the larger effort. A sub-team is assembled, plans the work, completes the work, and is then disbanded. To that sub-team, it is functionally their own project. The same goes for requirements and objectives if the work is unique enough that developing that part of the overall solution may be managed mostly independently as well.

Key results are lower tier, measurable elements within a larger project. They may be spun off into their own projects supporting a milestone or objective, or they may be the progression of sub-tier goals over the project such as performance goals that converge on a target over time.

In some ways, what matters is that you all speak the same language, since OKRs are one way out of many. In a classic systems engineering framework, each are their own classification of information types with well defined definitions. If others use the terms differently (like equating objectives to requirements) then you need to establish what you mean in your own situation so you can all use them the same way.
Kelsey -

Thomas & Keith have hit the main points I'd have suggested, so the only thing I'd add is to ensure objective handling of projects many organizations will define quantitative thresholds whereby a piece of work needs to be authorized, planned and executed as a project vs. everything else.

This helps to reduce the "what's a project for me is a task for you" situation...

Then, it comes down to an unbiased coarse grain sizing or estimation of the piece of work to determine which bucket it falls in...

Kiron added a good point to Keith and Thomas's thoughts.
I will assume that OKR means "Objectives and Key Results". Nothing new is I write that OKRs comprise an objective (a significant, concrete, clearly defined goal) and 3-5 key results (measurable success criteria used to track the achievement of that goal). This create needs that must be translated into requirements. To use a new buzzword, in some literature related to Agile you will find it as epics and features. Those requirements will help to create the needed solution to achieve the results. Solution is equal to "the thing" to be create (product, service or result) plus "the way" to create it (call it project). To put all these in the framework of the PMI you will find about this type of things in documentation related to business analysis.
Maybe, just maybe, the request should have been clearly explained with the assignment rather than 'explain the difference after the fact'. To me that represents a lot of wasted time and effort.

Acronyms mean different things to different people - I had to look up OKR and even then I 'm not sure what was called for. Sergio identified it as "Objectives and Key Results" and with that the assignment still remains unclear and subject to interpretation.

One option now is to sit with the players (folks) and discuss the corporate needs so they understand the objective rather than relying on buzz words.

"We are looking for a road map with significant anticipated projects over the next 2 years so that the company can project cash flow and resource requirements (or whatever the true objective is) and get shareholder buy in."

Please login or join to reply

Content ID:

"Experience is a comb which nature gives to men when they are bald."

- Chinese Proverb