Like any new technology implementation, deploying an enterprise workplace app involves many moving parts, potential issues, and challenges. Nailing your implementation and deployment is key to avoiding wasted time and resources.
To understand how to master implementing and deploying a workplace app project, we invited workplace strategist and digital transformation expert Gabrielle Fink and Modo’s VP of Client Services Mark Howden to share their insights and approach.
Highlights from the webinar include:
- Top user experience considerations
The user experience is the most important aspect of building a workplace app. If users don’t like the app, they aren’t going to use it, plain and simple. Therefore, you want to ensure:
- Your app looks good and is designed for mobile. You may be building a technology for the enterprise, but your app needs to deliver a consumer experience.
- Initial core functionality is kept to a minimum. You may want to include everything, but it’s just not realistic. It’s better to start with four to five components and ensure they function well.
- Your app performs well and loads quickly. Significant testing before launching will be necessary. This is particularly important when your app includes multiple integrations – if the system you’re connecting to is slow, it will slow down your app. If your company operates in several countries, you must ensure your app performs well through the various server hops.
- Best practices for managing and mitigating risk
- Don’t short-change discovery. According to Fink, you should allocate 4-6 weeks (less if you have outside experts doing this step for you) on discovery. It’s important to capture a clear picture of the locations you want to support, your existing system architecture, the data you want to use, what security and privacy requirements you’ll need to address, etc.
Download Workplace App Pre Planning Checklist for more discovery items
- Consider your app objectives. Fink admits that 10-15 locations could have been removed from her app had she learned more beforehand, e.g., some sites were small call centers, and another was just two floors of a building. The same applies to the first phase of functionality being considered. Will those features meet your stakeholders’ objectives and bring value to your employees?
- Be certain you have funding. And make sure everyone is clear on how funds will be managed.
- Don’t turn down a proof-of-concept (PoC) offer. A PoC helps with your planning and delivery methodology. It allows your team to flush out architecture issues, particularly security, a top concern for Fink’s financial services client.
- Elements to handle change management
- Have clear project governance. Establish rules and procedures for making project decisions (how changes will be approved or rejected).
- Have a change control board. Your project stakeholders should have the final say on any changes because, at the end of the day, change costs money. However, Fink has found that a change board only works well with an orderly plan.
- Ensure your plan and your vendors’ plans are aligned. For example, if your app includes a feature that relies on a new capability your vendor is building, will that capability be ready and fully tested in time for your build?
- Tips for a realistic and achievable implementation
- Include a PoC. A PoC helps you understand what your deployment might look like, e.g., how long does it take me to build out one location? You can then take your timeline, budget, and availability of resources and determine fairly accurately what is achievable.
- Know your team. Do you have the right technical skills to execute? Do your operations and support teams have the right skills, and have you trained them on the app and the platform?
- Test, test, test. Conduct performance and user testing to ensure the app will meet end-user expectations.
- Get sign-off before launch. Fink shared that she got sign-off on her delivery plan before launch to ensure everyone knew what was expected of them and what was being deployed to eliminate last-minute issues.
- Internal team members to run the app going forward
- Support. If you, as a company, will run your app, you need a service team to handle basic user questions and a technical team to address bigger issues. This technical team should also be able to build new functionality into the app but know when to hand it off to the vendor.
- Ownership. You need someone who owns the app (product manager/owner). This person will work with stakeholders to capture feedback and new functionality they want.
- Content. Finally, you’ll need content/operations leads to ensure the app stays on brand and looks good. They must build content to keep the app up-to-date and useful to employees.
- Common pitfalls to be aware of and avoid
- Don’t make assumptions about what software versions you have in place. You must flush out this level of detail during architecture discovery if you plan to integrate those systems into your app.
- Understand your data feeds. Are there any customer modifications/ manual tweaks in place that will complicate a third-party app integration? For older organizations, this is highly likely. The earlier you learn of complexities, the more time you have to figure out how to work them out.
- Assemble the right stakeholders from the beginning. They will help you get the budget, champion the project, and provide assistance when faced with internal challenges.
- Get cybersecurity right from the start. Make friends with your security team early on to understand all the requirements, regulations, and roadblocks you must address.
- How to avoid scope creep
- You want to encourage feedback, but once you’ve defined your vision and initial development plan, being bombarded with “we should add this” conversations is not helpful. Fink has found “it’s not what you say, but how you say it” works best. She suggests explaining to stakeholders that what has been defined for the initial launch aligns with the delivery objectives, budget, and timeline and that after deployment on date X, you will want their ideas for the next version.
- Key considerations when integrating with existing systems
- Know which versions you operate on. Never assume you’re on the latest version.
- Understand your contractual relationships with third parties. In particular, if service and support extend to your integration.
- Be aware of internal politics. Who inside your organization has a relationship with a vendor?
- Know when upgrades are planned. You may need to adjust your delivery plan around those upgrades to eliminate any issues.
- Test performance. If the performance of existing systems requested for integration is slow, it will continue to be slow within the app.
- Best practices to drive initial adoption and engagement
- Design your app with the end user in mind. Remember, it’s about improving their lives.
- Make it easy to download the app. Consider using QR codes.
- Get the word out about your app. Use traditional marketing tactics and get your team involved. Have them walk around the office, show people the app, and help them download and use it.
- Monitor your app data. Identify who is using the app and if there are any issues.
- Strategies to ensure your app evolves
- Keep the app fresh. You must continually improve the app and add new functionality to make it useful and fun.
- Have a product manager/product owner. This person will own the app and be responsible for its growth. They will also share performance metrics with stakeholders to maintain support and get additional budget.
- Have people build relevant and timely content. HR, facilities, marketing, and talent are key departments that must be involved in the app’s success.
- Force people to use it. If your app includes digital IDs, get rid of plastic badges.
Watch the full webinar on-demand: Tips from the Experts: Mastering Workplace App Implementation and Deployment Practices.