Sergey Nivens - Fotolia
When people think Agile, they think about developers writing applications. However, Agile methods can be used to create real change in other areas of an organization -- including content management.
During the first decade of enterprise content management (ECM), organizations would build out massive applications on top of large software and hardware deployments. If requirements changed during this effort, the resulting application wouldn't meet the needs of the business when it finally went live.
By this time, the budget would be exhausted. Many organizations had to suffer through the imperfect system until they had the budget to try again.
The world changes faster every year, so this approach has become even more problematic. Agile content management can help organizations quickly gain real value from their content applications.
A constraint in traditional ECM was the need to build out the entire infrastructure. Systems were often difficult to scale on demand and frequently wouldn't scale without a complete rebuild.
With clouds and containers, ECM systems can start small and scale on demand. Instead of working for three to four months to make the core content systems operational, teams can have the framework for a content services platform ready in a few days.
This is not to say that the big picture can be ignored: A basic understanding of enterprise-wide content needs can keep you from painting yourself into a corner. Talking to diverse groups in the organization early in the process can lead to a foundational content model that is flexible and that can grow with the organization.
How to establish Agile content management
Use of cloud services or containers from the beginning opens the door for Agile content management. Regardless of the Agile methodology chosen, the approach is the same; iterative creation and deployment of content management features that meet the needs of the people it is designed to support. The steady cadence of updates and releases keeps the technologists and the business in sync.
Let's consider an internal effort to manage external correspondence. This is a pressing problem for government organizations. The first step could be to build an application for the primary office to digitize incoming correspondence. They could build an application that scans paper letters and manually collects emails, storing them in the content management system. Those items could then be routed to the appropriate group to create responses, and then on to the necessary approver.
Having routing digitized already adds value to the organization: correspondence is safely stored and searchable. It is a basic application, but it is a start. After the initial launch, the following features can be added:
- routing rules;
- templates to ensure that responses have a standard format;
- automatic capture of emails to remove the manual effort of capturing them in the system;
- reporting to better track the work being done; and
- integration with the HR system to pull frequently requested information into the content system automatically.
During these iterations, if HR wants to use the platform to store incoming resumes and offer letters, this could be done quickly using existing functions. It could then be expanded to create a hiring workflow that produces the data necessary to improve the overall process.
Before long, the content system is assisting large parts of the organization. Every few weeks, new features increase the value for business units. For each process, the minimum viable product (MVP) is created and then extended. The decisions on which features to implement are made one at a time. As one feature is being developed, the next feature is being designed. When new features are identified, they are added to a list that is continuously prioritized.
Steadfast commitment required for steady value
By defining a small, discrete MVP that is iteratively built upon, value is added steadily. People get their hands on a working system sooner, providing faster feedback on business needs.
Agile content management also helps the organization define the difference between need-to-have and nice-to-have requirements. Nice-to-have features tend to never reach the top of the priority list, as features that meet more critical content needs are continually identified and implemented.
The keys to success are to fully embrace the Agile content management approach, to not design too much too early, and to understand how the business works so future needs don't destroy initial assumptions.
Having to change the entire content model because the industry has shifted can deflate a project quickly. That is why it is important to understand broadly, develop content model guidelines and only build those aspects that support the value being delivered today.
The only part of Agile content management that isn't Agile is the commitment required. You cannot slowly implement Agile: You have to commit. When the organization is fully committed to delivering content applications in an Agile manner, that's when the value to the organization increases at a steady pace.