I fully agree with the premise of this article, but (as a professional project manager of several decades) I think you need to include an element of risk analysis.
In other words, what happens if you have missed a requirement?
If the answer is that a single user fails to place an order, that isn't a serious issue.
But if missing functionality could give rise to significant legal action or financial losses, that is much more serious.
My reasoning is this: if the case is that huge, it should be covered in the initial requirements (first 20-50%). If, for some reason, it slipped through, the engineering team should catch it and handle it (even with a not-so-graceful app crash).
If we don't trust the engineering team is capable of catching that early, it's a wrong engineering team, or it's being driven in a very feature-factory manner. There will be no big wins with such a team 🤷♂️
My experience of engineering teams is that they are normally highly technical and usually not very business savvy. Someone else gives them business requirements.
And as an seasoned IT manager, I would absolutely prefer to do some deliberate and formal risk analysis than hope that a (technically focused) engineering team will spot these risks/needs.
I must say my experience is not very different here. I work with highly technical teams that expect nearly 100% clarity from the business. However, fortunately, I also have other groups - the ones who deeply analyze their business impact, usage of the product (not just technicalities), who calibrate their skill set to maximize product output, and balance excellence with delivery. All of these without being told explicitly to do so.
On the surface, these teams are very similar (hard) skillset-wise. However, in the long term, the difference in performance is apparent.
I fully agree with the premise of this article, but (as a professional project manager of several decades) I think you need to include an element of risk analysis.
In other words, what happens if you have missed a requirement?
If the answer is that a single user fails to place an order, that isn't a serious issue.
But if missing functionality could give rise to significant legal action or financial losses, that is much more serious.
My reasoning is this: if the case is that huge, it should be covered in the initial requirements (first 20-50%). If, for some reason, it slipped through, the engineering team should catch it and handle it (even with a not-so-graceful app crash).
If we don't trust the engineering team is capable of catching that early, it's a wrong engineering team, or it's being driven in a very feature-factory manner. There will be no big wins with such a team 🤷♂️
My experience of engineering teams is that they are normally highly technical and usually not very business savvy. Someone else gives them business requirements.
And as an seasoned IT manager, I would absolutely prefer to do some deliberate and formal risk analysis than hope that a (technically focused) engineering team will spot these risks/needs.
I must say my experience is not very different here. I work with highly technical teams that expect nearly 100% clarity from the business. However, fortunately, I also have other groups - the ones who deeply analyze their business impact, usage of the product (not just technicalities), who calibrate their skill set to maximize product output, and balance excellence with delivery. All of these without being told explicitly to do so.
On the surface, these teams are very similar (hard) skillset-wise. However, in the long term, the difference in performance is apparent.