Systems implementation: what is it like in the trench...

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.

Previously from last two posts...

On last post, I discussed about the main questions to be done by the corporation; presented the Cynefin Matrix, the Hypothesis Driven Problem Solving approach followed by the most of Strategy Consulting firms and advised about TOGAF usage, leveraging the first post, when I proposed the first questions for any Digital Decoupling + Next-Gen ERP implementation.

A good architecture model is result of these discussions performed before any implementation in fact. And this model must be solid to enable the business strategy, embracing changes and having a long lifce-cycle.

"Drawing" / framing these two posts we should see something like this:

Picture 01. Possible framework to business case / assessment

Looks like a good framework - this is one draft of my MSc research. Sounds obvious, but... if any point fails, the cascade happens (the communication among the architecture layers fails) and this is what I'm going to discuss on this post.

The issues seen on trenches

Here cheaper becomes expensive. The "I told you so" sign would be raised when steps at above are not followed and the issues come to project implementation. In general many corporations don't mind about following these steps or don't mind applying the strategy recommendations, they just open the RFP following their IT considerations and hope the implementation team (what may include their consulting partner) will apply their thoughts, being open to any change request without additional costs (and with no delays to go-live or releases dates), according to agile methodology.
All "when" possible scenarios (in overall way) are:

• When the hypothesis are not defined and the questions are not perfomed, the problem is not really known. IT department follows a reactice behavior, wants to solve the visible problems and is not able to come up with business requirements, restricting their point-of-view to implement applications and administrate them. The landscape starts to increment the application number and their complexity. So, the future project implementation won't have all real requirements in consideration.
• When the its complexity is not known, when the corporation people are not known, only some key-people feeling (specially the high management's opinion) are taken in consideration, and this is a risk. Their decisions are high-level costs-oriented (Let's save, no matter what the reality is). So, the future project implementation won't have the best decisions related to people, methodology, costs and partners involved.
• The "when before": when the TOGAF architects are not involved, no one skilled and able to create the strawman will translate the business requirements to functional requirements, non-functional requirements and data analysis. and when no strawman is thought, any strange third partner's RFP "Architecture Reference" response will raise, looking cheaper on beginning but expensive when implemented. So, "alien architecture" raises and increase the chances for stupid change requests.
• When the high level to-be scenario is not known, getting the last points in consideration, the project time won't be enough for future definitions. So, the corporation business team will not have the right people coming up with challenges and embracing the changes as expected. Change Requests risk is higher, increasing the project implementation costs.
• When the all important points for RFP definition is now clear among all players in the corporation, the same is going to read several proposals and not always all third partners response are meaningful to what is really required. So, the risk of starting a bad project on bad way is high, the shareholders will get bad results and the change won't get the expected effects for the corporation.

This is why is important to define good business cases aligned with TOGAF methods - we are speaking technology and/or digital transformation. The IT team loves silver bullet and addresses all issues to Agile Methodology, adding Kanban elements and SAFe tricks but following nothing as expected. And Business Teams love cheaper solutions with magician to design their requirements, with no need of solving technician problems (no programming skill required, no architectural "-illities" to be considered...).

You can read Spotify, Google, Meta or any guru's tactics, but nothing means it is fully applicable (or adherent) to your company's scenario. The fault is not from Waterfalls but to tentative of getting shortcuts.

Going deeper to technology project implementation, The known results of these issues "damage" the project life-cycle with a lot of misunderstanding, not well defined budget (in general, less than required...) and brings:

• Short time, aggressive deadlines. The project to be presented to stakeholders must follow a plan (forget about changing the baseline if anything happens). They expect the complexity project never exceed the Cynefin Simple expectations - the project team would be on chaotic square but the project plan (Gantt chart) must rely on simple square.
• "Firemen" involved - many of them through the project timeline or on go-live morning. Not rare the architecture model if unknown and suddenly a technical architect (out-of-scope, not into budget) joins the project to work only one day and remains on project defining this, spending money and let the project manager crazy about.
• No AS-IS scenario, impossible to think about a rational TO-BE scenario. No Functional Specification closes at time, business approval always delayed.
• Change Request battles over the project life-cycle, with CFO and CIO fighting each other or together against any implementer third partner(s). The corporation perception is damned.

Going deeper to Technical Architecture and Data Architecture issues, the integration layer is not defined, is hard to be defined. Where are the interfaces inventory and systems landscape diagrams? Does the project team know about the synchronous, asynchronous interfaces? Is there any entities diagram? Which integration applications (process integration, ETL integration) are required and where? In advance, all of these questions won't be clear and the architecture layer will need to be defined without any budget / WBS, so change request is expected.

And never forget the Change Management Team, applicable into TOGAF Business Architecture team. Depending on transformation size, this team must never be forgotten.

This is the advantage of hiring consulting firms with wide operation range, since Strategy to Technology and Support / AMS capabilities: they are aware / experienced about these problems and have the right people to all project times. Good and serious consulting companies help to minimize these risks - even they aren't the silver bullet.

The big challenge to solve all these points is the right alignment from corporations architecture layers and strategy. The TOGAF framework must be considered and solid business case should have been considered before any RFP.