Training

The essence of training is acquiring or improving skills.  If you undergo training, and no change occurs in how you do the things you were trained at, then the training did not matter.

If you had a certain way of planning projects, and underwent training on how to plan projects more correctly, then you went back to your way (which was not as good), then the training did not matter. Sometimes the reason you went back to the old way was not due to yourself. Perhaps the organisation you work in prefers the old way, and resists the new way (a very common situation), then you face incongruity. You know what you're doing is not as effective as the new way, but you 'have no choice'. It takes a lot of effort to try and change an organisations. If you tried, you may end up alienating people, or making enemies. There is also the risk that your execution of the new way won't be as effective as the old way. This is a real risk, because after all, you are just a beginner in the new way.

Random thoughts

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.

Manifesto for Agile Corporate Finance

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.

It's "Manifesto for Agile Software Development"

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.

Voicemail for Doors

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>"

Business Requirements

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.

Some of the business requirements, in order to be met, will also generate user and system requirements (eg business requirements to meet policies relating to disability).

Business requirements can derive from organisational policies, strategies, business case, and a range of other sources.

Examples of business requirements are:

• The solution must cost no more than $100m
• The technology platform must be AWS (or Azure, or Google) - for example, because organisational policy requires that IT solutions use these platforms.
• The solution must be fielded by 2nd quarter of 2025, to align with the strategy.
• The solution must meet data privacy policies.
• The solution must meet policies supporting users with disabilities.

Systems Engineering Bibliography

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.