You can read a million of these newsletters, blogs and books and think you have a clue, but then you look around your workplace and realize you’re not following any of the best practices you thought you learned for moving to SharePoint.

If nothing else, SharePoint is a complex beast. And—sorry to single you folks out—many of the problems start with IT, which is charged with installing, administering, securing, protecting and maintaining the environment. If you’re a company that’s new to SharePoint, you want to assemble a team representative of your information workers—the folks who’ll be using the software for business productivity—as well as representative of the IT folks who do all of the things mentioned above, to plan for the installation and rollout of the software to your business staff.

In reality, that team (if formed at all) probably meets only once or twice. Let me back up a second.

This ball is put in play when an organization executive reads somewhere that businesses are adopting SharePoint at a rapid pace, and he or she decides to go to IT to investigate. IT comes back and says, yes, it’s a great tool for collaboration and document organization, and the decision is made to go forward and get it.

So then the aforementioned team meets, and the IT guys probably think they’re being courteous (and trying not to look like they’re dominating the meeting) by asking the business what they want out of SharePoint. Of course, the business folks, who haven’t been involved in the initial investigation, kind of shrug and say something like, “I don’t know. What can it do?”

With that, IT concludes the ball is back in its court and must make all the decisions regarding taxonomy, authorization and more, because the businesspeople don’t know what they want. So when the business guys loop back in, they’re faced with lists of names that are accurate but imprecise (such as “editorial,” as an example, for a media company) and that don’t really convey a business need or objective. What’s supposed to go in there, anyway? The editorials they write? All their news stories? Anything that has to do with the editorial department, such as time cards and vacation requests? So, the information workers shrug, lament the fact that another “useless” piece of software is being foisted upon them, and leave the discussion—and will avoid using the software as much as possible.

It would be easy for me to sit here and tell you that you need to go slow with the process, to ensure all needs are being met, but that’s not the reality. In most organizations getting a new piece of software, there’s generally more excitement in IT than from the business users, who care less about the technology and more about getting their job done. For IT, making the technology work is getting their job done. So IT wants to get it done, all out of sight of information workers, who then get it dropped in their laps in the end.

More than scheduling meetings, organizations would most benefit from a standing technology committee from all of their departments, who work together to decide upon the best software to solve business problems, how it should be implemented, when it should be implemented, and how the folks who have to use it can best have their say into how it should be set up.

Has anyone seen a standing cross-department technology committee work effectively? What are your thoughts on the subject?

—David