While a lot changes in business, one thing stays consistent: the imperative to serve customers and employees, and to grow your business.

One of the ways to meet that imperative—in the face of never-ending digital disruption—is to strategize with people like those of us from Zia Consulting. We strive to bring together the best solutions for all those diverse, disruptive experiences across verticals. Whether it’s insurance, mortgage and banking, corporate legal, manufacturing, high-tech, or something else, we’ve had lots of conversations with recurring themes. Zia Consulting uses a modified Agile implementation methodology anchored by three key principles and grounded by milestones.

This is the final article of a five-part series on technology strategy techniques that bring about lasting change. In case you missed it, check out the ECM Strategy for Lasting Change series.

The first principle is an overarching set of solid best practices. From talent selection and staffing to development practices and deployment techniques, each area of the project should have a set of operating guidelines. For example, at Zia, we use requirements gathering standards of practice, specific code development and delivery methodologies, and agreed upon communication mechanisms and toolsets. We leverage models and techniques across disciplines, grounded in the standards developed by the Project Management Institute (PMI).

Vision Sharing

Vision sharing sets the stage for any project or program. During initial vision sharing, a focused, timebound discovery phase establishes the goals, sets success criteria, and assembles the right team. Underlying business and technical pain points are uncovered and documented. This activity sets the stage for project success and user adoption based on a shared view of the future.

 Plan, Do, Test, Do-again

After discovery, we adopt a “plan, do, test, and do-again” cadence. Planning is based on milestones set from priorities. It’s important to begin implementing the initially-scoped ideas while continuing to tackle the unknowns that were stumbled upon during discovery. In addition to delivering functionality, each iteration contains demo, testing, and feedback loops, allowing the team to adjust and respond to key feedback. Each cycle is short and involves early adopters. This allows for adjustments to be made along the way with less impact on the overall timelines. In other words, the process should keep the team from iterating too much without involving the right groups to weigh in, lest you find that you’re addressing the wrong pain points or (worse!) introducing new ones too far into the development process.

Best Practice Framework

The third principle is an overarching set of solid best practices. From talent selection and staffing to development practices and deployment techniques, each area of the project should have a set of operating guidelines. For example, at Zia, we use requirements gathering standards of practice, specific code development and delivery methodologies, and agreed upon communication mechanisms and toolsets.

For milestones that are foundational for success, we focus on the end to end pieces of setting the stage and development while pulling in the items we believe will drive successful adoption. While this diagram reads left to right, and looks linear, many of these steps are iterative and, from a timing perspective, one milestone can begin before another one is completed. We have found these components to be core to any technical project, especially those involving business process changes.

Setting the stage includes agreeing upon a foundation and framing the project within the landscape of the entire enterprise. Initial planning includes validating the team’s readiness to begin the project. There are going to be challenges ahead! The first plan needs to serve as a roadmap to getting through (and around) those challenges. In a previous post, I outlined the importance of gaining a clear picture of the Why, the Who, and the How of your project. 


Strategy Desk Tip:

ECM projects are complex technical undertakings. Therefore, setting standards for the development methodology and deployment early saves confusion and wasted cycles once sprint deliverables are ready. Is the hardware specified and procured? Are members of supporting staff like DBAs, network and storage engineers, and identity/security representatives committed to the project? Is there a release and deployment manager, responsible for the planning, design, build, configuration and testing of all software involved? As with other aspects of ECM projects, deployment design is as much an art as it is a science and each of our clients have specific procedures and processes. 

Our next milestone, frame the house, represents how the ECM relates to and integrates with other systems and related projects within the enterprise. Whether mapping out a system integration or simply proving out a unique and new business process for the end user, here’s where we establish the ECM project’s role in the enterprise and understand its impacts to other related systems. Enterprise integration doesn’t just mean system, data, and metadata synchronization; it also requires process-based changes. Framing the house stage may include a proof of concept to quickly validate the to-be system and processes.

Everyone is on the same page now and ready to build the solution. The development milestones tackle the digital transformation, providing new features to support business processes, system integrations, and data intelligence. New features are developed with a minimum viable product (MVP) strategy. MVP is a development technique which provides sufficient features to satisfy early adopters. The final, complete set of features is further designed and developed after considering the feedback from the product’s initial users.

Strategy Desk Tip:

Integration of the ECM with other line of business systems can bring significant value, and not necessarily where you expect! Integrations may be viewed as complex and costly, but we uncover the best technical options and discuss how to gain the most business value from an integration. For more tips on justifying costs and measuring success, refer back to another article on that exact subject. 

Something oftentimes overlooked is the need for reporting, data analytics, and business intelligence from the ECM data. We have learned from implementing content centric projects that the requirements for data intelligence are often only discovered as the project continues. As users start to see information in the system, they discover new ways of leveraging that information. As consultants, we always ask questions about how data points need to be pulled together. Additionally, for reporting and analytics, the requirements are simply not as well defined, even once users start to understand what they want. The specifics of finding and navigating data and how it is to be governed in the data lake are typically not clear ahead of time.

No project is successful without user adoption. That is why throughout the lifecycle—even as far back as the setting the stage timeframe—we take steps to maximize engagement from users. We talk to users, involving them in workshops, showing in-progress to-be diagrams and demos, and getting them involved in testing as the project progresses. The green line on the diagram above shows that managing the shared vision of the future starts weeks and months before new features are built, systems are integrated, or content is migrated.

This post marks the end of our ECM Strategy for Lasting Change series. For more context around conversations we’re having to drive enterprise transformation strategies, check out Mike Mahon’s overview of Zia’s 5 Ds of Digital Transformation. Here are a few additional resources:

Let’s chat about your organization’s strategic vision and challenges for content management and enterprise integration—not only to share our knowledge but also to learn from yours!

Pin It on Pinterest

Sharing is caring

Share this post with your friends!