One thing that jumped out to me reading the article was the author’s (or the organization’s) aversion to writing requirement spec (“detailed documentation”).

That sounded very worrisome particularly considering the fact that the development was for a domain like that of Pharma, where rules & regulations shadows heavily on what and how things are done.

I have some experience in developing software products for Pharma industry and it was quite an effort in keeping track of FDA updates which would impact the features that were under development or were planned for. Examples, basic and mandatory feature sets like Audits, Logging, Security, Access management, Reports etc. are heavily influenced by compliance regulations of FDA and equivalent bodies of Europe, Canada etc. And added layer of complexity is each regulatory bodies have different approach to regulation and compliance.

Considering the fact that Pfizer were outsourcing to ‘code shops’ who would never ever get into that complexity; well thought out requirement documentation which has taken into consideration current and future landscape should have been number one priority. I would have sleepless nights if I was coordinating a project where ‘can do’ developers start working from a basic one-pager from ‘business people’.

I guess it was perhaps because the author was the go between the domain experts (he mentions them as ‘business people’) and the developers.

It would have been great if the author would have shed some light on what could client do from their end in terms of reducing ambiguity while working with teams where communication and loss in translation is one of the biggest risk.

I suspect that there is a whole missing dimension in this story.