There are times when you may consider combining two Requirements into one, so that you can effectively plug two holes quickly.
Whilst this may at first seem a good expedient idea, and emanently achievable, in most cases it’s actually neither.
The more important the requirement, the more care must be taken as to how it is captured, fulfilled and managed end-end. Otherwise you witness what I have – a slow motion crash.
Inevitable mr neo…
Transitioning from a project organisation to a product organisation is hard for everyone. There are many differences between the approaches, primarily the notion of success.
From a mode of working where delivery of a project is finite to the concept of a long game where it’s all about releases, requires adjustment at all levels.
Having worked in a product and project environment I know the issues with both. Trying to help an organisation of one type transition to another, however, is much bigger fry.
I cannot help but feel that leaving this to front line staff is not the right way. Operational and behavioural changes are needed across the board.
For those who are also making this change, best of luck!
Is it necessary to have a unified theory of everything when trying to plan for enterprise architecture?
Should each end state have clear links and defined dependencies to others?
Should there be solid rationale behind the portfolio, so that the moving parts can be affected individually and you still know how they fit and why they should/must?
I think so. And that’s why it pains me when the answer to these are not considered, especially when churning out docs all over the shop.