Formal process protects delivery and quality. Ad-hoc process, non-process, antiprocess, and even “inherent” or “natural” process all do the opposite.

Clear phases. Formal approvals. Ongoing user prep. Better reporting. Testable deliverables. Less disruption when priorities shift.

Why Formal Processes Matter

Formal process is not about slowing work down. It's about reducing confusion, protecting scope, improving approvals, and making delivery easier to trust. Done right, formal process actually speeds up the work, because there are far fewer breaks and hiccups that burn time, force rework, and require repetitive realignment drama.

When teams know what stage they are in, what decisions are pending, what inputs are required, and what comes next, projects move more cleanly. Working relationships also hold up better under pressure. That matters during ordinary implementation, during change, and especially during urgent moments.

In our experience, structure does more than improve delivery. It improves communication, preserves confidence, and reduces the kind of avoidable friction that makes good projects feel harder than they should.

Master Process Spine

Different types of projects use different processes. Sounds reasonable. After all, why should a website or web app be expected to be buildable in a clear and effective manner, with the same process as a Custom AI Experience, or multichannel marketing project, or an enterprise annual report?

We take a different approach, precisely because we've found that most of the project we build, regardless of type, actually do have to go through the same general phases and fight off the same general threats.

So, when working with us, even if we start on a web project, the following year onboard a custom AI ecosystem for your organization, and then later tackle a marketing project or IT update or even a custom communications instrument (big annual report, massive rebrand and associated campaigns, etc), the process will become very familiar, very quickly. This is because, regardless of project type, we draw individual processes from a common "Master Process Spine":

Explore: We get to know your new project. And we get to know each other, if we haven't yet worked together.
Engage: We work together to define and agree on a technical scope that satisfies your needs while respecting your budget and working culture. This process also results in a beginning build plan that is actually quite detailed (perhaps more so than you are accustomed to seeing at such an early stage). If we come to terms, we sign.
Architect: Starting with the beginning plan we developed together in the previous phase, we hammer out a highly detailed and specific plan that drives all remaining phases.
Provision: We create all required implementation assets (and care assets, if we are to provide Care and Continuity), including code repos, development environments, remote servers or services, and more. Many of these materials are even shared with you for early user access (and learning).
Design: We create the first rounds of visuals. For some project types, this might be limited to flow charts and the like, while for others, this may be the start of detailed branding or marketing materials.
Develop C3L: All projects, regardless of type, have content. In this phase, we create the Custom Content Control Layer (C3L), which defines how your data will be handled within the project when we start importing your existing content and creating new content.
Import: Do you already have content that is ready to be added to the project (such as exports from the current or outgoing version)? If so, we start inserting such content in this phase.
Develop App: All projects, regardless of type, enable users of some sort to interact with something like an "app" surface. Whether pages in a web app, programmable interfaces in a Custom AI Rig, configs and settings in a marketing automation project, etc, this is the phase in which we start building the features of your site, app, campaign, etc.
Release: Time to share your project with the world! Or whatever other audiences you have in mind.
Maintain: If you're also engaging us to provide Care and Continuity, which we highly recommend in most cases, this is the phase in which that care and maintenance work begins. Beyond keeping your project safe and performant, care and maintenance at EhvenConsultants also affords you ongoing opportunities for growth, realignment with changing platforms and expectations, and more.

Testing sub-phases are built into every implementation phase, starting with Architect and continuing through Maintain.

Most of these phases (starting with Architect and ending with Develop App) can overlap (and even resequence to some degree) if doing so improves pace without reducing control.

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.

Rebuild As Is: Modernize Without Starting Over

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.

Not every project needs a dramatic reinvention first.

Sometimes you already have a design that works. Sometimes the real need is more capacity, better performance, stronger security, cleaner infrastructure, better reporting, or a safer growth path. Sometimes budget realities also favor a more gradual modernization strategy.

Our Rebuild As Is process is designed for exactly that situation. We rebuild the project in a cleaner environment, strengthen the underlying substrate, correct important inconsistencies where practical, and create a better platform for performance, security, maintainability, and future change.

That lets you stabilize first, improve next, and redesign more aggressively only when the time, budget, and evidence support it.

Explore, Prototype, and 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.

Some ideas are too new, too unclear, or too risky to be treated as ordinary implementation work on day one.

Rather than pretend that undefined work is already implementation-ready, we separate that uncertainty into an Explore, Prototype, or Feature R&D path. That gives the unknown its own budget, pacing, validation criteria, and collaboration rhythm without distorting the main project.

This protects both sides. You do not have to buy false certainty, and we do not have to promise delivery on a Feature that has not yet earned a stable definition. If the work succeeds, the result can then be integrated into the main project through the appropriate implementation or Change Request path.

Change Requests and Scope Control

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.

Change Management...

When requirements change enough to affect agreed implementation or ongoing support scope, we use a formal Change Request process.

That matters because real projects do change. New ideas emerge. Constraints shift. Priorities move. Legitimate change is normal. Silent scope drift is not.

A good Change Request process protects transparency, delivery expectations, budget predictability, and provider-client relations. It gives all parties a clean way to expand, revise, defer, or reshape work without pretending the original agreement still covers something it no longer covers.

This is not red tape. It is one of the cleanest ways to preserve trust while making room for real-world change.

Priority Support Outside Normal Process

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.

Sometimes the urgent problem is not a platform failure, a covered incident, or a defect in the solution itself.

Sometimes the problem is operational. A post did not go live when it should have. A staffer is stuck in an unfamiliar workflow. A deadline is colliding with confusion. A partner needs something immediately, and the people involved do not have time to wait for the next normal cycle.

When those situations intersect with systems or workflows we understand, we may be able to help through a priority support path outside normal process. If we can help, we will. And like everything else we do that carries a price, the terms will be clear before work begins.

This section exists for real-world pressure, not for fuzzy boundaries. The exception path is defined on purpose so that responsiveness does not come at the cost of clarity.

Emergency Response and Continuous Emergency Options

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.

Emergencies happen. Even strong projects can run into urgent conditions.

What matters is not pretending emergencies never occur. What matters is preparing for them, prioritizing them correctly, and responding through a process that is already understood before the bad day arrives.

Production-impacting infrastructure conditions are handled in coordination with the relevant hosting and platform teams. Feature-level emergencies, when they occur, are handled through a structured escalation path that can include priority shifts, focused troubleshooting, and sustained response until the issue is resolved.

For projects that face unusually high traffic, elevated exposure, aggressive attack conditions, or other ongoing operational pressure, we also offer stronger support options for continuous emergency scenarios.

Calm response beats theatrical response every time.

Updates, Reporting, Approvals, and User Preparation

(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.

Healthy systems do not stay healthy by accident.

Projects and engagements evolve across multiple layers, including infrastructure, application components, workflows, content, and user practice. Those layers do not all behave the same way, and they should not all be maintained the same way.

We manage updates deliberately because each layer carries different risks, different review needs, and different ownership patterns. Some updates are our responsibility. Some are cooperative. Some are best owned by your team with our support, training, and review. What matters is that they are not treated as random chores.

The same goes for reporting, approvals, and user readiness. A project is not truly ready just because code or content exists. It must also be reviewable, explainable, and usable by the people who will actually operate it.

That is why our processes account for reporting, approval points, user preparation, and the materials needed to reduce adoption friction. Tested updates matter. Untested upgrades are downgrades.

How Features, Pricing Pairs, Portability, and Handoff Fit Together

Our processes do not exist apart from our Feature model. They exist to help us implement, test, document, train, support, and evolve Features in a controlled way.

Everything we deliver is assembled from discrete Feature packages. Most Features include a Demo, Build Package, Test Suite, Developer Guide, Success Kit, Care Kit, and Pricing Pair. Not every Feature uses every sub-feature equally, but the structure is there to improve clarity, repeatability, and commercial predictability.

This also matters for portability.

Implementation Features are integrated into the project or engagement itself. Those deliverables generally remain with the implementation, even if it later moves to another provider.

Care Features are different. They provide ongoing support behaviors and capabilities through our managed processes, tooling, environments, and operational controls. Because of that, many Care capabilities do not simply move with the project on exit, though some may be made available separately through a defined handoff, exit, or post-ecosystem arrangement when practical.

Making these distinctions explicit protects expectations, protects portability, and helps all parties understand what is being built into the implementation versus what is being delivered through ongoing support.

Choose the Right Process Before the Wrong Process Chooses You

If you already know which lane fits your situation, we can help you move it forward.

If you do not, that is fine too. We can help you determine whether you need a full implementation, a supporting platform process, a rebuild, an R&D path, a Change Request, priority operational support, or a formal emergency response arrangement.

The important thing is not to let ambiguous conditions drift into expensive confusion.