Module 1: Pre-Build Readiness | Design-First Delivery | elijah.ai

Module 1: Pre-Build Readiness

Before You Open Power Apps

What this module covers: Four things you must have in place before you touch the tool. If you can't check these, you're not ready to build. That's not gatekeeping—it's protecting your time and your stakeholders' trust.

Time: 10–15 minutes to work through.

The Four Readiness Checks

Think of these as the minimum viable clarity. Without them, you'll build something, show it to someone, and hear: "Oh, that's not quite what we meant." Or worse: you'll finish and realize no one owns the outcome.

1. Who feels the pain—and how often?

Not "the department." A person or role. Someone who wakes up and deals with this problem regularly.

  • [ ] You can name the primary user or role. (E.g., "Accounts payable clerks" or "Sarah in HR.")
  • [ ] You know how often they hit this pain. Daily? Weekly? Monthly? Volume matters when you're deciding if automation is worth it.
  • [ ] You've talked to at least one of them. (Even a quick call. Don't assume.)

2. What's broken today—in plain language

"Make things easier" isn't enough. You need a problem statement that a non-technical stakeholder could repeat back to you.

  • [ ] You've written down what's broken in one paragraph.
  • [ ] It's in plain language. No jargon. "Invoice routing takes 3 days because we're emailing PDFs and someone has to manually key them in" beats "We need better process optimization."
Example (good): "Field technicians spend 30 minutes at the end of each day filling out paper forms and then re-entering the same data in the ERP. We lose time and we get transcription errors."
Example (not enough): "Our field operations need to be more efficient."

3. Someone owns the outcome

A named business owner. Not a committee. Not "the team." One person who is accountable for the KPI and adoption.

  • [ ] You have a named owner.
  • [ ] That person has agreed they own it. (Don't assume. Ask.)
  • [ ] You know what happens if adoption fails—who gets the uncomfortable conversation.

4. What does success look like?

A rough idea. You don't need a full dashboard on day one. You need something measurable.

  • [ ] You have a success measure. Cycle time? Error rate? Hours saved? Requests processed?
  • [ ] You have a before (or can get it). What's the baseline today?
  • [ ] You know what "better" means. (E.g., "Same-day invoice routing" or "90% reduction in data entry errors.")

Why This Matters

These four checks prevent the most common failure mode: building something impressive that nobody owns and nobody uses. They also give you a way to say "not yet" when someone drops a vague request on your desk. "I'd love to help—once we have an owner and a baseline. Can you grab those and we'll pick this up?"

Next Step

Once you've checked all four, move to Module 2: Plan Your Project. That's where you get into the nitty-gritty of mapping the current process and creating a project plan.