Three engagements. Each one ends. Each one leaves something behind.
Every engagement is bounded, priced before it begins, and built to transfer.
The point is not to install a system in your organization. The point is to leave your team able to run one.
Your Team Is Part of the Work
I do not disappear for two weeks and come back with a system for your organization.
That would be faster in some cases. It would also make the system dependent on the person who built it.
That is not what I am trying to create.
I design the architecture and guide the work. Your team brings the operating knowledge that only they have. We build and test the system together with the people closest to the work.
That means your people need to participate.
That participation is not an extra requirement around the engagement.
It is part of how the engagement works.
Organizational Knowledge Assessment
One to two weeks. $8,500 flat.
A bounded diagnostic of how knowledge and work move through your organization.
I review your knowledge environment, interview people across departments, examine how work actually happens, and identify where knowledge, process, ownership, and readiness are breaking down.
You receive an executive-level report with findings, risks, priorities, and a recommended path forward.
The report is yours whether or not we work together again.
Why the Assessment Comes First
I have watched good work die before it ever had a real chance.
The person requesting the work did not fully understand what it would take, and nobody validated that before the work started. Sponsorship was there. The right people participated. The work itself was sound.
It ended anyway because the scope was never checked against the effort with everyone who had the ability to stop it.
That is why I start with an assessment.
Before anyone commits to building something, I want the scope, the effort, the people involved, and the conditions around the work out in the open.
The assessment exists so we understand what we are actually committing to before we commit to it.
What the Assessment Asks of Your Team
I typically interview six to eight people for thirty to forty-five minutes each. Leadership, the people closest to the work, and the people on the receiving end of important handoffs. The number depends on the scope and complexity of the workflow.
Your sponsor or a designated internal coordinator arranges those interviews. I identify the roles and perspectives I need. Your team handles the scheduling.
Before the assessment begins, I need read-only access to the working environment in scope, along with existing policies, procedures, templates, process documentation, project artifacts, and onboarding materials. A basic role map and a list of the systems involved. Any security or access approvals completed in advance.
The timeline assumes those are available on day one. Delays in access move the schedule.
Flat price applies to organizations under approximately 150 employees. Larger organizations are quoted after a short discovery conversation.
Deliberate Pilot Sprints
Two to three weeks each. Starting at $7,500 per sprint.
A contained test of a better way. One workflow. One team. One real pain point.
We establish a baseline, work alongside the people closest to the operation, surface what is not written down, build the source of truth, and measure what changed.
Most engagements include two to three sprints, so within six to nine weeks you have evidence of what works and what is worth expanding.
Four weeks is possible by exception. It is not the default, because a longer sprint is usually a sign the scope was never narrowed.
Internal System Owner
Every sprint requires one named Internal System Owner on your side.
The title is intentional.
A liaison helps coordinate with a consultant. An Internal System Owner is being prepared to run the system after the consultant is gone. That is a different job, and it comes with a different level of responsibility.
This person is my primary counterpart throughout the sprint. They help coordinate access and bring the right people into the work. They provide context I cannot see from outside the organization. They help resolve decisions or get them to the person who can. Most importantly, they validate what we are building against how the work actually happens.
They also learn the maintenance process by doing it with me, not by sitting through a handoff presentation at the end.
Plan on roughly two to three hours of their time each week during the sprint.
After I leave, they own the system.
The Internal System Owner is named before the sprint begins, not at the end of it. I do not start a sprint without one. A system with no owner is orphaned the day I leave, which is the opposite of what you are paying for.
Who Else Participates
-
Executive Sponsor.
Kickoff, major decisions, escalation, and final acceptance. Roughly thirty minutes per week after kickoff.
-
Working participants.
Two to five subject matter experts and end users at a time, selected for the workflow in question. One sixty to ninety minute working session each week, with targeted sessions during heavier design or validation weeks. Not everyone attends everything.
Advisory
Fixed term. Scoped to the work.
Advisory is for the period after your team has built and tested something that works and is ready to expand it.
I stay involved as a guide while your team applies what worked to more of the organization, works through decisions, and strengthens the system without handing ownership back to me.
There is a defined start and a defined end.
If continuing makes sense, we make that decision together. It does not renew by default.
Advisory normally follows a sprint because, by then, there is something real to advise from. We have evidence from the work instead of assumptions about what might work.
There may be situations where advisory makes sense after an assessment and before a sprint. I am open to discussing that when the circumstances call for it.
What I will not create either way is an open-ended consulting arrangement.
Every advisory term has a published end date.
Continuing is a decision both of us make on purpose.
What a Clean Exit Looks Like
The test is simple. Can your organization operate, maintain, and improve the system without me in the room?
Before I exit, these are true:
- One person owns the system, and that responsibility is explicit and accepted.
- The source of truth is live, and people know where authoritative information belongs.
- Decision rights are clear. Staff know who can create, approve, update, retire, and escalate.
- The maintenance lifecycle is operational, not theoretical.
- The review cadence is on your calendar, not dependent on my reminders.
- Access is under your control. Nothing essential depends on an account, folder, or permission I hold.
- The Internal System Owner has completed at least one real maintenance cycle with me observing rather than doing it for them.
- Deferred items sit in a visible backlog with owners.
- Your sponsor knows who owns what next.
That last one is not paperwork. Leadership accepting the handoff is what keeps the system alive after the engagement is a line item in last quarter's budget.
Training and Workshops
Separate from the progression above. Useful on their own, and not a substitute for the work.
-
Training. $1,500. Up to one hour.
Informational. A specific topic delivered to your team, with time for questions.
-
Workshop. Starting at $3,500. Up to two hours.
Interactive. Your team works through the material against their own operation, using mindset rubrics they keep afterward.
Neither one diagnoses your organization or builds anything. If what you need is a system, start with the assessment.
What I Will Not Start With
You want AI deployed now and the knowledge work skipped.
A chatbot. An agent. A dashboard. An analytics overhaul.
Built on top of a knowledge base nobody has fixed.
That sequence is one of the specific failures this practice exists to prevent.
AI can move information faster, surface it more easily, and automate parts of the work. But if the information underneath it is outdated, contradictory, poorly owned, or hard for your own staff to trust, adding AI does not solve that problem.
It gives the problem more reach.
Starting there would mean building on ground neither of us can trust, and I would rather tell you that now than bill you to find out.
Where This Work Does Not Fit
Nobody senior enough can authorize the work and protect it.
The person requesting this needs to be the person who can clear staff time and keep the engagement alive when priorities shift.
Distance from authority kills more good work than bad execution does.
You want a vendor to own the system permanently.
The entire design of this work is that your team ends up able to run it.
If you want someone to hold the keys indefinitely, you want a different arrangement and probably a different firm.
You want software built rather than a system designed.
Applications, pipelines, and infrastructure are downstream. Avanza Methods works upstream.
I can advise on what to build and bring in a technical partner when the time comes.
And plainly: this work requires an organization willing to do the work.
The Goal Is Independence
The way I work is simple:
I design the architecture.
We build and test it together.
Your team learns by doing.
Then ownership stays with you.
A successful engagement should make you more capable of running the system without me, not more dependent on keeping me around.
Tell me what is in the way.
Tell me what is getting in the way of your organization moving forward and what would be different if it were fixed.
I review every inquiry personally and respond within one business day.
Clarity is what scales.