coneblog

The Client was in a big hurry, so I turned around the software development project estimate in less than a week. The ball was in their court. So I was surprised when the Client called only two days later.

“You have the Job, but you have to deliver on the dates that you quoted,” Said the Client. No mention of the original eight week deadline. Great! We had the job, in record approval time. Now we had to deliver.

In our every Monday morning staff meeting, we put the new job into the backlog mix, and asked the two operational questions: “Who is the Best Fit for the job?” and “Who is available?” Every so often you get lucky, and the two answers are the same. So it was in this case – a Sr. Developer, a VB specialist, was available, and a Project Lead with Oracle had some time available. Just as important, our new tech writer had just come on staff, and was ready to do the pile of documentation this job would require.

So I declared the project staffed, we set up a Notes Database to hold the project, and I loaded in the Functional Spec, my meeting notes and the Project Cost Model/Estimate. We scheduled an internal review meeting, and several meetings with the Client, and we were rolling.

As I’ve stated, smaller custom efforts such as this are very dependent on proper Data Base design. My Risk Management approach was simple. Nail down the data design, get a review and a sign off, then anything much different would be a change order. This would protect us from scope changes and creep in the later stages. I’ll happily move the fields around on the screens, but I wanted to avoid additional fields or tables.

So we concentrated our analysis on the data – what was in the form, what was in the reports, and the flow of the business process. I pay particular attention to “state change” indicators in the data, often captured in some type of Status field, and usually happening at the beginning or end of a business process. Often these are obvious, but they can be subtle. Status can be imbedded in the holding, handling or routing of documents, things that will go away with the new system.

Examples of status fields are approval fields and dates, and status check boxes. Again, my focus here is to minimize risk; if you miss a status marker or type, it could ripple a lot of change thru the system when you find it. Or worse yet, you never do find it until the System goes into production, and it fails operationally because there is no way to mark a record that is in a particular situation or state