A High-Level Objective, A Goal, A Requirement, A Priority – Where does the Line Get Drawn?
I recently received an e-mail from a client asking what sounded at first like a very simple question
I’m trying to determine what is important or a priority. I am reading a SOW and having difficulty breaking it down into requirements that I would want to include in the Charter. If you could provide any guidance it would be greatly appreciated.
I went through some of the references I have on my shelf (which are legion), and came up empty-handed. So I turned to my own philosophy on such issues and realized that one of my primary tenets of faith in project management holds true here—If no-one has come up with the definition, and you do it first, you win!
That’s actually true in most management practices. The first one to define the lexicon in a culture, an organization, or a project wins. I preface this article with that caveat, as it’s important to be honest about where my definitions came from. They’re a first take on the definition of terms. Your definitions will vary. But if you document your definitions and circulate them, you win!
High-Level Objective (aka, Charter Objective)
Charter objectives are those objectives that should be captured in the project charter and should serve as the guideposts for all efforts in a project. There’s a positive and a negative question to determine if something truly meets the criteria to serve as an objective worthy of placement in the project charter.
Positive: Is this the reason for doing the project and drives directly to why we’re pursuing a particular piece of work?
Note that we don’t do a document to show off a 12-point Calibri font. While that may be a requirement, it’s not the objective.
Negative: If we don’t do this particular aspect of the project, does it render the effort useless?
Again, while the font may be something that we expect of the project, it’s not such a severe issue that it would mean the project could not be used for its intended purpose.
The Project Management Institute used to break out the scope statement into two scope statements. One was preliminary, and allowed for an early discussion of the project’s roles and objectives. This was (and to my mind, still is) the objective statement that belongs in the project charter. This high-level statement doesn’t incorporate a lot of detail, but still allows for an intelligent discussion at any given point in the project. Any time there’s a question as to whether something is an appropriate element of work, it’s easy enough to point to the high-level objective and say “Does it serve this goal?” If yes, it has merit to be considered. If no, it is not appropriate work.
Conversely, anything that stands in the way of these high-level objectives is a serious problem. The elements within this statement are our priorities. Nothing must be allowed to stand in their way.
Requirements and Lesser Priorities
Requirements are all about execution. Everyone knows that a project that never gets executed is not a project at all. It isn’t happening. So while requirements are crucial to project success, they are not the guides. These are not the beacon through the fog. They are the work to be conducted. Guideposts guide. Requirements enable.
The word “require” is actually rooted in “re” (to do repeatedly) and “quaerere” (to ask or seek). Requirements are those things we repeatedly seek! Note that while we consistently equate them with needs, they are actually those things that we want over and over and over again. We need the elements as defined in the greater preliminary scope statement. We want requirements. We want them badly enough that we’ll keep asking for them, and if they’re not included, the client won’t accept our deliverables, but they don’t guide our success. They enable it. Requirements are the means to end. The objectives or charter objectives are the end.
This might seem like a purely academic distinction. It’s not. By being able to tell the difference, we can winnow down the charter objective to a clearer, more specific, more measurable goal, without the burden of how the work will ultimately get done. Most of that more detailed information, if done properly, will ultimately be captured in the requirements documentation—with each requirement pointing back to the loftier project objective.
