LabVIEW Life Lessons #2 - Delivery is all

[swatts]

Hello Sourcecode Sweeties

Here's the second in my series of short articles, each one will be about something that we've learnt over many years of writing industrial software.

It's all about delivery.

Strictly speaking this should be #1 as it is the foundation of everything we're about.

As it's clear from the discussions here we take a rather contrary and brutalist approach to LabVIEW and project management. The reason we have the confidence to take that stance is that we DELIVER. It's actually very difficult to argue against.

And before anyone says it, we don't just do easy projects. In fact a reasonable percentage are given to us because they have gone terribly wrong (we call them rescue jobs).

I guess you'll be more interested in what the secret to delivery is.

1. Tenacity

Projects can be tough, this week I started out with 2 projects and both had hardware that wasn't working. I could have thrown my hands up in the air and got frustrated or knuckle down and solve the issues. By Friday everything was working and once again my Engineering Ego is recharged.

When a fixed price job goes wrong, the hourly rate reduces. A sound business case is to walk away from these jobs. That sucks! Try to avoid doing this.

2. Checklists

One of the best aids to finishing a project is a checklist of work, it can be ticking off requirements, or tests or even open issues. If you find yourself stalling on a project, make a list of things to do and pick a couple of easy ones and a difficult one. One of the nice things about some of the formal Agile techniques is concentrating on a manageable list of tasks in a set period of time, it's very powerful.

3. Character

Are you a starter or a finisher? Be honest do you really love the start of the project, all the fun bits are the early design and customer interaction or do you love the feeling of satisfaction you get from signing off a project.

I'm about here...

10 years back it would have been 80/20 in favour of starting, so perhaps finishing on projects improves with experience.

4. Teamwork

If you are a flakey artistic type it's likely you'll be good at starting, but poor at the more detail oriented tasks related to finishing. The cure? Find someone to do the finishing for you. This can be a colleague or even a customer. One of our customers has a vested interest in detailed testing of our code and he's really good at it. In my opinion we make a good team.

Within SSDC we support each other, so when a project becomes challenging we know that there is someone there to talk it through with. Sometimes it's just nice to have someone to share the responsibility.

5. Experience

Alluded to this earlier and research has backed up that teams that have a history of delivering will most likely continue to deliver.

So remember: people won't remember that your software is clever, your unit tests are well organised, your methodology is bang up to date, you're really highly qualified and you have fantastic documentation. But they will remember if you take a lot of money and don't deliver anything.

Here endeth the lesson

Steve

[Thoric]

Great article. Some comments, if I may:

1. Tenacity - totally agree. I find that my level of engagement in a project directly relates to my ability to tolerate any problems. When I get bored, I struggle to persevere with hardware issues and software bugs. There's nothing better than pressure to make you more engaged - ie knowing your salary is dependent on a successful delivery.

2. Checklists - this is something I often fail to do. Some days I finish, think back and struggle to enumerate what I've acheived. I know I've been working hard all day, but if asked I'd wouldn't be able to describe my day very well. I have before created lists of tasks, striking them out through the day, and when you get to the end and see the post-it note all scratched out you feel much better about yourself 🙂

3. Character - I'm an inventor (of sorts), a designer, an engineer, an artist. Therefore I'm also a Starter! I love conceiving solutions, designing the code architecture, watching the components grow into working solutions, creating early releases and seeing it all work. The last bit - that final 20% - is always hardest. The documentation, the thorough system-level testing. Again, there's nothing better than a bit of financial pressure to get you to keep your engagement and complete the work. Just gotta hope nothing more interesting suddenly lands in your Intray before you're done!

4. Teamwork - Get the customer to do the testing? Are you sure? I once had a customer that created a validation sheet, a list of proving steps we would go through after delivery to prove the solution was good and met their requirements. I took that validation sheet and made absolutely sure my software worked before I delivered it. There's no way I'd give the customer software I hadn't tested if I could test it first. You'd a need a very good relationship with that customer, and probably a discount on the quote, if they were going to perform your system level testing for you. As for using someone else within your own team - I wonder how many of us are lucky enough to be working with fellows able to do that, like yourself Steve? Not a criticsim, I'm genuinely curious as to the rough ratios of lone workers to team-based workers.

5. The last bit "they will remember if you take a lot of money and don't deliver anything" is a very valid point. But also, if I might paraphrase a little "they will remember if you take a lot of money and deliver a poor solution". Deliverying everything perfectly is something that won't necessarily impress them, afterall that's what you promised anyway. But under-performing anywhere will be the one thing they do remember, and the one thing that comes up in conversations with others about you. You've got to get every aspect right.

As an example, a colleague ordered some bespoke benchtop hardware from an external engineering firm. It had multiple aspects including solid metal framework, worktop surfacing, dual monitor stand, four lockable compartments, computer holder, caster wheels etc. They got everything right, except the positions of the bolt holes in the top surface sheet that secure it to the frame. They had to correct them, which left unsightly oversized countersink holes around the bolts at the back. When the firm come up in conversation we always remember the "ruined surface with the misplaced holes". Not the perfectly manufactured 98%, but the little mistake on the top that most people don't even notice. It only slightly affects my opinion of them, but it's always mentioned in conversation, which unfortunately propagates a bad name. Such a tiny detail, but in the interests of maintaining a good relationship and delivering a "to-specification" solution, they probably should have made the decision to swallow the costs of replacing the worktop.

[swatts]

I think that's where the teamwork is in my thinking. Your question very nicely demonstrates a flaw in the point I was trying to put across. The solution is tested by me, the customer brings the usage testing.

To clarify a bit.....

The process is this.

1. receive an issue/bug or requirement.

2. some conversation to clarify.

3. fix and test in-house until we are satisfied.

4. release to customer for testing and approval.

The customer is best placed to test the solution against their use-cases and this is the type of testing I expect of them.

Your addition to point 5 is perfect IMO and I completely agree, the other pressure is to deliver something sub-standard because of constrained timescales. This also seldom ends well and affects your reputation.

[FabiolaDelaCueva]

---

@swatts wrote:

---

I think that's where the teamwork is in my thinking. Your question very nicely demonstrates a flaw in the point I was trying to put across. The solution is tested by me, the customer brings the usage testing.

To clarify a bit.....

The process is this.

1. receive an issue/bug or requirement.

2. some conversation to clarify.

3. fix and test in-house until we are satisfied.

4. release to customer for testing and approval.

This is what we do as well. I tell the team: The fastest we show the customer what they don't want/need, the fastest we can get to what they want/need. 

The customer might have a vague idea or even a very clear requirement of what they want us to do. It doesn't matter which one it is, they don't know if that is exactly what they want until they get to use it. So we program what they asked for, we test it in house and we send it to them to verify we are on the same page. Rinse and repeat.

This approach has worked much better than spending extra hours on getting everything perfect and meeting all the requirements only to find out we have delivered what they asked for, not what they needed.

We do multiple releases throughout the life of the project. Sometimes the release might be just for them to run the unit tests or to run parts of the program that will be eventually automated, manually. Involving the customer earlier on in testing the different components means that when we get to the integration testing it goes really fast. It also helps to keep the team members who are not that interested in the finishing part 😉 They have been finishing smaller pieces of the puzzle all along the life of the project.

Thanks again Steve for sharing with us. 

My apologies for bombarding old articles with my comments, I finally had a chance to come and enjoy my cup of tea and read your wonderful articles. Keep them coming 🙂

Fab