Feature
I’m in the middle of a series on how to build and deploy successful SharePoint document management applications, with the goal of migrating end-users off of the most prevalent legacy document management system out there: that unholy trinity of shared drives, hard drives and email.
In this post, we’ll dive deeper into system design and testing, one of the most exciting parts of the process.
In the last two posts I’ve been walking through a process that, while by no means a silver bullet, in my experience will give you a better chance of success than the typical approaches, e.g., if you build it, they will come.
- Process mapping
- Process triage
- Process redesign
- Capabilities mapping
- System design and testing
- Migration planning
- Communication and training
- Go live
We’ve covered steps one through four in the first two posts, and that’s the place to start if you haven’t already done so.
#5. System Design and Testing
The most important thing to take away about system design and testing for a shared drive migration to SharePoint is that the typical waterfall SDLC approach is less than optimal. A better approach, and one that I’ve used very successfully, is the rapid application development (RAD) approach. Here’s how it works...
Rather than serially executing the steps in the software development lifecycle, i.e., requirements gathering, system design, system development, testing and go live, you run requirements gathering, system design and development, and testing concurrently in order to speed up the development cycle and reduce overhead (documentation, handoffs, project management).
There’s lots of great stuff out there written about RAD (or RAD-like methods) for software development, so I won’t try to replicate that here. But I can give a quick overview of what the kind of RAD sessions I’m thinking of look like.
Basically, you’ll have SharePoint technical resources, end-users, infrastructure stakeholders, business analysts and quality/testing resources in the room. You’ll begin by articulating the business requirements for the solution, i.e., letting the end-users talk about what business activities that shared drives, email and hard drives currently support.
You want to make sure you don’t jump right into solutioning (getting too technical too soon can squelch the discussion of user needs/requirements), but at a certain point, you want the BAs, quality folks and technical resources to start contributing ideas about how SharePoint can address the areas the end-users have identified as important.
Once it becomes clear that you’ve gotten the lion’s share of the requirements and the discussion has shifted to system design, you’ll want to have the SharePoint technical folks plug a laptop into the projector and begin mocking up functionality directly in SharePoint, so that everyone can see the solution as it emerges.
Learning Opportunities
Webinar
Jun
6
The Future of Social Media: Emerging Trends and How to Stay Ahead of the Curve
The impact of emerging technologies like AI on social media
Webinar
Jun
7
The Building Blocks of Personalization
This webinar will explore how personalization can create powerful ecommerce shopping experience.
Webinar
Jun
8
Attracting—and Keeping—Your High-Net-Worth Investors
Join PwC to dissect their recent survey findings on a specific customer subset — high-net-worth investors.
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
Jun
13
Learn How to Deliver Dynamic Video Experiences at Scale
Learn how to convert existing assets into video experiences in near real-time.
Webinar
Jun
20
3 Steps to Unlock Your Customer Data and Drive Revenue
Discover how Twilio Segment’s #1 Customer Data Platform helps implement data-driven strategies.
Of course, you won’t be able to do all the system design in this forum. But consider this a prototyping exercise using SharePoint itself rather than a whiteboard or wireframes. The goal is to get a rough mock-up of a SharePoint site that is moving in the right direction to meet you users’ needs. The goal is not to get a fully functioning SharePoint application up and running -- that’s going to happen between sessions as the technical folks go back to the lab and, using what they learned in the session(s), build out a true SharePoint site.
Over the course of a number of sessions, here’s what the progression typically looks like:
- Session 1: develop first pass at user requirements; begin sketching first prototype
- Session 2: finalize user requirements; complete first prototype
- Session 3: complete second prototype; finalize test plan
- Session 4 - Session 5, etc.: continue revving and refining prototypes
It’s important to note that you won’t always need this many sessions. I’ve facilitated RAD sessions where we got to a good enough prototype after the second session that we were able to finalize and go live with only asynchronous collaboration on the emerging SharePoint application. I’ve also facilitated RAD efforts that required many, many sessions to reach that point.
How things shake out in any given case are going to depend on the complexity of the user requirements, your skill as facilitator, the personalities of the participants, the culture of the organization and dumb luck. Bottom line: be ready for anything and stay flexible.
The Final Word
Honestly, most SharePoint efforts move right from this step to go live -- who needs migration planning, training and communication? Copy everything over to SharePoint, or move nothing, or let users decide, and send them links to online training and call it a day, right? Wrong. The road to SharePoint success is littered with failed efforts that failed in large part because folks didn’t pay enough attention to these two steps…so we won’t make that mistake here!
In the meantime, I’d love to hear your thoughts on the process I’ve sketched out so far, your experiences with SharePoint development, or your own thoughts on how to get SharePoint right -- jump in, and let’s get the conversation started.
Editor's Note: You may also be interested in reading:
