Things that make a project succeed

[swatts]

Happy New Year!!

(People who follow the Gregorian Calendar)

Towards the end of last year I did an article on 12 things that make a project fail so for balance here's some things that will help a project to succeed.

These are not in particular order.....

Process

Have a process, declare it, develop to it and improve it.

That way your customer knows how you operate, your developers know what you expect from them. If you go into a project without a process it will be haphazard and the more complicated projects will really struggle. If you are employing contractors, you should ensure that they understand your processes. We have seen several projects that suffer because developers are poorly selected and just thrown at a project with little else but a list of requirements (incomplete)

Tenacity

For me, the hardest part of any project is finishing it off. But this is actually the most important thing, I know it sounds ridiculous but we've made a pretty good living recovering abandoned projects. One key personal attribute for this is tenacity.

• Do not give in when the hardware doesn't work as expected.
• Do abandon a project because it is no longer cost effective.
• Do not quit when your software is a bit flakey.
• Try not to allow your personal problems affect your output.
• Do not start a more interesting project before doing the hard bit of signing off existing projects.

All of this is a lot harder than you would think, but it is important if you're in this for the duration. Because abandoning projects is very, very bad for customer relations!

Not all projects go well, we are in the business of prototyping and bespoke software is difficult. It's why we charge the $$$$. Your customer should know if you are putting in the hard yards and often they appreciate it.

Experience

You will likely as not suffer a failed project by assigning 6 newly qualified CLAs, straight out of university, with no prior project experience, to anything complex.

If you  assign a team of engineers that have successfully completed other projects, it will probably succeed.

Managers generally struggle with this concept and I have seen quite a few new LabVIEW engineers put under unbearable pressure because their company has paid for the training and LabVIEW is easy! I've also seen multi-million dollar projects nearly fail, because the organisation has just employed anyone with the word LabVIEW on their C.V. (actually it would probably be typed Labview).

Methodology

There is too much discussion about how one methodology or another is better. The truth is that any methodology is better than none, a methodology your developers are comfortable with is an extremely valuable thing.

One thing I would add that your methodology needs to be able to cope with changes at the end of the project.

Open and Honest Communication

• Keep your customer involved in the project.
• Tell them if there are risks.
• Tell them if you are struggling.
• Do not lie to get the work.
• Do not keep silent if you are unhappy about something.
• Do not promise what you can't achieve.

This has the added bonus of making your life less stressful!

Good Customer

A healthy social life involves surrounding yourself with people that make you feel better and jettisoning people who make you feel crap. Business is usually a social activity and the same rules apply.

A good rule of thumb is that if the Accounts department are pleasant and pay you when they promise, then the company is usually a good company.

This relationship is conducive to project success.

Good Hardware

Hardware costs are usually a very small part of the life-time costs of the system as I discussed here. Hardware that can easily satisfy the requirements at a projects inception and has the ability to be expanded will vastly improve the chances of project success. Second-hand, under-powered and under-specc'd equipment will add a significant risk of failure. 

Risk Management

Talking of risk, your process should always push risk to the front. Always, always, always. This can be uncomfortable and natural human instinct is to get instant gratification by doing the easy stuff first. So if you suspect that the users requirements are not being expressed, then supply prototypes. If hardware issues need solving, solve them first.

A company fairly local to me had fully sorted it's CI method (Continuous Integration), bought loads of PXI racks, fully loaded with gear and then failed to deliver a single working test system, because no-one had actually built a prototype and run a test. Even after all my years in the business this still made my jaw hit the floor.

These points are pretty obvious, but it's sometimes good to have them in one place.

If you can think of any more, chuck them in the comments

Lots of love

Steve