In many years with SharePoint portal projects I've seen my share of good, solid product deliveries. I've also seen my share of epic failures. Regardless of setting, scope, resources, or other "stuff" there is one common factor that if present, ensures success, or if absent, guarantees failure. That factor is purpose.
We can talk all day long about capacity plans, extensibility, governance, or taxonomy. But if there is no reason for the users to use the portal in the first place, the implementation is nothing but a qualified exercise of installation. For a portal project to achieve any level of success, it must have some claim to value within the organization's environment. A good project team can engineer around poor capacity plans, technical limitations, governance gaps, and weak taxonomy. But you can't engineer around "uselessness."
On the other hand, a portal that has day one “usefulness” will attract (as opposed to force) users; driving adoption; and easing the later stages of implementation (the dreaded training!). From that I’ve coined the phrase “purpose driven portal.” And, thanks to a certain pop-book, do feel free to accept or reject a certain ring of religiousness there. After all, knowledge and information management are sort of the “religion” of the organization when you think about it.
Portals are the manifestation of an organization's information management processes (in whole or part, you take what you can). While I avoid trying to stake a claim within that rarified air of "knowledge management," yes that does come with the meal. Regardless, the reason portals sound so appealing to organizations in the first place is the promise of facilitating the IM process areas.
Unfortunately, we often see those IM processes mentioned in conjunction with scope statements like "... help with document management..." or "...allow project collaboration..." Fairly ambiguous functionality declarations, almost as if shuffling documents around the workspace is the whole reason the organization exists! With no specific reason for users to be “on” the portal, there is no driver to pull them out of the “file-share to email-attachment” mode of operation. And in short order, the IT department then has yet another “enterprise resource” to maintain which is not even close to any ROI figures quoted in the initial concept layout.
I would argue that IM processes should be the easiest for an organization to map out. After all, this “information” is the “stuff” by which the organization earns its pay (or whatever the pile of goodies at the end of the day is). But perhaps as with our own personal foibles in life, the closer one is to the process, the harder it is to articulate what the process is. So it is up to the SharePoint implementers in many situations to better define, refine, or even drag out those processes.
Over the span of a few posts here, I’ll explore some tactics, techniques and procedures for defining, refining, and, as needed, dragging the processes out of conversations during the early stages of SharePoint implementation.