Peter Mikula and
the meeting after the fix

Ninety people needed their email moved. At Otto Construction, the job was to take a 90-user organization from an on-premise Microsoft Exchange server to Office 365. Peter Mikula handled the planning, supported the migration, and dealt with the small problems that appeared afterward. The company’s IT director, Andy Adsetts, was pleased enough to say he would use Mikula again.

There is something appealingly untheatrical about that account. No grand unveiling. No business owner announcing a new era. A construction company changed its email system, and the person responsible for IT could get on with his work. For a consultant, that is a useful kind of applause.

Mikula is the Sacramento-area founder and CEO of Narmada, a software platform for managed service providers, or MSPs. He also founded Mikula IT Consulting, known as MITC. His work connects two jobs that can easily drift apart: making technology function and helping a business decide what to do next. Narmada puts assessments, budgets, equipment lifecycles, and client reviews into a shared workspace. The recurring concern is the meeting after the fix.

A career in the parts that must fit

Mikula’s working history moves through consulting, support, systems administration, and operations. It includes systems and desktop support at CBIA, systems and network administration at CMIT Solutions, and the Sacramento director of operations role at FlexManage. These are jobs in which a good idea eventually has to survive a real network, a real budget, and somebody who needs to finish a task before lunch.

His FlexManage work brought the organizational side into view. Colleague Jimmy Landrum credited him with creating operating standards across desktop support, network engineering, project management, network assessment, documentation, and consulting teams. The range matters. A project passes through several people’s hands; clarity has to travel with it.

Another professional recommendation, from Brian Beck, described an infrastructure replacement that followed Mikula’s audit. Aging equipment was out of warranty. Mikula helped connect the technical findings to costs, replacement decisions, and an implementation schedule. Beck’s account emphasized that clients and projects were able to continue through the change.

The pattern is practical rather than ornamental: inspect what exists, explain the consequences, organize the work. A network diagram can show where a cable goes. The more difficult diagram shows who needs to agree, what they can afford, and when the change can happen.

Beck’s account also describes recommendations made within the organization’s budget and goals. That qualification is easy to hurry past. A technically reasonable replacement still has to fit a customer’s circumstances. The audit supplied information, the cost analysis helped explain the choice, and the schedule made the change possible. Together, those steps show the advisory work around an infrastructure project.

The customer’s version of the story

MITC’s description of Mikula stresses a direct approach and continued improvement of processes. Its clients make the point in less abstract terms. Felipe Martin, the owner of Martin Brothers Construction, described wanting fewer delays and frustrations for his team. He valued Mikula’s response when the business needed help.

Lisa McCracken, a finance and administration director, described years of work with him, including network improvements and hands-on attention when important problems arose. Jennifer Aragon of the California New Car Dealers Association recalled being uncertain whether a small new firm could handle an urgent transition. Her account ends with satisfaction about the switch and Mikula’s attention to the organization’s systems.

These are customers describing their experience, and their choice of detail is revealing. They talk about responsiveness, continuity, and confidence. The technology matters because people have work waiting on it. Nobody needs a fascinating explanation of email at the exact moment they cannot send any.

Putting the review on the same page

MITC uses Narmada for its own virtual chief information officer services. A vCIO provides technology planning and advice without requiring the client to employ a full-time chief information officer. In Mikula’s two businesses, service delivery and software meet in the same activity: reviewing a client’s situation and making a plan.

Narmada organizes the material behind that review. Its workspace includes assessments with evidence and scoring, technology roadmaps, budget projections, hardware lifecycle information, and client dashboards. Connections to tools such as ConnectWise, Autotask, HaloPSA, and Microsoft 365 bring operational information into the process. A client portal makes information available to the people making decisions.

That combination gives the quarterly business review, usually shortened to QBR, a more concrete purpose. The discussion can connect a technical finding to an expense and an agreed action. A device’s age becomes part of a replacement plan. An assessment becomes something to discuss with the person responsible for the business.

For a founder with an operations background, those functions address familiar handoffs. An assessment records a finding. A roadmap places work in an order. A budget gives that work a financial frame. Keeping the information together makes it available for the next review, when a different question or changed priority may require another look.

Start with something you can use

In his June 2024 interview about Narmada, Mikula discussed preparing and carrying out client reviews, compliance audits, and lifecycle management. His advice included beginning with small frameworks and expanding gradually. It is a sensible detail to keep in view when looking at a platform with a long list of capabilities.

A framework is a way to make a review repeatable: a set of questions or checks that a provider can apply, revisit, and extend. Starting small gives a team something it can actually complete. The interview connected that work to longer-term business growth and keeping clients.

There is an operational temperament in that approach, consistent with his earlier standards work. Begin with a process that people can perform. Add to it as the organization learns. The attraction of a comprehensive checklist is obvious; so is the attraction of putting it off until next Tuesday.

For Mikula, the work spans both the service firm using the process and the software company packaging it. That proximity gives his career a particular shape. The client review is an activity his consulting business offers, as well as a workflow his platform supports.

The small-framework advice also gives the client a way into the work. A review asks people to look at a situation together. If the process becomes too elaborate to finish, its detail has little opportunity to influence a decision. Beginning with a manageable set of checks leaves room to explain why each finding deserves attention.

A better question than slide 27

By summer 2026, Narmada’s writing was taking aim at the meeting itself. One July article argued that clients care about their own business outcomes more than an MSP’s collection of tools. It urged providers to ask about plans and frustrations, then connect recommendations to what they had learned.

An August article gave the idea a compact name: the Q in QBR should stand for questions. It proposed using the meeting to discover what has changed, what is coming, where work is difficult, and which decisions require attention. Technical preparation still belongs in the process. The detailed report can support the conversation without supplying every minute of its agenda.

“Questions before recommendations.”

Narmada, August 2026

Those words appear in Narmada’s guidance, and they sharpen the connection between Mikula’s consulting work and his platform. His clients’ accounts describe someone responding to their particular circumstances. The company’s review advice asks providers to preserve that attention even when they have reports, dashboards, and several other accounts to manage.

A dashboard can make a meeting easier to prepare. It cannot decide which concern a business owner most needs to discuss. The person across the table still has to ask, listen, and notice when an apparently small answer changes the plan.

The company’s August guidance is specific about the ending, too. A useful review should leave an action with an owner and a timeline. That detail brings the discussion back to Mikula’s earlier work in project planning and operations. Agreement in a meeting is only the beginning; someone has to carry it into the working week. A named responsibility gives the next conversation a place to start.

The machine has a retirement date

The same attention to context appears in Narmada’s treatment of equipment lifecycles. Its guidance covers the whole journey of an IT asset, from acquisition and deployment to maintenance and retirement. Planning replacements lets a business consider spending ahead of time rather than waiting for a failure to make the decision urgent.

That is where a routine inventory can become useful to a business conversation. Equipment has a cost, an age, and a role in somebody’s work. Keeping those facts together helps a provider discuss the timing of an upgrade alongside the company’s other plans. The inventory earns its place at the table by helping someone choose.

Narmada’s writing about review fatigue also allows for adjusting the meeting schedule. Some clients may need a formal review twice a year, with other account conversations between them. Preparing an agenda beforehand and inviting the client’s updates are small accommodations with a clear purpose: make the time useful to the people attending.

Mikula’s path from support and operations to consulting and software gives this work its continuity. There are systems to maintain, changes to organize, and decisions to explain. Back at the ninety-inbox migration, success meant the new email environment worked and the client was satisfied. In a Narmada review, the next useful outcome is equally concrete: somebody understands the choice in front of them and knows what happens next.