Link to FSA Organizer: http://29r-03.com

This was a very fun project in the area that I had no idea in the beginning - construction delay forensic analysis.

After hearing Construction Delay Analysis 101 for about an hour, I came home with a document called 29R-03. It is one of many recommended practice documents published by AACE International, covering various analysis methods and proper implementation recommendations of them.

The industry's problem (that I was told) was that even though 29R-03 was published, it was not followed well by the industry. It might have been due to its controversial content (especially early editions), or because it is just not easy to follow through. You have to read entire document before you know which methods are applicable to your situation. How can we help it with software?

We went through several meetings and wild ideas, and one day we found this is very similar to how we treat taxation. You pay tax, right? Then how many of you read through IRS publications? I haven't. But thanks to applications like TaxACT or TurboTax, we don't have to read them all. The software will ask me questions that only I can give answers, then it will produce tax report that I can send to IRS. If taxation can be resolved this way, surely 29R-03 can.

All we had to do - other than writing software itself - was to list all the questions, and group them by topics so that the questionnaire can flow well. And that was not easy either, since there were 100+ questions and each question can have multiple related topics. After trying the task with Excel for a few days, I ended up using sticky notes.

It was interesting to learn how sticky notes on the big whiteboard were much more representative than Excel. I made a note for each question, and drew areas for groups. Then I could put a note in the group if it belonged to one group only, or use distance to represent how much related a note was to each group. Of course I couldn't use Ctrl+F to find things on the whiteboard, but I found myself way better at memorizing each note when they were on the board, compared to when they were rows in Excel.

Another issue was 3 distinctive use cases that were very similar in core.

1. Lawyers could use it to question the lawyer's analyst or opponent's analyst.
2. Analyst could use it to see which methods are on the table.
3. Analyst could use it to validate a method in mind against 29R-03.

Implementing the workflow didn't seem to qualify as "simple design" as in Agile SALT, so we went through yet another around of several meetings and wild ideas, and found a way to solve this nicely.

We thought through each use case's workflow and identified common area among them, and implemented that portion only. That way, the software became a tool that you can use on all of the three scenarios, and stay simple. What is not covered by the software were workflow related functions, which did not need to be covered by the software.

The outcome looks so simple, but as always, it took quite some effort to get there.