Provide a Low Code Platform for Agile Automation
We have a significant number of customers who originally purchased the PMG Digital Business Platform to solve a specific business problem (Employee Onboarding, IT Service Catalog, Manufacturing Process Orchestration, etc.) and who are now discovering that PMG can and should be leveraged much more broadly across their organizations. Evolving from a single team’s use to a shared resource accessible to a large number of teams or departments is definitely a challenge. Luckily, we have a community of PMG users working through this at the same time who are innovating, learning, and transforming their organizations and are paving the way for the rest of us. The approaches they are pioneering are relevant to a broader audience – anyone who has a low code development platform that they want to offer as a business capability across multiple teams. In this post I’ll discuss two of the challenges in this evolution – the role of the group who “owns” the platform and approaches to sharing costs by those teams that are gaining benefits.
Stand Up a Governance Team
If you want to have a low code capability, it is going to require that an individual or team serve functionally as the operator of the platform. It is conceivable that one individual could perform this function as a portion or all of his or her role but most of our enterprise customers find that they need a team appropriately sized to the group of internal customers they are serving. In practice, most customers are standing up that team using the resources from the original PMG platform team. While that is a very practical approach, it is important to recognize clearly and clarify for all concerned that this is a significant transition from one role to another. You will need to consider their reporting structure. They may need to be shifted in the organization to a spot that “makes sense” given their function. You will need to make sure they understand they are now going to provide governance functions on behalf of the entire organization rather than still maintaining responsibility for processes owned by just one team.
The central team will often provide the following functions for all the groups:
- Training and certifying new process designers on the platform; serving as coach/mentor as they come up to speed and configure processes
- User Administration
- Designing and configuring central shared forms and workflow modules for use by all such as approvals, email notifications, error handling, basic integrations to other key systems, etc
- Performing Process Design projects on behalf of teams who cannot or choose not to dedicate a resource to learn and configure in the platform
- Design and operate migration standards and processes
- Design and operate the production release process
- Perform Tier 1 and/or Tier 2 Support on behalf of participating teams
- Advocate internally for use of the platform by performing outreach and education about use cases, capabilities, etc.
Depending on your organization’s unique needs, you may position your central team’s roles along a broad continuum, choosing to have either more or less of the work federated out to participating teams or centralized with your operations group. The more you can federate, the more you eliminate a potential bottleneck and let groups work at their own pace. But of course, the more you federate, the less control you have so where there is high interdependence and high risk, the governance processes may need to be more rigorous. In practice, your team should continuously evaluate whether your processes balance speed and risk appropriately and adjust.
Define a Cost-Sharing Approach
Figuring out a cost sharing approach is also proving challenging for the companies we work with. After seeing several models, some more successful than others, here is the approach we recommend. Obviously leveraging any or all of the concepts here may be helpful – the fair and effective approach you come up with will look a little different from every other company’s due to your unique circumstances.
Plan to re-evaluate the cost side as well as the funding side on a periodic basis. For most organizations who are still budgeting on an annual basis, this will be an annual process. If you want to move more quickly and be more responsive, then the re-evaluation could take place every six months or even every quarter. In an ideal world, a Steering Committee with representatives from each department using the platform will perform the cost and funding review.
To evaluate the cost side, the Steering Committee will include the monthly SaaS fees or the Annual Support and Maintenance Fee for on-prem deployments. That’s the easy part. Then, they should assess or reassess the required skills and roles required to operate the platform. This is not the cost to implement new processes, but the cost of “care and feeding.” There are the central support functions, as well as a need to continue to make small enhancements and updates as your users and their processes change. Nothing will put a technology investment on the path to obsolescence faster than failing to invest in its evolution to support your evolving organization. So how many people are really required to provide these necessary functions? Are the roles as defined in the current organization adequate? Are there gaps? Are any teams over-allocated? The Steering Committee should define the team needed to keep the solution healthy. The software plus the supporting team – that’s the cost side.
For funding, it makes sense to take a multi-factored approach to calculating each team’s usage of the platform and share the costs accordingly. Some usage factors you could consider include: headcount in the group, number of employees or end-customers served by the group, number of requests or workflows run per week or month, number of support requests against the group’s processes, or number of failures/errors in workflows. Ideally, the Steering Committee should identify 3-5 factors that make sense in the context of the full implementation and use them in a weighted formula to allocate the costs they’ve calculated across each of the teams. The calculations can be used to make real-time true-ups or can be used for budgeting for the next cycle so that the true-ups are always in arrears, even significantly in arrears, but are nonetheless always being adjusted.
Conclusion
Every once in a blue moon, we find a very progressive company looking to purchase a low code development platform for its flexibility and ability to support a wide variety of automation and orchestration needs. But it is much more common for organizations to realize the true power of a digital business platform only after implementing it for a specific initial purpose. Either way, the company needs to put careful thought into how to support a centralized capability and also into how the teams who use it can fairly and responsibly share the ongoing investment.