I read an email from an IT director a few weeks ago that was explaining how we should proceed with a particularly troublesome issue. The email explained that the User's of the system can "recommend" changes to the website, and that IT will "review" them. It's old school to say "recommend", like really old school, before the concept of documenting requirements to solve a business problem old school.
How does this happen? How can IT management still think that they have the innate ability to understand the intricacies of what business User's want without documenting requirements? It can't and that's the point.
With most information technology, the people who know how the software is designed to solve issues are the first ones to evangelize the usefulness of it. They are usually very familiar with the business processes and at the time know a lot about what the Users need. However, over time these same folks will inevitably lose that edge. That is when they need to start asking their User's what they need. The problem is that pride and prejudice enter into the behaviors and thoughts of the original designers of the system. They are the architects. They feel entitled to dictate what should and should not be included in future designs.
Thus, please be sure there is ample documentation of requirements and functional specifications which solve the issues, and that these docs are updated or superseded. The worse thing that can happen to a system in the long run is to rely on one architect for all design questions and answers because the one person is surrounded by many who have unique perspectives and could potential have more innovated ideas on how to solve problems.
How does this happen? How can IT management still think that they have the innate ability to understand the intricacies of what business User's want without documenting requirements? It can't and that's the point.
With most information technology, the people who know how the software is designed to solve issues are the first ones to evangelize the usefulness of it. They are usually very familiar with the business processes and at the time know a lot about what the Users need. However, over time these same folks will inevitably lose that edge. That is when they need to start asking their User's what they need. The problem is that pride and prejudice enter into the behaviors and thoughts of the original designers of the system. They are the architects. They feel entitled to dictate what should and should not be included in future designs.
Thus, please be sure there is ample documentation of requirements and functional specifications which solve the issues, and that these docs are updated or superseded. The worse thing that can happen to a system in the long run is to rely on one architect for all design questions and answers because the one person is surrounded by many who have unique perspectives and could potential have more innovated ideas on how to solve problems.
No comments:
Post a Comment