Not So SMART Objectives

In a VUCA world, objectives must be SMART:

S – Subjective

M – Machiavellian

A – Adjustable

R – Reactionary

T - Tentative

The Real FR vs NFR Requirements

Any professional working with requirements is familiar with the abbreviations FR (Functional Requirements) and NFR (Non-Functional Requirements). This categorisation attempts to distinguish one type of requirement from the other. It's an unfortunate exercise to separate them so distinctly because FRs often need to be described with their accompanying NFRs, while NFRs are often met by implementing a set of FRs.

However, we can reuse the FR vs NFR distinction in some other ways. Proposed below is a list of the more important ones:

Fictional vs Non-Fictional Requirements – Fictional requirements are not really requirements. They are designs, solutions, or wishes masquerading as requirements.  Non-fictional requirements are real requirements.

Factional vs Non-Factional Requirements – Factional requirements are those pushed for by only a certain set of stakeholders. Other stakeholders couldn’t care less about these. Non-factional requirements are required by the system and transcend individual factions.

Frictional vs Non-Frictional Requirements – Frictional requirements are contentious, either to some stakeholders or to other requirements. They also cause friction in the system development by causing the majority of the delays. 

Fallacious vs Non-Fallacious – Fallacious requirements are requirements that are properly written (they are Non-Fictional), but aren’t what is needed. Non-Fallacious requirements are requirements that are needed.

Fundamental vs Non-Fundamental – closely related are Fundamental requirements, which are essential to meeting the objectives. Non-Fundamental requirements are 'nice to haves'. Ironically, building only Non-Fundamental requirements does not result in a nice system.

Function vs Non-Function – Function requirements are about what the system needs the user to be able to do (‘The user must be able to cancel a transaction’). The user is replaced if they cannot perform the function. Non-function refers to user attributes and capabilities (‘The user must have the ability to view the most recent transactions' -- perhaps by possessing SQL skills?)

Familiar vs Non-Familiar – requirements that are common to many systems. These include management reports, etc. Non-familiar requirements are those that haven't appeared before in the project's collective experience.

Favourite vs Non-Favourite – Favourite requirements are flashy requirements sponsored by someone. They tend to be given attention. Non-Favourites languish or are implemented and tested perfunctorily. No one notices if they run away.

Falsifiable vs Non-Falsifiable – Falsifiable requirements are those that can be shown to not exist. Non-Falsifiable requirements cannot be proven to have been met. A quintessential example being ‘The system must be user friendly’. 

Fat vs Non-Fat – Fat requirements are a clump of requirements stated as one single requirement, often with multiple adjectives.  They tend to clog the process. Too many can result in a project heart attack. Non-Fat requirements are singular, and are processed through without harmful effect.

Fiscal vs Non-Fiscal – Fiscal requirements relate to cost ( ‘The solution shall not cost more than $X per transaction’)

Filial vs Non-Filial – Filial requirements are those that can be traced to a parent requirement. They show respect, and obedience, and conform to their parents wishes. Non-Filial requirements are either orphans or contradict their parent requirements. They cause family infighting and should be made to either conform, or else be cut off from family tree.

Fecund vs Non-Fecund Requirements - Fecund requirements are prone to keep popping out new requirements -- annoying, smelly, little new requirements that need lots of care and feeding.

Book Review: Breaking the Code of Project Management

Breaking the Code of Project Management
Alexander Laufer

The genesis of this book come from Laufer’s observation that traditional project management principles need overhauling.  He argues that the growing realisation of the power of empowerment, the poor historical record of project management, the flawed foundation of a major project management tool (PERT), and ‘emerging paradigms’ in research and practice require a new investigation into what is needed to ensure project success.

Laufer is big on using stories as a means of learning and presents his reasons why.  The book brims with stories.

It gave me some discomfort when Laufer referred to the ‘Agile method’ as a ‘project management approach’, given its limited focus on product development (primarily software products).  He also makes the mistake of referring to the ‘four values’ (a pet peeve of mine).

No project management tools appear in this book.  You won’t find discussions of the WBS, PBS, Gantt Charts.  The focus is on what it takes to deliver projects successfully.

Laufer concentrates on what he calls ‘Results-Focused Leadership’, a framework of guiding principles, colour-coded for vividness: yellow for the spirit of will to win, green for planning, brown for implementation, red for people and organisations, and grey for communications.

Recommendation: A practical book on how to deliver projects, yet very different from the standard project management books which cover the tools and principles of project management.  It almost ignores traditional project management.