I do have an advantage, I've been doing design for a long time
The first stage and often the hardest is capturing a
good requirement specification. I believe the customer should be in the loop and working on the problem too, and that there be a good balance between creativeness and evolution. Also the art of getting the compromise right between what the customer thinks he wants, and what I think the customer wants.
Quite often in my experience, when lesser experienced engineers are doing that, they take a written statement from the customer and then interpret it exactly to the letter (including typos), over-literally. It all becomes too 'contractual' too early on in the design lifecycle, stifling out the creativity and the project resembles a train on the wrong track. If there's any discrepancy in the information, the lesser experienced engineer just out of school does what they think the customer wants, going all 'isolationist' as though they know better. Or you get requirement specifiers compete with one another, trying to get in at the earliest they can in a new project so they can have more control, then the detailers pick it up and complain about silly choices made too early on.
Yes, getting a dialogue going, does wonders doesn't it?
Looks like there's a good requirement spec evolving for PICies to pick up on. I say this a doddle for a PIC Geek to do. As for the "day counter" function (that you were seeing a servo for), there is a non-volatile memory (E²) in a PIC to do that.