The hor d’oeuvres are delicious.
I could not understand the incongruity. How had the IT manager failed to understand the disconnect between the release’s goals and the actual user experience? How had the release made it through Test environments?
The hor d’oeuvres were delicious. The dev team members, exhausted from many double-digit-hour long days were mixing with the business users and business leaders, and I, though peripheral to the effort, was among them. The venue was swank - overlooking the Hudson River with a view to New York City, the Freedom Tower, and the rest of its illustrious skyline. The senior manager in charge of the software delivery was smiling, and laughing, and popping in from group to group to thank the delivery leaders and to converse with the business. It seemed the entire set of business leaders for the delivery had shown up, from the business users up to the business Senior Management.
It was a big rollout! The delivery was to provide a streamlined front-end and numerous functional enhancements to manual processes the business had been enduring for years as the set of enhancements was funded, approved, defined, built, and rolled out.
“Nothing ever comes back”, said one manager to me as I met various stakeholders at the rollout party. “It takes 45 minutes in the screen, before the operation fails”, said another. By the end of the party, I had determined that it might take 2 hours to enter a single user account from inception through to provisioning and finalizing a fundable account; that is, if it did not fail.
The contrast between the IT senior manager’s idea of his rollout and the view of the business was striking. As a senior Data Architect marginally involved with the software design and implementation (peripherally involved, and only engaged at the end when they suddenly realized they had not built any reports and hurriedly rushed some in), I could not understand the incongruity. How had the IT manager failed to understand the disconnect between the release’s goals and the actual user experience? How had the release made it through Test environments?
In post-release review, various checkboxes had been checked along the way: each functional unit test had been tested and passed in dev QA. The dev QA team had sent innumerable bugs back to the development team, but, in each instance, the bugs had been fixed, the test cases had passed, and the feature that was specified was certified as being fully implemented.
Similarly, in UAT, each test performed looked at one feature or functionality, and in each case, the features ultimately passed, albeit in many cases being sent back to dev QA and development.
So what had happened?
1) there was no spec for technical requirements such as Service Level Agreement (SLA) for amount of technical resources required (eg database server memory, storage, rollback space), but, more importantly, there were no business requirements for the time to retrieve or to perform an end-to-end account entry. Consequently, technically the entire release passed. Unwritten requirements do not get tested.
2) IT Manager had an angry temper. Killing the messenger was his Modus Operandi. There was a joke that was told about the tongue-lashing people would get. It was amusing until it was your turn. A joke went around about when it would be time for someone to be in the barrel.
That was the last party for that group of business leaders that IT Manager threw.
I have a feeling there are some AI initiatives where the unwritten requirements are about Data Completeness, Accuracy, and Availability, and about the reliability of the AI in correctly interpreting business rules or business data.
There may be some too afraid for their careers to say it: you are missing the full specification, or what is being built will not work as built.