Michelle Krejci, Greg Pamier, Will Milton, Doug Dobrzynski, Matthew Gilboy
There are three paths client can follow to reach support:
- New support client with audit
- New support client from internal development project
- Grandfathered support client without audit
None of our clients are there yet; they all have some road to follow. A workflow for on-boarding all three will be addressed after requirements.
The support process and offering differs from the existing QA, Project Management, and Development workflows. These workflows should inform support work and support work should inform development. The support on-boarding process is to accommodate this.
Below are the requirements that clients must meet before we provide support or begin a project. This is also the minimal state that clients can expect to be in after we build their site.
Previous versions of these requirements have been laid out in the Support Wiki: https://projects.prometsupport.com/projects/updatesfortradesupportsjobt/wiki . Key contributors to that document have been Michelle Krejci, Greg Palmier.
The following requirements are not exhaustive but represent an initial minimum of compliance that can be tested against any support clients.
- A site audit should be performed for all new clients that identifies, prior to support obligations, the gap between the state of the site as it is, and the steps necessary to meet our threshold.
- Checklist for Audits: https://projects.prometsupport.com/projects/sysadmins/wiki/Site_Audit
- Client buy-in on on-boarding the site. This includes:
- Slaughtering of site
- Push strategy documented
- Featurizing of site
- Disabling of all possible module UIs in production and negotiation of features that will need to be ignored in features reverts and pushes
- All code in git on Github
- A dev-staging-prod environment
- A Promet Standard file structure (i.e., modules in /custom and /contrib, no files or directories in root, theme files properly labeled, no .bak or tar.gz files, etc.)
- No other CMS or other websites in general inside of the Drupal Webroot (/dev, /staging); any landing pages will either require a fully documented and agreed upon gitignore policy, or will need to be excluded from liability
- Root access to the server(s) provided
- PHP Tuning and Minimum Performance/Security Tasks completed or agreed upon as highest priority backlog items
Promet Source is a development shop that specializes in the delivery of Drupal applications.
- General compliance with current LTS Slaughterhouse methodology
- All content types, taxonomies, views, and roles and permissions in features
- Generate drush.make file and place in git repo outside of root and in wiki of project
- Get User Stories to use for QA purposes (so we all know what we mean when we say the site has passed QA) from client
- Updates applied to core and contrib
It is essential that clients operate based on the same understanding as Promet, and that Promet has a transparent understanding throughout the organization of these expectations. These expectations need to be standardized across all client types to ensure that costs for support are reduced by streamlining client deliverables.
- A clearly defined set of criteria for a hotfix
- Clients will be required to provide user stories, acceptance criteria, and assist in the maintenance of testing details
- Clients will be required to attend occasional training on topics deemed necessary to the maintenance of their site, as applicable to their skill level and site featurization
- An understanding of how frequently we will back up their database
- An understanding that we will not log into their production site and make a fix. Rather, they will receive detailed instructions for client content/user administration as necessary
- A complete assessment of what a 'good' state is and what a rollback means
- A complete assessment of enabled features on the site that we will provide consulting or development work for, but not support
All of the above requirements are remediable tasks. The should be guided by a singular intent: make the work boring. Essentially we are selling a promise. The promise is that we will keep the clients site up. If it breaks we will put it back.
The remedying of these deficiencies is what can be construed as on-boarding. Any client that purchases a support package must understand that their site will be
To repeat, there are three scenarios for on-boarding: new support from audit, from internal development, and grandfathered in clients.
On-boarding workflows:
- New support client with audit
- audit reveals findings
- audit provides recommendations to meet requirements above
- post-audit followup:
- client pays for development work to be executed outside of support contract
- client pays to execute complete list of recommendations
- until post-audit followup is complete, client is deemed 'unsupportable'
- New support client from internal development project
- Grandfathered support client without audit
The purpose of support is to streamline all possible tasks. The support department is not a short run shop. Its primary objective is to perform the same tasks over and over and over for a stable of sites rather than one-off exciting work for a handful of favorites and friends and complainers. This includes applying updates, rolling back items the client broke to the previous known 'good' state.
Support is a retainer service. Support lives by maximizing the same output across multiple clients and this is only achievable when we have a stable platform to deploy against.
Support specializes in two ways: engineering and development. The former works on clients as a platform. The latter works with clients on a directed project basis. Directed projects are very limited engagements and are very limited in scope and scale. The intent of directed projects is to provide a secondary backlog for support projects without disrupting the supportability of a client or causing them to need to go through the on-boarding process.
For projects of sufficient scale or scope, the support department will have no choice than to reject work in progress. unless performed within the agile methodology, with milestones incrementally delivered in minimum viable projects, and with thorough documentation and a bevy of automated and manual tests.
In all likelihood, clients will find transitioning away from support prohibitive because the site will require on-boarding again. The cost will be reduced but will not be trivial.
Support will do well to work in tandem with QA and Development to ensure that the site is regularly audited throughout development. Support infrastructure will need to be able to address both functional and non-functional specifications; clients exceeding these specifications will need to be turned down or management will need to provide a viability study to address an expansion.
Further requests for documentation include:
- A checklist for determining when and how a project will be handed off from the support platform to the development workflow
- A checklist for determining the viability of a development project being incorporated into the support platform
- A matrix for determining complexity, scope, scale, and other elements that contribute to pushing a site off support
On a per client basis:
- Management time is kept to a minimum and not billed
- Support time is kept to a minimum and not billed
- Every ounce of effort that is put into any form of development is billed
On a division level:
- Management time is intended to identify accounts that are lagging behind in compliance and require work
- Support time is meant to:
- deploy changes across the entire ecosystem
- develop tests
- improve internal deployment and delivery tools
- find ways to identify and minimize unique and interesting tasks
When support tasks are able to accommodate more changes to the code base while simultaneously maintaining stability we are able to provide value while minimizing risk. This means that we are able to provide support to more features of the site and facilitate more autonomy of site users.
This assumes that we begin with a certain portion of the code base that is 'supportable'. As the platform for support grows, this portion also. For example, if we 'support' 5% of the code base, and make an improvement to the 5% for client A, then the improvement will be applied across clients B-Z as well.
An edge case of this would be Drupal Core updates. Ideally, we might have such command over the code base that we would be able to roll out updates to development environments for UAT across all support sites, simultaneously.
Support needs to determine or access to:
- What is considered to be an "expensive" task and client
- Historical data of the most successful support clients to date
2014 1/30 - Initial commit 1/31.1 - Updates of engagement scope 1/31.2 - Include of change log, escape velocity, metrics section 2/1 - Added detail to a variety of sections