Scalable and self-replicating minimalistic operational model for self organized organizations
The Bigger Picture
Architecting operations for Axelerant as a remote web services company for over five years now, with a background in self-organizing non-linear dynamical systems, I have been witnessing quite a bit of dynamical similarity in discovering and architecting a product (application) solution or organizational operations as a wholistic ecosystem. Valid not just while discovering the solution while in its infancy and when we are building a minimum viable solution keeping the "need funnel" at highest priority values but also while it is organically evolving (while moving) as the company or as the collective conciousness matures.
This motivated me to explore more on its structure, dynamics and drivers to understand any organizations operational ecosystem as an application or a product!!. It's easy to zoom inwards and find similar structure, dynamics and drivers (only limited in scope and tailored) to smaller autonomous sub-systems forming the wholistic operational system. Dive deeper and dynamical model remains the same (majorly)...We see this all the time in our project portfolios as well for customers.
An important question arises "Why is all this important"? - To be aware, be consciously sensitive and hence not ignore any tangent, plan and prioritize accordingly. Essentially "to have a well oiled and a non - skewed scalable system or a sub-system forming the gestalt."
We started with a minimum viable operational solution for the entire organization keeping the blueprint limited in scope to highest priority business (operations) values. Values were aimed at either enhancing systemic efficiency, effectiveness or element (forming the system) empowerment. Elements being people, processes or tools and techniques.
Just as with any application discovery, we started with wishlist epics reflecting on short term and long term organizational outcomes (and outputs). Elements from wishlist then moved to a prioritized backlog with collaboratively defined, Must Haves, Should Haves, Could Haves, and Would not Have (MoSCoW) executed via monthly time boxing. Decision drivers for epic selection landing in the domain of strategic alignment (at that time) and implementation feasibility analysis to get needed and planned outcomes/outputs on the timeline. Implementation feasibility analysis was well supported with market analysis of best practices, risk spiking and even building POC's for some user stories.
Being a small unit (in number of employees), it was possible for us to easily allow for co-architecting (via collaboration and consensus at relevant places) the operational solutions; the entire organization forming the customers and hence feeding the wishlist.
Further on the timeline
Once a Minimum Viable operational ecosystem is in place, it has to be maintained (to support efficiency and effectiveness) and also enhanced/empowered in capability. For both the tangents, requests are from internal stakeholders (which generally is the entire company for small to mid sized companies) for internal challenges or for supporting/catalyzing adoption of world wide delivery best practices. The service requests and enhancement stories (epics and themes if we consider a wider scope and classification) can be classified into two dimensions ("not" mutually exclusive) based on
(a) timeline of needed change (b) goals associated with the needed change
Service requests in (a) can be further categorized and weaved with categories in (b) to form following classification matrix
Proactive change (as a risk mitigation strategy for internal and/or market driven risks suitably prioritized by studying probability and impacts) and which could be a correction or an enhancement based on goals
For example, creating a new notification scheme for a new role in your PMIS tool as a proactive correction to allow for future scalability and efficiency.
For example, security updates and plugin enhancements to PMIS or other tools and techniques to allow for proactive capability enhancements or introducing a new engagement program based on the pulse of company wide feedback. (ADAPTIVE)
Reactive change (post a failure and to plug a gap to not repeat failures/post a success to repeat successes in similar or dis-similar domains via tailoring), again which could be a correction or an enhancement based on goals
For example, correcting systemic glitches such as scheme or accessibility issues "post reporting" say in a project in PMIS. (CORRECTIVE)
For example, adding a new plugin to PMIS such as for automating recurrence of timely processes to aid efficiency. (ADAPTIVE)
Other possible examples across operational functions
Engineering "managed outsourcing" talent management framework (Proactive - Capability enhancement)
Re-invent feedback management system based on collective stakeholder feedback (Reactive - Adaptive/Enhancement)
Enhance customer or talent on-boarding experience (Proactive - Enhancement)
Tool integrations to allow for effective information management and information accessibility (Proactive - Enhancement)
Re-engineer process baselines (Reactive - Corrective if driven from project failure)
Re-engineer process baselines (Proactive - Enhancements driven from project success)
Re-engineering and "managing" organic evolution - Continuous delivery execution models
With the above classification of service requests based on timeline and goals (separately or collectively) needed for implementation delivery, one can follow Kanban style queue based management with defined SLA's or SCRUM based deliveries with monthly or quarterly time boxing.
We have been using both the dynamical models for excuting service requests - driver being the location of request on the above grid.
(a) Help desk portal for short term needs (Critical and Urgent incidents and problems) managed by a dedicated team
Deals with random requests that cannot be accounted for individually in the annual budget planning process as a program/project. Size and complexity of the service request being core diiferentiators. Others being systemic impact, shorter completion time and which arise as a result of more direct contact with internal customers.
Managed via internally architected Service Level Agreements (SLA's), flow and queue management using Kanban (Can't afford choking here)
Generally focus on stability and maintainability of operational system. Requests could be directed to a third party as well for cloud based tools.
For example, Upgrades and need based tailoring to tools and techniques, Project level information needs, Talent and customer on-boarding with defined baselines, Execution of defined timely processes (weekly, monthly, quarterly,...), ...
(b) Themes, epics and user story management via SCRUM for enhancements which could be both perfective and adaptive arising as correction or a prevention (advanced detection and correction of latent errors)
Requests generally focus on functionality enhancements/corrections
Execution demands capacity estimation and timeline planning with MoSCoW (highest value delivery if enhancement) with typical cadence on scrum ceremonies and embedded with Kanban at places (if a need).
Feature enhancements could also be focused on adding to system perfection proactively. These could include working towards quality and maintainability to the application portfolio or a specific product (a framework) in the portfolio.
or could be adaptive such as planning for disaster recovery (must have for tools and techniques) again proactively.
For example, Architecting dashboards and information radiators for a stakeholder tier with a specific level of visibility, Introduction of a new process baseline to support additional best practices in a function, Introduction of a new engagement program, ...
(c) SCRUM and Kanban or any hybrid of both can also be used for "internal product development" post "make or buy analysis". We internally used Redmine for quite a few years and it being open source, the instance was tailored with in-house architected plugins and patches with Ruby development expertise until we finally shifted to a new PMIS. Local intranet solutions could be another example. Just like any typical product development, SCRUM fits in well here with Kanban as a cultural enabler.
It is generally a good practice to execute both the models with separate and dedicated teams to allow both to run in parallel with defined SLA's, sprint plans and also allow for a consistent and predictable velocity of deliverables. However, this may not be feasible for a small sized company for limited support overheads. With the same team, the execution models need to be better aligned, balanced and prioritized, of course after identifying any impacts and dependencies.
It's difficult to state at this point on how the above dynamical model changes/scales or bifurcates with medium to large sized companies though I strongly believe that the core "elements" will still remain the same.