ARTICLE
How does a custom system rollout actually work?
A custom system goes through six stages between signing and launch, and the slowest is usually not writing code but pinning down how the work is done today. This article covers what happens in each stage and what the client needs to put in.
The short answer
A custom system rollout has six stages: process interviews, specification and prototype sign-off, phased development, internal testing, data migration and training, and post-launch adjustment. The slowest part is not writing code but the first two stages, which get a complete picture of how the work is done today. Projects that give those two stages the time they need almost always run more smoothly afterwards.
What happens in each stage
1. Process interviews
We interview every role that will use the system, not only the decision maker. For the same process, the version a manager describes and the version the front line performs are often different, and the system has to fit the second one. During interviews we ask people to open the Excel file or paper form they use now, because those fields usually carry rules nobody states out loud but the work depends on.
2. Specification and prototype sign-off
After the interviews we produce screen prototypes and process diagrams so the client sees the shape of the system before development starts. Changes cost least here: adjusting a screen means editing a drawing. Raised after development, the same change is rework.
3. Phased development
We do not wait until everything is finished before handing anything over. The core process is built and accepted first, then the surrounding features. The benefit is that if we misunderstood something, it shows up in the first batch rather than at the end.
4. Internal testing
The development team tests whether functions work, and the client tests whether the work flows. Both are necessary. We provide a test environment and test data so real users can run through a realistic round of their own work.
5. Data migration and training
Old data is usually in worse shape than expected: duplicates, gaps, inconsistent formats. We run a trial import first and list the problem records for the client to decide on, then migrate for real. Training is organized by role, so each person only learns the part they use.
6. Post-launch adjustment
Launch is not the end. Details that no interview could surface only appear once the system is in daily use. We treat the period after launch as part of the project, not an extra service.
What the client needs to put in
- One contact who knows the process and can make decisions, so requirements do not bounce around internally.
- Enough time for the interviews and prototype sign-off. This is the highest-return part of the whole project.
- Early tidying of existing data, especially anything meant to be migrated into the system.