Non-technical Input on Technical Standards and Requirements

Many technical groups within organizations feel that they own all things technical and therefore should define requirements (for example, CMS requirements) and technical standards (for example, the Web Tools and Applications standards team that we recommend groups have).  On the one hand, I totally sympathize with these groups (I come from the technical side of things) since they often end up getting burned by tools acquired by other groups that they must then support.  Also, many non-technical groups feel out of place and overwhelmed by the idea of helping with technical standards. That said, everyone gets burned if the technical requirements and/or standards do not sufficiently support users, so non-technical input is key (even though finalization of technical requirements / standards will rest with the technical team).

Here are some reasons non-technical staff should be involved in technical standards and requirements:

Prioritization

Functionality may be discounted from a priority perspective by the technical team.  Note that even if eventually a decision is made against a difficult-to-implement functionality, then at least everyone had a chance to discuss it.  Many of these decisions may be largely irreversible so, at a minimum, everyone should have their thoughts heard. 

• “Friendly urls.” The technical team may want rewriting a la tinyurl, whereas business representatives may want only urls that “stick."
• Single sign on details. Users may want simpler passwords, so a risk/reward discussion may be required.
• CMS requirements. For example, user interface issues.
• Browser compatibility. Business/user representatives may have knowledge that others do not about key users that require certain browser compatibility.

Perspective

More subtle, but perhaps even more important, is that the technical teams and non-technical folks may have a different perspective or angle on the same issue.  This may even mean that less work is required of the technical teams (I have seen this happen frequently).  Other specific examples:

• Load time. The tech team may prefer looking at methods that are easy to capture, whereas from an end-user perspective other issues may be more important.  For example, uncached load time on client side.
• RSS. The tech team may want to just “turn on” RSS through whatever tools are available, whereas business users may look at it more broadly to include RSS analytics, RSS landing pages, RSS across multiple systems, etc.

This client/user perspective can also help define the  business drivers behind why certain metrics need to be gathered and how that may impact tool selection.
 

Take Heat / Workload Off of IT

This one is self-explanatory and may mean more or less to your organization depending on your situation.  By involving the business side, IT is naturally exposed to less criticism.  Also, other teams can investigate best practices and conduct research (as well as writing out the standards, etc).  In addition, the extra involvement will improve the buy-in on tool decisions.  

Less Costly Mistakes or "Do-Overs"

Standards or requirements created without non-IS input can easily create situations where implementation meets significant enough resistance that work has to be redone.  For example, if we take the example of “friendly urls,” if a decision is made for client side rewriting, then it may be even more expensive to change than the initial expense of doing it that way.

Other Business Process Implications

Technology is never implemented in a vacuum, so the business process implications must be considered.  For a CMS, this can impact the training, editorial standards, documentation, and implementation details.  Examples include:

• Taxonomy management and information architecture. It's easy to underestimate the impact that simple template changes or the lack of ability of systems to manage a hierarchical taxonomy can have.  The impact to the publishing process, editorial standards, and training must be considered.  
• SEO and the content itself.  To achieve some tool standards, business users may be required to follow certain standards and write their content for SEO. 

Note that this is also an attitude, since obviously it could be argued that the above could be accomplished by the IT group just going to the other teams to gather requirements.  We would suggest taking a more "operational" approach where there is ongoing development and ongoing optimization, as well as improved transparency and buy-in (thanks to Lisa for raising this point).  

For better prioritization, perspective, and efficiency, include your non-technical stakeholders in standards and requirements teams.