>>Are there any rules of thumb, or other guidelines?

>> Do you have any business rules that work without
>> pi**ging off the employee?

>> ... measuring employee productivity of those who
>> work outside of the office?

Hi Donald:

I worked in my home for over three years and found out the following: If you are going to develop applications using distributed resources (employees or consultants) you HAVE to have a project management scheme in place at the very minimum . I think Michael hit that one right on the head. Project management means (to me anyway) that there is a central resource that is responsible for coordinating the efforts of one to many developers with regard to the tasks they must complete, in what order and finally in what time frame so the application is completed on time/on budget. Those resources have to be given definative tasks with strictly defined timeframes. That is the first piece of the puzzle ... the second piece is a detailed reporting of the offsite employee's time. This can be easily accomplished using cheap tools like TraxTime. Time expended/Time allotted for each task gives, of course, percentage completion which is a factor in your productivity question. The big problem here of course is I've seen few companies that can sit down and create a detailed/defined list of things that must be completed in order to successfully finish the project. This is usually just left up to the "team" to figure out on their own ... when the team falls behind ... it's the "team's" fault. (No, no, no ... it's the fault of a poor engineering effort to begin with). When is the last time you saw a detailed MS Project file for an application development effort that encompassed the effort required to build the entire application?

The next important part is communication, communication, communication. You have to keep in touch with them. The phone becomes your own personal water cooler ... backed up by email.

This can be done ... well ... I've also seen very respectable companies do it poorly. When things fail, it is usually the fault of poor project management skills / incomplete design engineering effort (assuming the business unit analysed and bid the project properly to begin with ... signing a fixed cost contract for $700,000 on a job that really is worth $3Million ... well ... that's another story).

The flip side to this coin was already covered by you when you talked about describing the scope over and over again to the distributed people. By keeping your team to employees you minimize this problem. However, if you ever decide to branch out you'll need to find folks that can create the software equivalent of architectural drawings, Use Case, ERD, State Transition ... any number of that UML stuff folks talk about. This helps bridge the communication gap that exists between the Analysts and the Developers.

Hope this helped in some small way.

CTBlankenship
CVI