In my last article I explained how important BA-like requirements gathering is to any serious UX Design effort. An experienced enterprise Information Architect is often the best person to facilitate these requirements gathering efforts.
The upshot of good user eXperience Design is that spending a little more time and money in advance on planning the site structure and user experience save a lot of headaches and re-work during development later on. This is especially true of internal corporate communications and collaboration vehicles that tend to grow in a viral and sprawling fashion.
While it's true that pro-active governance planning is mission critical, it is equally critical to have a scalable Information Architecture plan. Governing bodies typically consist of two halves - a Strategic/Executive Steering committee and an IT Operations committee, and it is important that each independent body achieve 'reach-back' by placing a few key players as overlap members serving on both committees.
Most players in this endeavor understand that Effective Governance is clearly concerned with establishing rules and behavioral guidelines via related acceptable use policies and providing infrastructure related best practices around storage quotas, back-up procedures, records retention and archiving policies
Enforcing these standards is a more difficult task than simply creating the governance plan. How will those responsible for executive decisions on the strategic business committee know what site structure standards they are supposed to uphold? They must have a handy reference guide to weigh proposed changes and upcoming development efforts against! This source of this reference guide is your Information Architect or eXperience Design team and the name for those metrics against which future changes are evaluated against include xD documentation such as Sitemap, Taxonomy, and Metadata Mgmt. plan.
Let's say you have planned for a standard 6-8 week portal stand-up project where build itself takes up a good 4 weeks +/- of that initial effort within the SDLC's Work Breakdown Structure. Maybe it's not that simple. In my experience spending a good 4-6 weeks of user eXperience Design planning ahead of the actual development curve will save time and prevent the project from getting derailed. It's not enough to simply write down a list of items that the business wants enables in this phase of development, it's very important to translate those 'asks' from a dictated list of the 'what' into an actionable business case visualization describing 'how' the business' needs will be met. This means a solid period of assessment, definition, and validation prior to design.
The key take-away here is that as software designers we would be wrong to jump right into design discussions without first answering the question 'what problem are we trying to solve here?' If You give our eXperience Design team a fair amount of time to document business goals, user requirements, and functional requirements then we will provide you with a set of design planning artifacts that serve to keep all stakeholders (including both Business SMEs and Development resources) on the same page throughout the course of the development project. Also bear in mind that once these data model requirements have been validated on a global level, more detailed functional requirements continue to be formulated at a granular level through iterative wireframes review and creative development sprints. The WBS for an effort of this type looks like a hybrid of waterfall and iterative SDLC models. Our xD process is neither the traditional BA / requisite pro documentation approach nor the more modern agile scrum model; in our most successful scenarios, it is a combination of the two that is uniquely tailored to the individual needs of Your company's business model.
We are not about process merely for the sake of process and prolonged development timelines; however, we cannot succeed when aggressively protracted timelines suggest that we achieve results in a handful of hours and half-days when the prep work that makes our success probable requires weeks rather than hours. There is a lot of face time involved. There will be UI Review meetings, heated discussions, those with religious opinions, and opposing points of view with regard to UI reviews and revisions. The beauty of engaging our xD resources is that we provide your internal teams with a lamplight leading out of that 'navigation hell' of indecision and dead-ends and into successful site structure model negotiation that leads to effective site template definition and inspired results in the proof of finished products.