Because of the focus of my blog, I probably write more than anyone else at IT Business Edge about the need to get IT and business on the same page. But it's a topic almost everyone here manages to touch upon at least occasionally.
Just yesterday, for instance, Loraine Lawson wrote a terrific post (with a bonus "Office Space" reference) about the need for enterprise architects to better communicate with the business to ensure they adequately address business needs.
Like enterprise architecture, creating business requirements documentation is another area that tends to skew toward the technical, so much so that business objectives sometimes are overshadowed.
It's important to anticipate and document how technical change will affect people and processes, said Erik Van Slyke, a founding partner of Solleva Group whom I interviewed last week. Using data structure as an example, he told me:
Any time you change data structure, there is usually a change that occurs to the process of entering or maintaining or reporting out that data. This is almost biblical in that data begets the process begets the role changes. Once the process changes, that process change will end up automatically impacting how people work. Once you change how people work, that might be as simple as changing basic work instructions or work procedures, but the more that changes, you need to really then take a look at whether or not that is impacting the role itself. If a process streamlines and you remove activities from someone's job, that role starts to change. Then once roles change, there are org structure changes. So you look at things beyond the technical like process, work procedures, roles and org structure.
Van Slyke went on to emphasize the importance of bringing IT staff and business users together during the requirements process. I didn't have to dig back too far into our archives to find a great blog post on the same topic by IT Business Edge VP Ken-Hardin.
His short list for what should be included in a good business requirements document includes a detailed description of the desired functionality and an explanation of the business rationale for a project. And, he suggests: "If it is at all possible to draw a picture of something, be it a business process or a UI screen-draw it, or find somebody who works for you that can."
The business needs to remain involved after requirments are written, he writes. Other duties for the business during an IT project: reading "every little line" after IT converts business requirements into functional specifications and alpha testing the deliverable. Will business users welcome this involvement? Not necessarily. As Hardin writes:
Being intimately involved in the dev process is often not as much fun as it sounds. Parsing functional specs line-by-line is a pain, particularly if your stock in trade is selling advertising or writing clumsy blog posts.