Starting a SharePoint intranet project, whether creating a new intranet or redeveloping an existing one, can be daunting. Alongside strategy and design questions are now a myriad of technology decisions, often exploring uncharted territory within the organisation.
(Read more about SharePoint intranet project planning, and other best practices, in our new report, Best practices for SharePoint intranets.)
At a basic level, intranets based on SharePoint are just like every other intranet. The same questions of design, structure, management and governance arise, regardless of the technology used to publish the site.
As discussed in the earlier article Promoting the intranet as a service, the intranet should be considered a service, underpinned by a technology product.
SharePoint does, however, introduce some new questions into the intranet planning process. The greatest strength of SharePoint is its breadth of functionality, from content publishing and collaboration, to CRM and application development.
It is this wide range of capabilities that can be so daunting for many teams. Without a clear plan, the results can become a little bit of everything, but no one clear and compelling success.
This article outlines a best-practice methodology for planning SharePoint-based intranet projects. Drawing on the Intranet Roadmap™, it provides a step-by-step approach that every team can take.
The result is confidence from the outset that the project will deliver clear benefits, and an approach that brings together business needs and technology considerations.
Intranet projects on SharePoint need a clear direction
Challenges and opportunities
Intranet projects are not easy at the best of times. Often replacing sprawling legacy sites, they have to meet the needs of a diverse audience with a limited budget and constrained resources.
SharePoint intranets are just like any other technology platform in this respect. Independent of the underlying product, the new intranet needs to be usable for staff, valuable for the business, and easy for the intranet team to maintain.
SharePoint does introduce, however, some particular issues of its own, both positive and negative.
The opportunities presented by a SharePoint intranet include:
- Valuable new functionality, especially in the areas of team-based collaboration and simple document management.
- Wide capabilities that expand the intranet beyond mere content publishing.
- More opportunities for integration between business systems, in both the front and back ends.
SharePoint projects are not, however, without their challenges, including:
- Comparatively complex platform that needs many technology decisions to be made up front.
- Danger that projects become technology-driven, rather than business-focused.
- Requirement for customisation and development, which can either deliver great benefits or waste money.
- Breadth of functionality that can make it hard to determine a clear project scope.
- Significant resource requirements.
Project planning methodology
Like every project, success is assured by having a strong plan from the outset. This is doubly true for a technology platform such as SharePoint, which offers such a daunting range of possibilities.
The Intranet Roadmap™ provides a firm foundation for this project planning, as it outlines all of the activities needed for a design or redesign project. A SharePoint intranet is just a variation on the approach that works for every project.
(For more on the Intranet Roadmap: www.steptwo.com.au/products/roadmap)
The key difference from a typical approach is that the technology platform is chosen at the outset of the project. This can be turned into an advantage, allowing the scope and design to be developed with a deep understanding of what the technology has to offer.
An effective project methodology then emerges as follows:
- understand business and staff needs
- confirm ownership and overall governance
- determine strategy and scope
- select functionality
- design the intranet
- develop a technology specification
- implement the intranet
- migrate content
- establish operational governance
These steps are listed in the diagram to the right, and are explored in the following sections.
1. Understand business and staff needs
An intranet will be used if it’s useful. This seems a simple observation, but it can’t be taken for granted. The starting point for any intranet project must therefore be to clearly understand business and staff needs.
As discussed in the earlier article Conducting intranet needs analysis, it is important not to fall into the trap of ‘asking staff what they want’.
With SharePoint introducing new capabilities and functionality, staff will be unfamiliar with the possibilities on offer. This type of questioning also falls into the trap of focusing on the technology, instead of the business needs.
The best approach is to explore how the business operates, and what problems staff encounter on a day-to-day basis.
A range of techniques can be used to uncover this information, including:
- one-on-one interviews
- focus groups
- workplace observation
- contextual inquiry
Avoid broad-brush approaches such as surveys, as these won’t uncover the depth of information needed to make the many design and technology decisions that will arise during the project.
By the end of this first phase of work, there will be a clear understanding of business and staff needs that will drive every aspect of the planning and implementation.
2. Confirm ownership and overall governance
SharePoint can easily start as technology projects within IT, and can even grow organically out of initial pilots.
Before progressing too far into the project, it is important to clarify the overall ownership and governance of both the project and the intranet as a whole.
IT will almost always be a key player in a SharePoint intranet project, due to the technology-heavy nature of the platform. In many cases, however, they won’t be the ‘business owner’.
This ownership may be held by a single group, such as communications or knowledge management, or be shared within a committee or other similar governance group.
Whatever the model, it must be clear how key strategic decisions are made, where the budget is being provided from, and where the intranet sits in the organisation.
3. Determine strategy and scope
The five fundamental purposes of an intranet can be used as a set of ‘sliders’ to help determine the overall focus of both the intranet and the SharePoint project.
Going into an intranet project, it is often unclear what role the intranet should be playing within the organisation. Beyond ‘having an intranet’, many organisations struggle to articulate overall intranet strategy.
While there needs to be clarity around intranet purpose and role in every situation, this is particularly vital for SharePoint intranets.
The breadth of SharePoint functionality opens the possibility for the intranet to play a much more significant role within an organisation. It can also, however, make it hard to work out exactly which direction to take.
Questions often include:
- What collaboration features should we be using?
- Is SharePoint a publishing platform or a document management tool?
- Should the focus be on SharePoint as an application development platform?
- What third-party functionality should we be deploying?
To answer these questions, it can be useful to go back to the fundamental purposes of the intranet. These are described in the book What every intranet team should know, and since expanded to these five purposes:
- Content:a repository for both corporate and business unit information.
- Communication:a communications channel out to most or all staff.
- Collaboration:a range of collaboration and social features, for teams, projects and communities.
- Culture:a reflection of the current organisational culture, and a support for culture change.
- Activity: a ‘place for doing things’ rather than just reading things, focusing on business processes and task completion.
As shown in the diagram earlier, these can be used as ‘sliders’ to help build consensus amongst stakeholders about the focus of the intranet.
From this, the broad scope of the project can be determined. For example, the focus may be on improving content and communication, the fundamentals of most intranets.
Or perhaps content has already been well-addressed, and the goal is now to deliver rich collaboration and ‘enterprise 2.0’ functionality.
Ensure that both the strategy and scope for the intranet are aligned with the nature and activities of the organisation. (What works for an engineering firm won’t match the needs of a hospital, or a consumer goods company.)
4. Select functionality
Once the overall strategy and scope for the intranet is determined, the project can then start to look at the practical details of what will be delivered.
SharePoint natively provides hundreds of different features and capabilities. Not all of these are appropriate or needed for a given organisation or project.
Beyond this, there is a growing ecosystem of third-party products and extensions that provide additional capabilities, or address out-of-the-box SharePoint weaknesses.
Many other products ‘integrate’ with SharePoint in a range of ways, further blurring the line between the intranet and other information and IT systems.
A hundred questions will need to be answered by the project team, such as:
- Will user-driven personalisation be implemented, and to what extent?
- Is there a need for multilingual content?
- What integration will be established to desktop tools, including Office?
- Which of the many collaboration features will be used?
- Will SharePoint replace network drives?
- What online forms will be automated?
These are just a few of the possible questions, and the IT team responsible for deploying SharePoint will want to know the answers as early as possible to help them scope their efforts.
To answer these questions, go back to the five purposes determined in the previous section, and use these to guide individual decisions. The figure on the following page shows what this might look like.
For example, if the focus is on content, then required features may include targeting information to specific business units, simple document management, and strong search. More complex features, such as full records management may be deemed out of scope for the initial project.
Conversely, a focus on collaboration would put the emphasis on teamsites, personalised homepages, and social tools.
These decisions about functionality will guide the design process outlined in the next section, allowing the designers to focus on delivering the required capabilities in the best possible way.
The five purposes can be used to help select which functionality will be enabled, whether built into SharePoint or provided by third-party tools.
5. Design the intranet
It is easy to create an intranet that makes perfect sense to the designers and developers of the site, but much harder to produce something that is easy to use for all staff.
As the functionality and complexity of the intranet grows, it becomes even more challenging to deliver a usable intranet.
The answer is to involve staff throughout the project, following a ‘user-centred design’ process. This is described in considerable detail in the book Designing intranets: creating sites that work.
This best-practice approach provides a toolkit of practical techniques that can be used with staff, including:
- personas
- card sorting
- tree testing
- usability testing
The result of this process is a set of designs that can be implemented in SharePoint. These are typically documented in the form of a site map and wireframes (page layouts without design or colour).
While the user-centred design process is the same for every intranet technology in broad terms, it must be done with an understanding of the specific capabilities of SharePoint.
As with every technology, some approaches ‘go with the grain’ of the product, and some are harder to deploy.
The design process must therefore consider:
- key features and functionality on offer
- ‘best practice’ approaches from a technology perspective
- platform strengths and weaknesses
- the amount of customisation and development required to deliver desired designs
If obtaining third-party help with the intranet design, ensure that they have sufficient SharePoint knowledge to deliver something that maximises the strengths of the platform.
For more on designing intranets: www.steptwo.com.au/products/designing-intranets
6. Develop a technology specification
This is where all the detailed technology decisions are made, based on the required functionality and design.
As a technology-heavy platform, SharePoint needs to be carefully established to ensure that it’s manageable and scalable. Organisations typically seek external assistance from a specialist SharePoint implementer at this point, to obtain the required depth of knowledge.
Choose the implementer carefully, as one of the challenges of SharePoint is that all the architectural decisions need to be made at the outset, before the first server is deployed. There is limited opportunity later in the life of the platform to rework or revise the architecture.
Use the insights gained earlier in the project to develop a thorough technology specification, covering:
- overall platform and server architecture
- configuration of SharePoint functionality
- required customisation and development
- data models, content types and lists
- integration of third-party plug-ins and tools
A clear and well-thought-through specification ensures that deployment and development work will proceed with minimum surprises. Like any technology project, jumping straight into development without a plan is a recipe for disaster.
7. Implement the intranet
In every intranet project, there are many individual aspects which need to be covered during implementation. These include:
- establishing the technology platform
- configuring the software and tools
- implementing the desired site structure (information architecture)
- establishing metadata, content types and lists
- implementing desired page layouts and templates
- implementing the visual design, including creating HTML and CSS (if not done earlier in the project)
- load testing and user acceptance testing
- training for site administrators and authors
Depending on the complexity of the organisation and the project, all of this may be as simple as using SharePoint largely ‘out of the box’, and doing a few weeks more work.
At the larger end, deploying SharePoint may involve months of technical work, and the same again to cover the non-technology aspects.
Bring in sufficient SharePoint expertise to ensure this phase progresses smoothly, but don’t forget that the goal is to deliver a great intranet, not just to deploy SharePoint.
Ultimately the project will be judged a success if the new intranet is clearly valuable for staff and the organisation. Behind-the-scenes work done on the technology platform will win little recognition.
8. Migrate content
One of the goals of many intranet projects is to deliver better content to staff, particularly when an existing, legacy intranet is being replaced.
This makes migrating (or creating) content a critical part of the overall project. As discussed in the earlier article Content migration: options and strategies, there are three broad possibilities:
- automated migration
- migration by hand
- partially automated migration
If upgrading from an earlier SharePoint version, automated migration may be a possibility, particularly if content was previously well managed.
Most projects, however, will end up conducting some form of manual migration. This should be conducted by the content owners themselves, supported by clear guidelines and standards.
Ensure that enough time is set aside for this in the project plan.
9. Establish operational governance
Intranets don’t run themselves. Even when a usable and powerful intranet is delivered, this effort will be for nothing if it immediately starts to slide into disrepair.
The ongoing management and governance of intranets is therefore critical. This includes establishing:
- an ongoing central team to manage the high-level aspects of the site
- standards and guidelines
- training for content authors and owners
- decision-making processes for intranet changes and improvements
- ongoing reviews and enhancements
- ongoing promotion and visibility raising
- change management and adoption activities
For more on this, see the earlier article Creating an intranet governance guide, which provides a framework for establishing suitable governance.
Most of all, don’t fall into the trap of building a solution and then ‘handing it over to the business’. If the business areas and staff who will be ultimately responsible for intranet aren’t involved throughout the project, it will be difficult or impossible to do this handover.
Instead, consider at the outset of the project the governance and resources that will be put in place for the long-term. This will help to guide decisions about strategy, functionality and design.
Also recognise that deploying new and unfamiliar functionality will also require significant amounts of change management and communication, if adoption is to be assured. This is particularly the case for functionality that requires the active participation of staff, such as personalisation or collaboration.
Conclusion
In many ways, delivering a SharePoint intranet is just like every other intranet project. The overall goal remains to deliver a site that is easy for staff to use, and valuable for the business.
Take a measured approach to the project, and start by building a strong understanding of business and staff needs. Use this insight to determine the overall strategy and scope.
This drives the selection of specific SharePoint functionality, and underpins a user-centred design process that produces a usable and effective design.
With this in hand, the project can proceed to the technology aspects, first developing a specification and plan, and then implementing the platform.
Ongoing governance and support ensures that all of this effort isn’t wasted, with ongoing improvements steadily adding value to the site that has been launched.
Related posts:
The post Planning your SharePoint intranet project appeared first on Step Two.