A dissertation that has typos has too many words.
A dissertation that has typos but makes sense nevertheless is not a dissertation worth writing.
If writing is a muscle that can be trained to improve one's writing, don't forget to train both the left and right parts of the brain, lest they grow uneven.
Suppose that in 2001, seventeen corporate finance professionals came together at a ski lodge, and wrote a document called "Manifesto for Agile Corporate Finance", and one of the values promoted is "Cash on hand over receivables" (analogous to 'working software over comprehensive documentation).
How bizarre would it be if the values espoused in their manifesto then gets used as bedrock foundations for: the right way to build software, run projects, and a host of other activities unrelated to corporate finance?
I also wonder if everyone would be calling it the "Agile Manifesto" for short, omitting the "for Corporate Finance", thus obscuring its intended domain.
Whenever someone refers to the "principles of Agile" and claims these principles are found in the Agile Manifesto, always remember the manifesto is called "Manifesto for Agile Software Development".
It's not "Manifesto for Agile Anything". It's not "Manifesto for Agile Marketing". It's not "Manifesto for Business Agility". It's not "Manifesto for Agile Project Management"
It's a manifesto for agile software development.
The manifesto was written by software developers to promote better, faster, more enjoyable, higher quality software and software development experience.
Busy working on a new product: Voicemail for doors.
If someone knocks on your door (or rings the doorbell), it prompts: "Hi, I can't come to the door right now. Tell me who you are and why you're here, and I'll open the door as soon as I can. <beep>"
In the field of systems development, we distinguish between different kinds of requirements, such as top level requirements, business requirements, user requirements, and system requirements.
Business requirements refer to the overarching needs and constraints imposed by an organisation's stakeholders on the solutions to a problem. They delineate the range of acceptable solutions to the problem, but without going too much into the solution. User requirements in contrast dictate needs relating to how the solution will be operated, maintained, and used.
Business requirements can derive from organisational policies, strategies, business case, and a range of other sources.
Examples of business requirements are:
Buede, Dennis M. The Engineering Design of Systems: Models and Methods, 3rd Edition. John Wiley & Sons, 2016.
Strong focus on function analysis and decision analysis. Good introduction to IDEF0.
Chapman, William L., Terry Bahill, and A. Wayne Wymore. Engineering Modeling and Design. Boca Raton, FL: CRC Press, Taylor & Francis Group, 2019.
Forsberg, Kevin, Hal Mooz, and Howard Cotterman. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems. Hoboken, NJ: J. Wiley, 2005.
The rare project management book that gives emphasis on the critical importance of systems engineering.
Gibson, John E., William T. Scherer, William F. Gibson, and Michael C. Smith. How to Do Systems Analysis: Primer and Casebook. Hoboken, NJ: Wiley, 2017.
Teaches systems analysis (systems decision making) rather than systems engineering. Systems analysis is an essential practice in systems engineering. Bahill's book on trade-off analysis is another one of few books on the subject.
Hitchins, Derek K. Systems Engineering a 21st Century Systems Methodology. Chichester, West Sussex, England: John Wiley, 2007.
Kossiakoff, Alexander, Steven M. Biemer, Samuel J. Seymour, and David A. Flanigan. Systems Engineering: Principles and Practice. Hoboken, NJ: John Wiley & Sons, Inc., 2020.
James, Martin. N. System Engineering Guide Book. Springer, 1997.
Rechtin, Eberhardt. Systems Architecting: Creating and Building Complex Systems. Englewood Cliffs, N.J: Prentice Hall, 1991.
Sage, Andrew P., and Andrew P. Sage. Systems Engineering. New York: J. Wiley & Sons, 1992.
Stevens, Richard J. Systems Engineering: Coping with Complexity. London: Pearson/Prentice Hall, 1998.
Walden, David D., Garry J. Roedler, Kevin Forsberg, R. Douglas Hamelin, and Thomas M. Shortell. INCOSE Systems Engineering Handbook: a Guide for System Life Cycle Processes and Activities. Hoboken, NJ: Wiley, 2015.
Wymore, A. Wayne. Model-Based Systems Engineering: an Introduction to the Mathematical Theory of Discrete Systems and the Tricotyledon Theory of System Design. Boca Raton: CRC Press, 1993.
What are the user requirements for using an ATM? The most obvious ones are: ability to withdraw cash, ability to check account balance, ability to make deposits.
But how about others: ability to retrieve all the coins and cash in the ATM, ability to unjam the ATM if things get stuck, ability to physically move the ATM?
They are not requirements of the bank's customers, but they all valid user requirements. The user requirements depend on who the users are.
To build a successful systems, it's necessary to identify who the users of the system are. The 'who' does not mean specific persons, but categories (or types) of users. For an ATM, these can include: the paying stakeholder, bank customers, customers of other banks with whom the ATM's bank has arrangements with, bank personnel who need to manage the ATM, security personnel, network staff who need to ensure the ATM is connected, back office bank staff who need to analyse and report on data about ATM usage, and so on.
It's clear that if we miss one of the categories of users, we will be unlikely to have miraculously provided system functionality that satisfies their needs.
One challenge to identify categories of users occurs when we are building new systems that are not merely upgrade of existing systems. In this case, there are currently no existing users. The categories of users would need to be identified. Other sources, such as the concept of operations, or the operating model are sources of an initial set of users.
Does your system development process include a rigorous identification of the system users?
References:
Stevens, R. J. (1998). Systems engineering: Coping with complexity. London: Pearson/Prentice Hall.
Derivatives contracts come in two basic types: forwards, and options. More complex derivatives contracts build on these basic types.
FORWARDS
A forward contract is an agreement between two parties to trade a specified volume of a specified asset, at a specified price, at a specified future date. It's a binding, legal agreement.
Terms
The asset being traded is called the underlying asset. These can be commodities, shares, indexes, etc. The expiration date is when the contract has been settled. The spot price is the current market price. The term long is used to refer to the buyer, and short to the seller.
Payoff on a Forward Contract
Generally, the long party benefits when the (spot) price of the asset goes up (relative to the contract price), and the short party benefits if the price of the asset goes down.
For example, let's say the contract was to purchase a unit of stock index at $1,000 at the end of December. If at the end of December, the spot price for that stock index is $1,500, then:
Long position to the contract makes: $1,500 - $1,000 = $500, because they are able to buy the asset at $1,000 instead of the current market price of $1,500.
Short position to the contact loses: $1,000 - $1,500 = ($500), because they are obligated to sell the asset at $1,000 instead of the current market prices of $1,500.
FUTURES
Futures are forward contracts that can be traded at futures exchanges. Some futures exchanges are the CME (Chicago Mercantile Exchange), ICE (Intercontinental Exchange), LIFFE (London International Financial Futures Exchange), Eurex, SGX (Singapore Exchange), OSE (Osaka Tokyo Exchange), and the HKEx (Hong Kong Exchange and Clearing).
A party may buy a futures contract and become the new party. The party that sold the contract removes themselves from the trade.
OPTIONS
An options contract gives the buyer of the contract the right (but not the obligation) to trade an asset at the contract price. There are two kinds. The call option gives the buyer of the contract the right to purchase an asset. The put options gives the buyer the right to sell an asset.
Options Terminology
The strike price is the price the buyer pays for an asset, also called the exercise price. The act of acting on their right is called exercise. Options contracts indicate the style of exercise allowed:
Call Options
A call option that gives the buyer the option to not buy the asset if the contract price is higher than the spot price; ie, if they will lose money. The seller's obligation remains the same: sell the asset at the contract price. In a call option, the seller can only lose money, so the payoff comes in the form of a premium. The seller needs to be paid upfront to put themselves in this exposure.
References
McDonald, Robert Lynch. Derivatives Markets. Boston: Pearson, 2013.
Notes from Chapter 2 of Understanding Variation: The Key to Managing Chaos, by Donald J Wheeler
The chapter is titled:"Knowledge is Orderly and Cumulative". Here Wheeler discusses three approaches to interpreting data, and the benefit of the control chart.
Two people may have access to the same set of data, but they can arrive at different conclusions. The reason is because they may have different interpretation processes.
Not all interpretation processes are valid. Wheeler describes two problematic approaches, and then discusses Shewhart's approach.
The Specification Approach
The first approach is 'comparison to specifications', or the Specification Approach. In this approach, data is interpreted in comparison to specifications, and its 'goodness' or 'badness' is determined based on how well it conforms to specifications.
For example, management may demand that the factory produce 1,000 units per month (the specification). If the factory produces 800 units in one month, that figure is interpreted as 'bad'.
Comparison by specification leads to binary results: either data conforms or it does not. it also leads to sudden changes in goodness or badness. A process could be in good graces one month, and in bad graces in another.
But the biggest problem with this approach is because specifications are the 'voice of the customer'. This is what the 'customer' wants. The process has nothing to do with it. The voice of the process is what the process is able to achieve. If the voice of the customer and the voice of the process is not aligned, the result is people distorting the system or distorting the data in order to meet the specification on paper.
Nevertheless, the voice of the customer is important because it tells you when you're in trouble.
The Average Value Approach
The Average Value approach compares the goodness of data against the average value of the data. "Why is sales 10% below last year's average?". This approach to interpreting data leads to pathologies similar to the Specification Approach -- people tend to distort the system or distort the data so they don't have to explain why the data is too far away from the average.
At least the Average Value approach uses the voice of the process (after all, the average value is produced by the process, and not some arbitrary number).
Shewhart's Approach to Interpreting Data
Walter Shewhart was the first to define the voice of the process. He called this a "control chart."
A control charts has time in the X-axis, has a central line, has two control limits, one on either side of the central line, both the same distance from the central line. The distance of the control limits is determined from the data, from the voice of the process. The values plotted can be raw data, or some value calculated from the raw data.
The control chart helps interpret the data by characterising the behaviour of the data and allowing us to predict the future behaviour of the data.
The control chart shows that there really is no distinction between good outcomes and bad outcomes; they both came from the same process.
A process that is in control is predictable. In other words, we can predict its behaviour in the future and make plans based on that prediction.
The Second Principle for Understanding Data
Shewhart's second principle for understanding data is:
While every data set contains noise, some data sets may contain signals. Therefore, before you can detect a signal within any given data set, you must first filter out the noise.
(His first principle is introduced in Chapter 1. It's: No data have meaning apart from their context.")
The two mistakes that could be made in analysing data is treating random variation as a meaningful departure from the past, and the second mistake is not recognising when data is a sign of change.
Attempting to avoid the first mistake by not reacting to variation can cause you to miss true signals of change, and thus make the second mistake. Attempting to avoid the second mistake by reacting to every signal causes you to make the first mistake
The key benefit of a control chart is it identifies for you data that is noise, and data that is signal.
Requirements professionals, who help shape the products are trained to: "Focus on needs, not on wants."
Sales professionals, who sell the products, are trained to: "Sell on wants, not on needs."
There seems to be a disconnect here somewhere.We'll know the robots are taking over when CAPTCHAs begin to look like this.
***
Premature allocation of requirements is the root of many system architecture evils.
(With a hat tip to Donald Knuth, who coined: "Premature optimization is the root of all evil.")
***
Actor Giancarlo Giannini delivers a memorable line in the movie "A Walk in the Clouds". Giannini plays Alberto Aragon, a Mexican father, very protective of his daughter. He reminds a younger American man (played by Keanu Reeves): "Just because I talk with an accent doesn't mean I THINK with an accent!".
He's right, however, he's only partly right. He does think with an accent -- WE ALL THINK WITH AN ACCENT.
Our 'thinking accent' is formed by our age, base intelligence, education, cultural background, industry, personal experiences, personality, values, fears, intentions, and so many other factors. It makes each one of us see and process things differently from others.
***
Short posts I made on LinkedIn
Do rewards motivate people to behave in the desired manner, or do they just attract people motivated by rewards?
***
Soldier pinned down by enemy fire: "Fire Control, this is Foxtrot. We need close air support now! Over."
Fire control reservist (who is a Business Analyst in civilian life): "Foxtrot, that's a solution, not a requirement. What do you REALLY NEED? Over"
***
If you fail to plan, plan to be agile.
***
***
If you like putting out fires you should be a firefighter.
If you like recovering after a fire you should be in disaster recovery.
If you like tallying up the cost of fires you should be in accounting.
If you like analysing tradeoffs between the risk of fire and cost of prevention you should be an analyst.
If you like preventing fires you should be in safety or quality.
If you like monitoring distant fires and where they are heading you should be in risk.
If you like playing with fire you should be a scientist.
If you like harnessing fire you should be a manager or engineer or entrepreneur.
If you like starting fires you are just an arsonist.
***
If you attended a course that teaches how to do better in IQ tests, and you did get higher scores afterwards, did your IQ get higher, or did you just learn how to do better in IQ tests?
***
***
***
***
A collection of short posts I made on LinkedIn:
The MoSCoW priority labels coincidentally also describe Hitler’s and Napoleon’s changing attitudes toward capturing the eponymed city:
Must have it
Should have had it by now
Could have it still if only
Won’t have it.
* * *
Not everything that matters can be measured
Not everything that can be measured matters
To twist JFK’s words:
Ask not what you can measure
Ask what measures can do for you
To badly paraphrase Einstein:
Everything that matters and can be measured must be measured, but no simpler
***
Carpe diem caveat – “Seize the day”, not “cease the day”. The intention may be the former; the result may be the latter.
***
Continuous improvement must seek to do two things: make existing processes better, and stop introducing new bad processes in the first place.
***
Remind your audience that THERE IS such a thing as a stupid question -- it’s the question you keep to yourself.
***
Lots of people talk about 'Systems Thinking'. What's the verb for doing systems thinking it? Shh... be quiet, I'm systems thinking!
***
If you believe that user stories are requirements, try calling them 'user requirements'.
***
What's the term to describe the opposite of scope creep -- when scope keeps getting reduced because we're running out of time or budget?
***
Inspired by, "I have a statistics joke, but it's not significant" (floating on the internet)...
I have a project management joke, but it's still in the concept phase.
I have a risk management joke, but there's no appetite for it.
I have a requirements analysis joke, but it's not functional.
I have a logistics management joke, but I can't deliver it properly.
I have a Scrum joke, but it's not empirical enough.
I have a Scrum joke, but we'll have to do a retrospective afterwards.
I have a Lean joke, but I never remember it just in time.
I have a Kanban joke, leave your card here and I'll tell it to you.
As an Agile proponent, I want to say I have a joke, so that people can get amused.
I have a systems thinking joke, but I have to say it with 30 others jokes before you'l get it.
I have an andon joke, but you have to stop me if I'm telling it the wrong way.
(Part of my undertaking to read Chapter 2 of books in my library.)
This book was published in 2014, so there will be some contents that are out of date. A lot of activity has occurred in the central counterparties regulatory world recently.
Many derivatives contracts, such as options, and futures, are traded on an exchange. In an exchange, derivatives contracts are standardised. Standardisation leads to efficiency and tradeability.
While originally, contracts where traded on an exchange where the exchange served merely as a witness, and not a counterparty to the trade. If a trading party did not live up to the contract, the exchange would fine them or even expel them.
Only approved firms and individuals may trade in an exchange.
Exchanges facilitate margining and netting between trade counterparties, which reduce the magnitude of risk for each side.
There are 3 forms of clearing: direct clearing, ring clearing, and complete clearing. Direct clearing is where each party delivers their contract obligations to the other. If there are offsetting trades, often the practice is to just net the difference, a practice called "netting", or "payment of difference". Ring clearing is an expansion of direct clearing to more than two parties. The parties must agree to join the ring. If A must pay B, who must pay C, then C can receive the payment directly from A. The exchange itself is not a participant other than an enforcer of rules. A disadvantage of rings is that a quality counterparty may be replaced by one that has lower credit quality. Not everyone in the ring benefits. Complete clearing extends and improves the ring by placing the exchange as a central counterparty to all parties. A party no longer has to worry about the credit rating of their counterparty; the exchanges assumes the rights and responsibilites of the counterparty.
Of course, if an exchanges assumes the obligations of a party, it must protect itself from exposures arising from an insolvent party. Two ways to mitigate the exposure is through the practice of initial margins and variation margins. In addition to margins, a method of loss sharing is also implemented. One practice is requiring all members to make share purchases.
There was resistance to this concept early one: firms with high quality rating felt they lost their advantage over lower quality firms because a firm's credit rating became irrelevant. The counterparty service can be provided by the exchange, or be provided by another firm offering that service for the eschange.
All derivatives market clearing service became standardised and used central clearing until OTC's arrived on the scene.
To be continued...
Chapter 2 "Establish Quality Goals"
NOTES
A goal is an "aimed-at" target. A quality goal is a quality target you are aiming for. The goal would typically include "a number" and a "time table"A job ad for a software engineer listed the following tools. I'm not familiar with half of them (not even by name). Writing down the list as I'm curious to do some digging and find out what each are:
I have quite a number of books in my library, virtually all of them non-fiction. I'm starting to think there's not enough time to read them all. Skimming each one doesn't really help me absorb them, so I thought it might be interesting to explore the books by reading Chapter 2 of each.
Chapter 2 of this book is "Decision Fundamentals for Thinking Clearly". It's a short chapter and touches very briefly several topics relevant to thinking clearly.
We get a reminder that decision rigor is 'driven by the fear of a negative outcome'. This is something we all instinctly already know. We become more anxious when the decision has serious consequences (eg, which univerisity to go to), and are rightly less rigorous when the consequences are not serious (eg, what to have for lunch).
An interesting paragraph is on when do we actually 'make' a decision? Does deciding one way or another constitute making the decision or is further action required? Some decision experts say you make the decision when you irrevocably allocate resources. (I had not heard of this before. I think it's a good criteria). The author argues against it because it fails in some cases. His example is the decision to lose weight and deciding to eat less. Contrary to this criteria, the decider has actually decided NOT to allocate resources (food).
The author defines a good decision as 'applying informed judgment based on relevant facts and quality ethics to select an alternative and act on it'.
A short paragraph reminds us that the outcome does not define whether a decision is good or not. This is pretty much an obligatory topic in any decision making text. Another paragraph covers another obligatory topic -- the fallacy of sunk costs.
Mooz introduces a concept new to me: 'Cost / Price of Indifference'. It is the purchase price at which you don't care (emotionally) whether you get the goods or not. He suggests this is a time saving concept when purchasing or selling anything. Rather than agonising hours and hours over how much to bid, just bid at this price. He did not discuss this in the context of buying stock market shares. I think that will be interesting to consider.
There are two stages to decision-making. The first is Decision Preparation. This is about getting the decision statement right, setting up the decision type frame, and the decision solution frame correct. The second stage Deciding, which is about the act of selecting from the alternatives that were set up in the decision solution frame. (The author didn't mention this, but I recognise this 2-stage framework as classically systems engineering).
Other short topics covered is the decision maker's viewpoint, decision fitness, and decision fatigue. Decision Fitness is another concept I had not heard of before. This is a concept about the fitness of the person making the decision. They must be proficient at the following skills:
Often heard: "What you experienced was not true Agile."
Never heard:"What you experienced was not true Waterfall."
In a VUCA world, objectives must be SMART:
S – Subjective
M – Machiavellian
A – Adjustable
R – Reactionary
T - Tentative
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.
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.
Fergus O’Connell claims that the real reason why time management courses fail is because ironically, they try to teach time management. This is the wrong approach, says the author. What they should be teaching instead is that people should aim to do less work. This is the aim of this book.Philosopher: Anything worth doing is worth doing well.
Pragmatist: Anything worth doing is worth doing badly.
Academic: Anything worth doing is worth publishing.
Businessman: Anything worth doing must be worth doing.
Entrepreneur: Anything worth doing I already did last week.
Accountant: Anything worth doing is worth recording the worth.
Procurement: Anything worth doing must be done at the lowest cost.
Frederick Taylor: Anything worth doing can be done more efficiently.
Lean Consultant: Anything worth doing must be done with the least waste.
Venture Capitalist: Anything worth doing? Call me.
Procrastinator: Anything worth doing is worth doing tomorrow.
Agilist: Anything worth doing should be prioritised in a backlog.
Manager: Anything worth doing can be delegated
Economist: Anything worth doing, surely someone has already done it.
Project Manager: Anything worth need to be delivered on time, to budget, to scope.
Risk Manager: Anything worth doing must be worth doing on a risk-adjusted basis.
Pessimist: Nothing is worth doing
Optimist: Everything is worth doing. With a smile.
Cynic: Anything worth doing is always done for the wrong reason.
The popular version of 5W and 1H is a reminder to ask: Who, What, When, Where, Why, and How?
The new, or older, if Machiavellian roots are traced, is practiced as:
WHO should we blame?
WHAT is in it for me?
WHEN will they find out the truth?
WHERE can we cut quality?
WHY me?
HOW can we hide the problem?
***
Here are some tips I can share about taking and passing the exam:
When all you have is a hammer, everything is a nail.
When you don't have a hammer, there's nails everywhere.
***
There's a playful way of explaining the reason why one does something. The argument ends with the rationale "because <noun or adjective>."
We can recommended this as new format for user stories, because it's aligned with how people speak these days.
AS A phone user, I WANT TO upload photos in one click, BECAUSE one-click!
AS A bank customer, I WANT TO see my balance on my phone, BECAUSE money!
***
With a slip of the tongue, I came up with a wonderful, terrible portmanteau:
"Projuct". Defined as the product of a project.
***
