coneblog

I was under the gun to do a fixed price estimate for a poorly-defined system in one week.

I wasn’t completely in the dark, though. I had the set of paper forms used in the existing process. I had the current set of reports. I had the cost models from prior successful projects for this Client. So I started with the cost model.

My methodology for job estimation of smaller jobs is the same now as then – I used a Task and delivery-based cost model that I worked up in Excel. My experience is that smaller software jobs are generally not constrained by task dependencies. The process runs basically sequentially, and the projected end data doesn’t depend on cross-connections between the projects. And I don’t worry about staffing mix.

I don’t bring out MS Project and start building dependencies and staff rosters unless the project is organizationally complex, large, or relies on a number of delivery threads.

So I brought out the Cost Model from the last job to familiarize myself with the Phases and deliverables. Here were the Phases:

1. Administration/QA
2. General Design Specification – deliverable is a GDS
3. Perform Application Development – deliverable is an integrated system reviewed with users
4. Detail Design Spec (as built) – deliverable is a DDS
5. Factory Acceptance Testing – deliverable is a completed FAT at the Factory (my shop)
6. Installation, Training and Support – mostly support of the Client installation team, plus User and Operator Manuals

All in all, one part code to three parts paper. An interesting feature of working in this environment is that you create the Detail Design Spec from the completed system, not the other way around. For a “Validated” system in the Pharma environment, you need a delivered system that exactly matches the design spec. The easiest way to do that is to capture screens from the completed system!