Thinking about complexity of projects AND "Tech Strategy & Advisory" BEFORE starting any project

DISCLAIMER

There is no silver bullet, I'm not the the "self-proclaimed arbiter of truth" and I'm writing following my experience and research. Any "positive review" is welcome.
I'm not going to provide details here about any company implementations (due to privacy reasons) but write about the concept on "open way". And check against the real and academic point-of-view from Software Engineering and Enterprise Architecture - my thesis on MSc. program.

Where do I research good sources?

One of most important aspect to be thought is: how complex is my landscape, environment, business and application match? Is my corporation coming up with a chaotic life or truly controlled life? Is it really good for us as company?

I'm not a coach and several books and studies thesis about should be found on Harvard Business Review (for business point-of-view, white papers articles) or SCOPUS (https://www.scopus.com/home.uri) when thinking about scientific point-of-view due to scientific articles, in general accessible for academic public. Some mates like to use the Google Scholar but its indexing way is broader than Scopus and there is risk of getting "predator" sites; getting research "at work" / preview documentation from Arxiv.org is other risk - everybody can post there but there is no confirmation this document was finished, reviewed and approved by any good and "official" scientific research group like ACM, IEEE, Elsevier, Web of Sciences, Willey, Nature...

The dangerous questions to be done... looking for bad news, firstly

Before starting any new project, in a simplistic point-of-view, the project management and stakeholders should at least starting thinking on this way to collect the most dangerous questions BEFORE requesting any project proposal:

1. Do they really need to have any technology / digital transformation (or landscape upgrade)? Is their business really attended by technology landscape? Will any new landscape be able to solve this matter?
2. Is the application, business, technical, data architecture teams integrated and able to deliver (and code...) and manage composable architecture? Do they have skills (it should be closer to the prior question)?
3. Do they know the AS-IS scenario of their corporate process?
4. Do they know the way to reach the expected TO-BE scenario for their corporate process?
5. Is the business teams interested to simplify their process, decommission any unnecessary application and follow the standard process available on packaged systems, based on market best practices?

Cynefin matrix

One interesting approach (and simple) is related to Cynefin Matrix which is about project complexity - https://en.wikipedia.org/wiki/Cynefin_framework.

Basically any problem should be "deployed" over any one of these four domains / quadrants:

1. The Simple means the situation / problem is under control, should follow best practices and there is structure way ofs working to come up with - typical routine in operations, eg: job execution following a structured documentation.
2. Complicated means the problem requires attention and there is way to follow structured process. Scope is on control. Remembers a typical engineering project like a building or airplane design - not easy, requires a lot of efforts and studies, but there is a structure methodology to be followed and reach the aims.
3. Complex looks like the complicated but with a dose of unpredictability, like a cat behavior. Methodology helps to act, but there is no silver bullet to all "impossible" situations being faced on the next next morning.
4. Chaotic means the high level of unpredictability (like an advanced burning building), no perceptible relationship between cause and effect. Snowden and Boone wrote on Harvard Business Review. 85 (11): 68–76. PMID 18159787 (https://hbr.org/2007/11/a-leaders-framework-for-decision-making): In the chaotic domain, a leader’s immediate job is not to discover patterns but to staunch the bleeding. A leader must first act to establish order, then sense where stability is present and from where it is absent, and then respond by working to transform the situation from chaos to complexity, where the identification of emerging patterns can both help prevent future crises and discern new opportunities. Communication of the most direct top-down or broadcast kind is imperative; there’s simply no time to ask for input.

Hypothesis driven problem solving - and why Tech Strategy approach matters?

What is the suggested approach to advance on this mindset? In general, "smart" companies have their own strategy sector to analyze on all "corporate dimensions" how to proceed - and TOGAF is an excellent framework to be coupled on this job, letting IT serving the Business as expected. Or at least these companies hires Tech/ Digital Strategy Consulting firms to analyze, creating strong and complexes Business Cases to C-suite level, enabling them to take better decisions. But this kind of ways-of-working costs and large companies are more prepared to invest on.

In general, these Strategy Companies follows the "Hypothesis driven problem solving" - HTTPS://ONLINE.LINDSAYANGELO.COM/F/HYPOTHESISPROBLEM-
SOLVING-TEMPLATE.
In summary, it is composed by these steps:

1. Define the problem
2. Develop your initial hypothesis
3. Gather and analyze information to validate or refute your hypothesis
4. Pivot your hypothesis and arrive at your solution

Structuring a possible "framework" to address a technology / digital project with all of these ideas...

Taking in consideration all considerations from this post before and following my previous one (my previous post - https://dev.to/eng_cabrera/digital-decoupling-and-next-gen-erp-sap-like-implementations-first-considerations-2nf1), we'll have a good material to work on.

The next-gen ERPs, like SAP S/4 Hana (or any other famous packaged vendor, like Oracle or TOTVS too, whoever!), must follow this mindset approach and avoid unnecessary implementation costs, reducing Change Requests needs. TOGAF is a strategic framework and consider all required forces to be applied on a corporation, creating the real Enterprise Architecture mindsetting.

The alignment among all TOGAF architecture branches is going to create the Enterprise Architecture: Data (includes the integration architecture, middleware team), Business (Strategy, Change Management), Technical (Infra and all non-functional requirements) and Application (functional and developer resources).

My in-progress MSc. thesis is focused on Application and Technical branches, but I see there is a lot of gaps among all layers (good for next researches, for my future and coming PHD).

Coming posts... or next steps

For next post, I'm going to complain about failures I see on the overall market - the bad side / news of this post. It's not only seen on Brazil, but in many places, with or without consulting companies working with clients. IT market is full of non-technician people, who never read the classic books or never interested on study "computer sciences on roots". Having an engineering degree, computer sciences or coming from top universities is not enough to work on IT area, it's mandatory to study more and more - "when you think you know 95%, you'll find out you know only 0.05%", said my old UNESP teacher for Microprocessors classes. For IT it's the "groundhog day" ways-of-working, so: study forever and ever.

All of these points are my research focus and I want to share here, on free way.