Bridging Business Goals with Technical Reality

Most technical requests fail not because they’re impossible—but because they’re overbuilt.

“What if revenue forecast data lived in a dashboard?”
“Can workflows email clients directly?”
“Can we track Zoom attendees and sync them into the CRM?”

These are good questions. They’re creative, forward-looking, and usually rooted in real business friction. When I hear them, my first reaction isn’t to shut them down—it’s to slow the conversation down just enough to understand what problem is actually being solved.

Because effective consulting isn’t about saying “yes” to every idea. It’s about helping clients choose the right level of solution for the outcome they’re trying to achieve.

One Request, Multiple Solution Paths

I get asked a lot about “Best Practices.” It’s a good instinct to ask, but my response is never a list of items. Instead, it’s a list of more questions. Most technical requests don’t have a single correct answer. They have tiers of solutions, each with different tradeoffs in cost, flexibility, and long-term maintainability.

Take dashboards in Deltek Vantagepoint as an example. A request to surface contract backlog data can generally fall into one of three approaches:

1. Native dashboard configuration. This approach relies on standard dashpart bases, calculated fields, and light workflows. It’s fast to implement and inexpensive, but it requires accepting the structural constraints of the platform. For well-defined, stable, or low-priority questions, this can be more than sufficient.

2. Extended configuration using custom data modeling. Here, custom hubs and stored procedures are used to reshape data so it can be consumed by dashparts more flexibly. This requires clearer requirements and stronger technical effort, but it offers significantly more control. Because the data stays internal to the system—rather than flowing through APIs—it’s often more resilient. The tradeoff is complexity: future changes typically require SQL expertise.

3. External BI tooling. Connecting data to tools like Power BI or Informer via ODBC or APIs unlocks best-in-class reporting and analytics. This route offers maximum flexibility and user-driven exploration, but it introduces higher licensing costs, data latency, and operational dependency on another system. It also assumes users are comfortable working in a separate analytics environment.

None of these options are inherently “better.” The right choice depends entirely on context.

How I Evaluate the Right Fit

When deciding between approaches, I anchor the conversation around a few core questions:

• Is the pain point clearly defined? If the problem itself is still fuzzy, larger technical solutions tend to drift in scope and miss the mark.
• Is there real momentum behind the request? Some issues are interesting ideas; others actively consume time, attention, and operational energy. The latter justify deeper investment.
• Are the needs repeatable or isolated? For one-off reporting needs, internal solutions are often faster and more cost-effective. For broad, evolving analytics requirements, external tools may make more sense long-term.
• Does the solution align with system assumptions? Every platform operates with implicit expectations, such as:
  • Treating the core system as the source of truth
  • Using native search and security models
  • Relying on external tools for outbound communication like email

When a request pushes against those assumptions, it doesn’t mean it’s wrong—but it does mean the tradeoffs should be explicit.

The Goal Isn’t Maximum Capability — It’s Appropriate Capability

The most successful solutions I’ve seen aren’t the most technically impressive ones. They’re the ones that fit the problem, the organization, and the moment. My role in these conversations is to help clients move from “Wouldn’t it be cool if…” to “This is the level of solution that actually serves us best.”

When the solution feels obvious, that’s usually when the real work begins.