Pre-Programming Documentation

screenscribe

Hey everyone. I'm starting on my first AMX project this week and wanted to ask what documentation you guys normally expect to receive from a client before starting to program a new system? I was provided with a line diagram, an equipment list and a brief summary of the room. Is this pretty standard documentation?

Also, do you guys normally get touchpanel notes from a designer beforehand (assuming you're not doing the touchpanel design yourself)?

Cheers,
Matthew

DHawthorne

I'm typically handed a room-by-room equipment list and a summary of what the system is expected to do (an equipment list, for example, won't tell me if they want a weather page on the panel, or if the panels will control multiple areas, etc.). I'll generally float a few panel designs by the client for their preference, but often the salesman just tells me what template to use and I'm on my own to fill it in and design the appropriate navigation. Since we do everything as a turn-key solution, I'm getting this documentation from sales, not the end user, and I can confer as much as I like to clarify things.

ericmedley

Another good thing to have is a general outline of the user interface design. This can be as simple as a flow chart scratching out how the navigation will lay out.

We have a whole process for this. I usually get architectural and schematic drawings, engineeiring drawings, a scope of work and rough schedule. We too have a fairly established user interface that doesn't vary much in concept. The graphics change, but the general layout and navigation do not.

screenscribe

Thanks for the responses, guys. I really appreciate it. It's good to see how different organizations manage the process.

fogled@mizzou

None.

I expect to get told, verbally, about 40-60 days before a project is expected to be done, that the client "wants a system." I have to make up the rest as I go along - including equipment specs, ordering, programming, panel design, and significant portions of the physical installation. The information conduit between me and the people who will use the system is usually either nonexistent, or so slow and inaccurate as to be useless.

In some ways it's incredibly frustrating when I miss the mark due to poor communications, but in other ways it's totally cool to have so much variety in a 'sandbox' kind of job.

ericmedley

fogled@mizzou wrote: »

None.

I expect to get told, verbally, about 40-60 days before a project is expected to be done, that the client "wants a system." I have to make up the rest as I go along - including equipment specs, ordering, programming, panel design, and significant portions of the physical installation. The information conduit between me and the people who will use the system is usually either nonexistent, or so slow and inaccurate as to be useless.

In some ways it's incredibly frustrating when I miss the mark due to poor communications, but in other ways it's totally cool to have so much variety in a 'sandbox' kind of job.

What??? You didn't see the 'mind reading' clause in your job description???

I guess I missed it in mine too.

jweather

ericmedley wrote: »

What??? You didn't see the 'mind reading' clause in your job description???

I guess I missed it in mine too.

This is the part that seems to be the hardest for me to get across to sales. "Okay, yes, I see the complete equipment list here and the system diagram, but what do you want to *do* with this system?" Especially as the systems get more complicated, there are just too many different things that the system could be used for.

fogled@mizzou

jweather wrote: »

... what do you want to *do* with this system? ...

LOLZ! Mine is always exactly the opposite: in EDU, all I ever get are ideas about what people want to do with a system. These ideas are completely un-encumbered by any thought process, and only partially covered by the budget process.

At least I have a fairly narrow market to learn, and I am learning it, bit by bit, install by install. I especially learn a lot during the inevitable post-install functionality re-alignment work. That's when I finally get to actually talk to the users and watch them interact with the system. And re-program it so that it does what they really need (within the constraints of the cheap equipment that was budgeted for the job).