Formal Processes

Ad-hoc processes, non-process processes, and antiprocesses can indeed produce projects. Up to a point. But formal processes with client-facing documented steps, continuous user education, structured reporting, and testable end products will always take you farther.

WordPress Master Project Process

The WPMPP is used to create most WordPress projects and includes 10 phases:

Explore (we get to know each other)
Engage (if we agree, we sign)
Architect (configure app substrates)
Provision (create servers for early user access)
Design (create visuals)
Develop C3L (build metadata handlers and DB tables)
Import (insert starting content)
Develop App (build user-facing features)
Release (share with the world)
Maintain (keep it safe, grow it strong)

Testing sub-phases are built into every implementation phase, starting with Architect and ending with Release. The Maintain phase includes recurring testing sub-phases.

This process is similar in coverage to many shorter processes that are well-liked in professional circles, but the more granular breakdown improves clarity, tracking, transparency, and user prep. Most of these phases (starting with Architect and ending with Develop App) allow overlapping and resequencing for more agile execution.

Supporting Solutions Master Project Processes

Our xMPP's are used to create non-WordPress projects that are sometimes requested by organizations that come to us for WordPress, but then find that there may be critical pieces missing elsewhere in their online ecosystems. These are all server apps that we use in our own business and now provide to clients as needed:

Matomo (web analytics provider that expands or replaces Google Analytics)
Mautic (marketing automation provider that we usually pair with SendGrid as an email sender)
Suite CRM (Customer Relationship Management)
NextCloud or Seafile (file storage and cloud borne productivity apps)
WireGuard (privately operated VPN)

Rebuild As Is

Have a site design that works for you, but you need more capacity, better performance, or security improvements? Or do you perhaps need an overall rebuild, but budgetary concerns are forcing you to adopt a more gradual process?

The "Rebuild As Is" process takes what you have now, rebuilds it in our environment, services it with our processes and techniques (including the Care Plan that is right for you), adds a high-performance database and metadata infrastructure, and even fixes certain implementation inconsistencies and errors that may be plaguing your current project.

Then, after the release of your rebuilt project, while we keep it safe and performant, you can take your time to grow as you go with minimal churn and as budgets allow.

Feature R&D

Sometimes, a new feature idea might arise that is not serviceable as an existing or known set of functionalities. It might be something new. Or maybe even an idea that isn't fully clear just yet.

Rather than promise delivery on a feature that is hard to define, even if only because there simply aren't any equivalents out there for us to study, we'll pull this unknown out of your feature list and treat it as a separate project to be integrated later into your main project.

Separate budgets, dedicated resources, a lively approach to collaboration and user education, non-blocking timelines, and project management that is focused on your R&D needs, join together to reduce your risk while improving compatibility and integrability with your main project.

Stack Updates

Your project is made of multiple components that are arranged in layers that are said to stack together to form your overall solution. There are three sub-stacks in your overall solution stack:

Server, which includes everything actual servers along with networking and software that form the system behaviors and capabilities you need,
Application, which includes WordPress and all other software we install and manage to form the Feature design and functionalities that constitute your project, and
Content, which includes text, images, downloadable, and other materials you publish within your project.

Server Stack maintenance and updates are handled cooperatively by our data center teams and our development staff. Application Stack maintenance and updates are driven by our development staff, and your staff contributes with testing and approvals. And Content Stack updates are managed by your team, but we also have optional training workshops in which we can all join forces to further improve your Content Stack by refining your SEO practices and cleaning up your Information Architecture.

CR

Change Requests are available when design or development objectives change enough to affect the agreed implementation or care scope. Our CR process improves transparency, budgetary predictability, and delivery expectations so that pace or price changes never surprise any stakeholders.

OOPSR

The "Out of Process Service Request" (OOPSR), is for emergencies experienced by the project team, but are not the result of issues on the website or any covered calamity (like a hack that needs to be cleaned up).

Whether a member of your staff forgot to publish a pending post or complete a design that is due to go live at midnight or a new staffer got into some trouble that no one seems to understand, or a partner needs info that lives on the site and cannot wait until the next business day... Even though these cases are not actually emergencies that are due to the project we have built for you, we do nevertheless recognize that your internal emergency may hit areas that we understand. And we want to help if we can.

So, if you're ever stuck with a situation like any of these, you can use your account tools to request emergency support even when the emergency is in your internal operation rather than our ecosystem. If we can help, we certainly will. And, like everything we do that has a price, you'll know the terms in their entirety before any work begins.

Emergency Response

Emergencies happen on the web. Even the best-built projects run into issues on occasion.

Anything that could be expected to affect Production uptime is covered by our data center teams. Feature-level emergencies, if and when they occur, are handled by development staff and include "Prioritize Up" orders (putting impacted projects ahead of all pre-release work), and troubleshooting as required until any and every issue is resolved.

And for projects that are more prone to emergency conditions, such as websites that attract massive traffic spikes or invite attacks due to controversial subject matter, we also have additional support options for "Continuous Emergency" scenarios.