User-Centered Design in Procured Software Implementations
Journal of Usability Studies, Volume 6, Issue 2, February 2011, pp. 60 - 74
Article Contents
The Final Push Toward a Distributed Implementation Model
Earlier it was stated that the SharePoint implementation team had hoped to eventually retire the role of SharePoint Liaison. It was also stated that there were versions of the Current Information Architecture Evaluation and New Site Hierarchy Documentation templates that could be used for self-service department migrations. Unfortunately, the SharePoint implementation team had not been successful in moving migration projects solely to the departments—there was something about these projects that seemed to require hands-on consulting work.
A year and a half after migration projects began (and after the SharePoint implementation team had solidified the process shown in Figure 7), it was time for the Development department to move to SharePoint. The Development department consists of over 40% of the company’s staff—engineers, quality engineers, documentation, product usability, etc.—and has teams of people dedicated to tooling and training for development-specific programs. We were pleased to have access to these resources to help with the Development migration effort.
A Development into SharePoint (DiSP) team—consisting of two program managers, a tools manager, a development university manager, and two members of the original SharePoint implementation team (including the author)—created a new plan. We created training and tooling around a slightly revised process and leveraged program managers who were already embedded in development teams. These program managers acted as SharePoint Liaisons, though everyone in Development would have more resources available to them, and therefore require less hands-on support.
This was a good idea in theory—in practice the Development department and the DiSP team struggled. Some likely contributing factors included the following:
- Executive management control of and disagreement about site hierarchies, driven by the fact that Development consists of 14 product groups and four business areas that operate differently (i.e., unclear vision and complexity). Additionally, there was little use of the existing document templates around evaluating existing information architectures or creating new site hierarchies (i.e., lack of skills).
- Program manager training and tooling being developed and refined at the same time many migration projects were already underway (i.e., unclear action plan and lack of skills).
- Possibly as a result of lack of or poorly developed technical and migration process skills for many program managers being asked to help their teams move into SharePoint.
- Little real-world, timely, hands-on SharePoint training that would have allowed program managers to understand the important features and trickier details of the platform.
- Fewer than expected users of the training and tooling provided by the DiSP team (i.e., lack of incentives and resources).
Should the SharePoint implementation team have encouraged the Development department to migrate to SharePoint following the original, more guided process, one product area at a time? In hindsight, some think so. Were the program managers just going through the typical learning pains of SharePoint later than we would have liked? It was possible. Was there not enough motivation or executive support behind the move to SharePoint? This was also a possibility. Or, were there simple tweaks that could have been made to reinvigorate the project? Only time will tell what changes the DiSP team makes, and how Development will complete their migration. But it is clear that change management issues continue to affect the progress and success of the SharePoint implementation.