Working with Cloud Data

The people designing and building your data platform are the people you work with directly. Our senior practitioners work inside your systems and alongside your team, so the people making architectural decisions are also part of the conversations that shape the work.

This page explains what that looks like in practice: how an engagement starts, how the work is organized, what we need from your team, and what you should expect to have at the end of the first phase.

What you can expect from us

How an engagement begins

We start with one area of the business where better data can have a clear impact. It may be a reporting process that takes too much time, a set of numbers that people do not trust, or an important business question that is harder to answer than it should be.

Together, we decide which problem makes the best starting point. That becomes the focus of the first phase.

We then work backward from the business question into the data behind it. We identify the source systems involved, understand how the business currently defines the important measures, and build the ingestion and modeling needed to support them.

Your subject-matter experts help us validate the result against the systems and processes they already know. Once the model is ready, we put it in front of the people who will actually use it.

We do not need to define the entire data program before beginning this work. A working model gives your team something concrete to evaluate, and what we learn from the first subject area makes the next phase easier to scope accurately.

The goal is to get useful work in front of your team early enough that feedback can still influence the design. Kevin Griffin, McPherson's Vice President of Financial Planning & Analysis, described the first phase:

“We just accomplished in 90 days what traditionally takes a year or more to do. This is twelve months of work.”

How the work runs week to week

We manage the work through a shared backlog that shows priorities, estimates, and status. You can see what is being worked on, what is coming next, and what changing a priority is likely to cost.

Several workstreams may be active at the same time. For example, we may be connecting the next source system while another part of the model is being validated. That lets the project continue moving without waiting for every activity to finish in sequence.

While a subject area is being actively built, we usually hold a short working session with the people closest to the work. These sessions are often about 30 minutes and may happen daily or several times a week depending on the project and your team’s availability.

The purpose is practical: answer questions, review what changed, resolve business rules, and identify anything blocking the next step. The group is intentionally small and usually includes the relevant subject-matter experts, the Cloud Data practitioners doing the work, and the sponsor or project lead when decisions are needed.

As the work stabilizes, the meeting cadence usually decreases.

Completed work is also demonstrated to the people who will use it. Where possible, someone from your team leads those demonstrations with our support. That person becomes an internal resource for the subject area and helps extend the knowledge beyond the core project team.

For planning purposes, active subject-matter experts should expect to spend a few hours each week on the engagement. Most of that time goes toward working sessions, validation, and answering questions that require business knowledge.

What your team contributes

A successful engagement requires both technical work and business participation. Cloud Data can own the platform implementation and engineering, but your team provides the business knowledge and authority needed to make the result trustworthy.

One person may cover more than one responsibility.

When an engagement includes a new platform implementation, we can carry that work end to end. We configure the cloud data platform, connect the required source systems, and build the models and pipelines on top of them. If you already have a platform in place, we work within that environment instead.

Your subject-matter experts play a different role. They know how the business actually operates: how customers are classified, when a sale counts, which transactions should be excluded, and where exceptions exist that may never have been formally documented.

That knowledge is essential during validation. If the right experts are not available, questions remain unresolved and the project either slows down or moves forward on assumptions that may need to be corrected later. We identify those dependencies early so the right people can be involved when their input is needed.

Business definitions also need an owner inside your organization. We can identify inconsistencies, recommend an approach, explain the downstream implications, and document the final decision. Your organization ultimately decides what an important business measure means.

What you have at the end of the first phase

At the end of the first phase, you have a working data foundation for the business area we started with. The important measures have agreed definitions and have been validated against your source systems by the people who know them.

Your team also has reporting built on that model, documentation explaining what was built and how it works, and a prioritized backlog for what comes next.

Once the underlying measures are settled, trained people on your team can apply them to operational questions without waiting for us to design every report. They can combine governed measures with the context they know from their own work, test an idea, and share what they learn. That is the practical goal of self-service: extending the value of the model as new questions arise.

After the first phase

We continue learning about the next priorities while the first subject area is being built. By the time that work is validated, we usually have a much clearer understanding of what should come next and what it will require.

That means the next phase does not start from zero. Once you confirm the priority, we can move directly into the next subject area using what the first phase has already established.

Your team is also becoming more capable as the work progresses. Because training and documentation happen throughout the engagement, people begin working directly with the platform while we are still there to support them.

For some teams, that means moving away from spreadsheets and other manual reporting processes. For others, it means giving analysts a governed model they can use to answer new questions without rebuilding the underlying logic each time.

The long-term operating model depends on what you want. Some clients keep Cloud Data involved for architecture, new subject areas, and more complex changes. Others want us to build the capability and prepare their team to operate it independently.

We plan for that choice early. It determines how much training, documentation, and operating handoff we build into the engagement. In either case, routine work should not depend on Cloud Data being the only team that knows how the platform works.

Whether this is the right fit

This approach works best for organizations that want to build a data capability they can continue using and extending over time.

It may not be the right approach for every problem. If you need one report delivered quickly, for example, a smaller and more focused engagement may make more sense. We will tell you that in the first conversation rather than recommend a larger program than the problem requires.

The way we work is shaped by a few principles: put usable work in front of people early, validate important definitions with the people who understand the business, and build the platform so your team can take increasing ownership of it. Read more about how we build data programs →