Part 1 of 3 on project management in the Claris world.
What makes Claris FileMaker Pro attractive can also make its projects hard to manage: you can build quickly. A skilled developer can sit with a client, understand a problem, and produce something useful far faster than traditional software allows. That is a real advantage. It also makes it easy for the development work to quietly become the project management.
For years, many FileMaker projects have run that way. The developer scopes the request, estimates the effort, manages the client, builds the solution, and delivers. On the right project, that works. It breaks down when the project gets bigger. Now there are multiple stakeholders. The budget matters more. Several requests move at once. Priorities shift. Something described as one more field turns out to touch the data model.
At that point, development is no longer the only job. Someone has to ask whether the new request is actually in scope. Someone has to weigh the hours used against the approved budget. Someone has to notice a dependency putting the launch date at risk before the date arrives. And someone has to have the hard conversation when what the client wants, what they can spend, and when they want it no longer line up.
That is what I mean by owning the outcome. The developer owns the technical work. Project ownership is broader. It covers scope, timeline, budget, communication, priorities, dependencies, risk, and whether the client gets what they expected in a way they can trust. That sounds obvious written down. In practice it is spread across several people, and that is where projects drift. Nobody ignores the budget on purpose. Nobody intends to surprise the client two days before launch. It happens because everyone owns a piece while no one is responsible for keeping the pieces aligned.
Good developers should not have to solve that by becoming part-time project managers. Strong project management gives them more room to do the thing they were hired to do well: they build. The project manager handles the connective work, the hundred small decisions that determine whether a technically successful project also feels successful to the client. When that role works, the improvements are quiet. The project just becomes easier to understand. Dates mean something. The client knows what is happening. Scope changes get discussed instead of absorbed. Budget conversations happen before there is a problem, not after.
None of that is as exciting as a new feature. It is also what makes repeatable delivery possible. That is why project management deserves a deliberate seat in the FileMaker world. Not because firms need more ceremony, but because somebody has to own what happens between the first client conversation and the moment everyone agrees the work is done.
In Part 2, I take that up a level. Owning one project is one thing. Building a company where that ownership happens on every project takes a system.
