Communication Management Portal
A SharePoint product development project to design a streamlined communication and document exchange portal.
EXECUTIVE SUMMARY
MFC is a financial firm employing more than 2,000 investment and support professionals. They wanted to simplify the process for all internal formal business and investment requests. I designed a solution for them with a SharePoint application to manage all incoming and outgoing department-to-department communication.
The portal is a SharePoint-based app for use by the numerous business support and investment teams. The platform enables them to send official communication from one department to another in a searchable and streamlined manner.
Benefits
The portal simplifies what was a manual process of formal communication. The new app provides users with an end-to-end electronic process to both communicate and store important intra-departmental investment and legal requests across the organization.
This new electronic process also enhances visibility for senior leadership on their department communication because they no longer rely on an administrator to gain access to the communication records. Business support teams and all relevant stakeholders have a real-time view of the communication, action owners, and status. It is a repository for all documentation which can be accessed through a search function.
THE PROBLEM
Many departments asked IT to be onboarded to the existing tool which was planned for decommissioning, or for a department-specific application, in order to simplify the process and reduce the amount of time spent on managing department-to-department communication.
Some departments were using a custom-made Oracle tool while others used manual methods to track formal communication (Excel, Outlook, and hardbound notebooks). Formal communication encompasses requests and documents related to legal, due diligence, settlements, payments, financial reports, contracts, employee information, etc. Many of these documents are business critical documents, requiring follow-up and action.
As part of a firm-wide document management project, the Oracle tool will be commissioned in 2019 and SharePoint will be our document management platform. MFC management maintained that a SharePoint application should be developed to respond to business support needs and enable process standardization across all departments.
KEY GOAL
A SharePoint application should be developed to respond to business support needs and enable process standardization across all departments.
- MFC Management
MY ROLE
I was responsible for all aspects of the project, from requirements gathering, experience and visual design, testing, and training.
I was the project owner, product designer, and business analyst for this project, working closely with the SharePoint team for support. I collaborated with stakeholders across all departments to lead workshops, conduct both individual and team interviews, manage the scope, collect feedback, facilitate testing, and provide training.
UNDERSTANDING THE USER
Primary users were business support teams across 20 departments and were my touch points throughout the project.
Business Support Teams
Primary User
Act as main contact for each department's executive office and facilitate firm-wide communication.
Management
Secondary User
Need a big picture view of incoming/outgoing requests to hold their team accountable when there are action items assigned.
Action Owners
Secondary User
Assigned as action owners and responsible for executing and closing the request on time.
6-MONTH PROJECT TIMELINE
BREAKING DOWN THE PROCESS
MONTH 1 | UNDERSTAND
To understand how employees managed their communication processes, I planned and conducted user research interviews, analysis of existing workflows, and held cross-department workshops.
Insight
Initial workshops were too big, impacting the quality of input.
Solution: I split the group into three and met with departments individually to address specific concerns.
Because I was solely responsible for this project, these meetings covered ⅔ of the business departments which I felt was enough to get the right level of research detail. During these meetings, I observed how different departments managed their communication (record, store, follow up, action, and reply), understand their pain points, and enabled them to articulate why they performed certain activities, despite the questionable value add.
While some users were excited about the idea of simplifying their process, others were apprehensive something developed by IT would be clunky, difficult to learn, and complicate their process.
I found that although each department managed their communication slightly differently, the variations could be attributed to:
-
Legacy department practices
-
Personal habits
-
Distrust in technology
Causes of Process Waste
Approvals
Excessive internal approvals before a document could be sent
Duplication
Duplication of record-keeping by documenting metadata in multiple locations
Cross-Departmental
Communication
Lack of communication between business support teams across the business
Internal
Communication
Lack of communication between business support teams and their internal stakeholders
Users acknowledged these issues and the burden it placed on their process. Although they were open to improvement, they were scared of the change it would bring. While some could easily see the value of automation and the time and effort that would be saved in their daily activities, others saw that as a threat to their role.
MONTH 2-3 | PRODUCT DESIGN
Next, I designed an MVP to demonstrate how departments could more easily request and share documents. Stakeholder feedback revealed complexities in the workflow and this lead to crucial improvements to the MVP.
MVP
Design Principles
Clean
Minimalist
Easy to learn
The first version of the MVP was aimed at showing the following flow:
-
Department A sends a request to Department B
-
Department B reviews and assigns an Action Owner to that request
-
Action Owner completes the request and replies back to Department
Standard User Flow
Stakeholder Concerns
Root Cause Analysis
-
What if the recipient wanted to distribute the request internally before replying?
-
What if the Action Owner did not reply back using the tool?
-
What if no action is required?
-
What if additional approvals were required before sending?
After several meetings, I discovered the root cause for these questions was based on internal workflows which could not be standardized:
-
Some departments hold Business Support teams accountable for replying back on action items.
-
Some departments hold Action Owners accountable for replying back to action items.
-
Some departments follow both standards, depending on the request type.
-
Some requests require confirmation from management before replying and can take more than a day.
The Reply/Action form went through several iterations to support process complexities.
MONTH 4-5 | TESTING
When the product was built, I planned and facilitated usability testing with 75 employees including department admins and team. Testing validated many of the design decisions and revealed some small fixes to improve ease of use.
I chose testers who had provided the most input into the design of the tool and had a good understanding of their current process and business needs. I also gave all departments access to the test site so they could practice using the tool and align their current processes.
Users were happy with the overall design of the tool, especially the Incoming and Outgoing dashboard which showed all essential metadata, and the Status page, which gave the information they needed to follow up on requests - information they did not have have quick access to with their manual process.
Feedback was mainly focused on three areas:
Advanced Search
Before
Users struggled with the search feature. It did not yield results as expected when entering the search criteria. Initially I thought this was a problem with the actual search function, but after following up with the SharePoint developer, we concluded it was a UI issue.
After
Instead of having fields for all metadata, I simplified the search page to a single search box with the option to add and remove selected filters.
Language
Before
The majority of my users are not native English speakers. Therefore, some of the form fields, labels, and navigation, were not intuitive. Some of the icons did not have labels and users interpreted them differently.
After
I changed some of the language to be as explicit as possible, added labels to icons, and included tooltips.
Notifications
Before
Despite my advice that too many notifications would get lost in email inboxes, users wanted to receive one at every stage in the workflow. Every time an action is taken on the tool, they wanted an email notification.
After
I received complaints about too many notifications but the opinion is split across various departments so I have not made any changes. I advised those who do not like them to set up Outlook mailbox rules to reroute those emails.
After the communication tool launched company wide, it was clear that full adoption was going to require more than a standard training session. I coordinated with business support leads and created customized training based on their unique workflows.
I'm a paragraph. Click here to add your own text and edit me. It's easy.
All departments went live at the same time. The users that provided the most input since the beginning were much quicker to adopt the tool and had laid the groundwork for their stakeholder adoption. Others never communicated with their stakeholders and thus were met with more resistance. I had to provide more individualized training over the upcoming months and in some cases, management stepped in to manage the roll-out within their department. I encouraged everyone to report defects and provide continuous feedback so we could capture a list of future requirements.
MONTH 6 | GO-LIVE
TITLE OF THE CALLOUT BLOCK
OUTCOMES & LESSONS LEARNED
With more than 40% of man effort saved, the successful implementation served as a launching pad for a project to automate the process for departments to make submissions to MFC committee’s using SharePoint.
After the initial launch in June 2018, I reached out to the business again to collect feedback and observe them using the tool to better understand where enhancements could be made. Users gradually began to build trust and confidence in the tool and in November 2018, a second release was deployed.
The success of this tool was also the launch of another project to build a tool for the company committee and working groups. A new project to automate the submission process is underway so going forward all of MFC’s formal documents and requests will be made using SharePoint.
Users are saving more than 40% of effort now that all send/receive, follow up, tracking, storage, and reporting of communication is automated.
Business Support teams can now focus on adding value to the business without the burden of manual processes.