That last 5%

jjames

So I've got a question for everyone: how do you overcome that last 5% of a job? Is it more, or is it generally the last 5-10% of a job that just really drags? Do you have a routine that you follow to get that last portion of the job finished? Or is it all out guns blazin' just trying to get it done?

For me I try to follow a routine of just going through every single button on the touch panels / keypads, and thinking of ways that no one would think to hit a button and try to confuse it.

ericmedley

whooboy! that's the million dollar question.

We try to have someone not involved with the project go and bang on the system (every button) to find flaws. In most cases, they will find a few things. We have really been beating the drum of standardizing everything we do to try and get hold of all the 'reinventing the wheel' stuff we can.

In our case, I can tell you that the last 5% always seems to be the client finally getting the thing in their hands and then them tweaking things that they didn't expect to turn out the way they did.

The most painful thing for me to hear is, "Gosh, I just spent all this money. You'd think the thing woudl do such-and-so." No amount of showing them that the thing they're thinking about is not in the project scope, not in the desired specs, or in some cases, not even possible with current technology, seems to quell this.

Our biggest challenge is the endless service calls that seem to come in the last stage that are in reality just user error or should in reality be change orders. Lutron lighting is the worst for us. No amount of preparation seems to get the client ready for what happens in reality.

I say all this, but in truth, our clients seem to be pretty happy with their new toys. It's more frustrating for us than them.

a_riot42

The last 10% of a job used to be time-consuming especially with the testing of buttons, but since switching entirely to modules, I know that if one button works they all do and this has brought testing time down to almost nothing. The only things that need to be tested are the weird one-of stuff that is usually pretty quick to do since there isn't much of it.
Paul

jjames

Yeah, I'm switching over to modular programming, and using DEV arrays so that an unlimited number of panels can execute specific code, but is also dependent on other device mapping as to what actual device it needs to control (if that makes sense.) That has cut down a lot of time for us, knowing that (like you said) if there's a problem, it'll be widespread and if it works, it SHOULD work across the board.

Still - that last 5-10% is just a pain . . . just seems to drag on.

DHawthorne

I try like heck to get one of my guys who has never seen a line of code to go through it. I tend to develop a certain tunnel vision that prevents me from even thinking of ways to use the system outside of the way I designed it, and often completely miss gaping holes.

Colzie

DHawthorne wrote: »

I try like heck to get one of my guys who has never seen a line of code to go through it. I tend to develop a certain tunnel vision that prevents me from even thinking of ways to use the system outside of the way I designed it, and often completely miss gaping holes.

If one of our design engineers is on site I'll have him run through the panel. They are pretty good about doing a thorough job.

If they aren't on site I'll have one of the installers take a look. The problem with that is it can be hard to get them to understand that I WANT them to "break it". Usually they'll poke a few buttons and say "yep, looks good".

It takes a certain mindset to completely run through a panel properly.

a_riot42

DHawthorne wrote: »

I try like heck to get one of my guys who has never seen a line of code to go through it. I tend to develop a certain tunnel vision that prevents me from even thinking of ways to use the system outside of the way I designed it, and often completely miss gaping holes.

That's true, but I also find that only the programmer is going to be able to test the things that they feel the programming might be a bit sketchy on. The programmer who knows how its programmed can test for the corner/edge cases that might not work, but require a very specific operation to trigger.

What I tend to do is do all my testing myself checking the corner/edge cases, and then give it to a tech or someone else to check the 'typical user' bugs.
Paul