Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

12 Things That Make Projects Fail

Active Participant

Happy Christmas Christians and Happy Holidays non-Christians

I've done enough language stuff for the time being, it's time to look a bit closer at a subject that is far more interesting to me.

LabVIEW projects are getting bigger and more complex, generally SSDC is now working on distributed systems, large database enterprise systems or control systems. NI is wanting to sell system level hardware rather than single boards. All this means project failure can now impact on peoples jobs and company profitability.

I have referenced the Standish CHAOS study in presentations before and a quick look at the graphs will tell us that any improvement observed from 1994 to 2010 is marginal, statistically I would say that any improvement is within the general variance.

This is interesting because I am constantly inundated with propaganda promising me a brave new world of software development.

The take-outs from this are LabVIEW projects are getting more complex, and I would expect these complex projects to begin to follow the findings of the Standish CHAOS study.

If we now look at these two videos by Steve McConnell (If you don't know who he is then look him up!)

This webinar looks at case studies of 4 projects ranging from embarrassing failure to great success and the 4 judgement points are a nice simple way of evaluating a projects chances of success.

If you've not bothered to watch the video the 4 factors are Size, Uncertainty,Defects, Human Factors and how you manage each of them affects project success.

This next video is in a similar vein but looks at some common graphs associated with the software development process.

40 minutes in StevieMac (as he loves to be called) discusses human variations and it is a stunning bit of study.

Again if you couldn't be arsed to watch the vid, the spoiler is that human variations affect a project by factors way greater than methods or processes. So as an example filling your Agile team with idiots is likely to lead to failure.

1. Complexity

Sometimes a project is JUST DIFFICULT! The likelihood of failure is greatly increased as you add function points to a project. If you have trouble defining a project or you just can't picture the design in your head I reckon it's a sure sign you have to put some hard miles in up-front.

2. Bad Judgement

As was shown in the 2nd video sometimes a project will fail just by intelligent people doing stupid things, in the case of the various medical failures it was bad business as much as bad software engineering. It's well worth understanding the financials of a project before you begin.

3. Lazy Estimation

If you are fairly professional you will have some very busy times (being professional is a really attractive sales technique). It can be very tempting at those times to take a bit of a punt on the estimate and often you will be caught out in spectacular fashion

The general rule in our business is that we very rarely make what we expect to make on a project. I would hazard a guess that we're not alone on this. What is the percentage? well taking the CHAOS report terminology I would say the the majority of our projects could be classed as challenged, very few fail (I think we've had one canceled and this was essentially political). How were they challenged? The majority would be late for a variety of reasons, generally it's over optimism! Very few would lose functionality. This is all indicative of poor or lazy estimation. For us it is mitigated by sticking rigidly to fixed price, absolute openness and early release of useful code.

4. Lack of Experience

I touched on this subject in Damn! My Silver Bullet Appears To Be Made of Crap. The graph showing how experienced teams have vastly improved productivity over inexperienced teams in the second video backs up my feelings here. That doesn't mean that a team should only contain gnarly old gits (SSDC defined), but often employers are less than discriminating when employing LabVIEW programmers. That poor decision is often the foundation of a failed project.

Experience gives you the flexibility and resilience to change that most projects need.

NOTE: Qualification <> Experience

5. Lack of User Interaction

One of the most best bits of the Agile Manifesto is this

"Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software."

We need to understand that the industries that most benefited from Agile processes were not actually delivering software to customers at all. The simple expedient of showing the customer stuff on a regular basis was deemed to be a huge breakthrough!

If you are not doing this with LabVIEW you really are in the wrong game!

6. Inappropriate Cost Saving

I discussed this in The Cost of Failure Article. The only addition could be applied to the people doing the work too, in any engineering discipline paying peanuts really does mean employing monkeys.

7. Politics

You could be happily working away on your project and management change everything. We've also had projects that were designed for a nefarious purpose (in our case to extract processes from the shop floor so the factory could be closed and shipped abroad).

8. Dishonesty

Saying all is going well when it isn't is dishonest, similarly agreeing to unattainable delivery dates to win a job. Customers generally have fairly simple requirements with regards to projects, they expect you deliver what you you say you're going to deliver, when you said it would be done. Getting money for a project is usually a one-shot thing, going back for more money is incredibly difficult for all involved and is bad for customer relationships.

9. Offloading Responsibility

Quite often we find the customer expectation to be that not only do we design the software, we are expected to generate the requirements, specify the equipment and we have even been asked to redesign the customer hardware. In this type of job you need to be very sure of your ground because you are going to be taking all the blame.

The healthy situation is that the customer has the domain expertise and can communicate these as part of their requirements and feedback. Jobs are far less risky in this environment.

I've added Pascals comment into the main text as I think it more eloquently describes one of the points I am trying to make.

PascalHeinen wrote:

I also see this phenomenon in projects and I think that if we generate the requirements the costumer is less involved/impressed/excited about the work that is done. Because of him not having to think requirements through, he will change requirements if problems arise, just to move on with the project. Which leaves a bad tasted in my mouth.

10. Too Much Belief in Silver Bullets

This is a bit like self-help books that try to convince you that you're the most important person in the world and sheer force of positive thinking will make everything OK. It won't and probably the worst thing you can do to a complex project is add new processes or tools to it.

11. Inappropriate Design

If it doesn't fit the problem it's probably inappropriate. A large proportion of the jobs we rescue have had an unsupportable or just strange architectures applied to them. Similarly if the solution is radically more complex than the problem it is a sure sign of poor architectural decision making.

12. Trying New Things

An important, risky and time constrained project is probably not the best time to try out that new process or architecture. Essentially self-learning shouldn't be done on a customers paycheck (unless declared) and it also increases risk. A better way is to allow enough resource to attempt new stuff on internal projects or discuss it with your customer, sometimes they are willing to take the risk if there is a tangible benefit.

One reason I like fixed price work is that it forces you to analyse risk well and to then push these risks to the front.

I'll leave with a motivational poster to set you up for the new year.

WP_20141101_001.jpg

See you at CSLUG on the 17th if you're attending.

Very Much Love

Steve

Comments
Member

Hello Steve,

Thank you very much for another amazing rambling!

I have a question about Offloading Responsibility. You mentioned that you preferably work on fixed priced projects. How do you combine this with offloading responsibility? What if you discover that the customer expectation is that "not only do we design the software, we are expected to generate the requirements, specify the equipment and we have even been asked to redesign the customer hardware"? Are you hesitant to accept these projects?

I also see this phenomenon in projects and I think that if we generate the requirements the costumer is less involved/impressed/excited about the work that is done. Because of him not having to think requirements through, he will change requirements if problems arise, just to move on with the project. Which leaves a bad tasted in my mouth.

Hope you understand were I'm getting at. Is it better for us to select costumers that know exactly what they want (if we have the luxery to do so)? Or is it part of our fast evolving job that costumers expect us to do this stuff more and more and we need to learn how to deal with it?

Thank you

Active Participant

Why thank you Pascal,

I agree wholeheartedly with you comments and we're currently working on a job where a customer is expecting us to come in at the end and sort everything out for them. We have a spec. full of TBDs and they are not responding to our queries. Delivery end Dec 2015. The correspondence is currently as follows....

Us: Can you tells x,y and z

Customer (after a week of silence): It has to be delivered end of Dec.

Us: Can we have some hardware?

Customer (after a week of silence): No it won't be available until end of December, oh and it needs to be delivered then too.

Us: Well it won't because of x,y and z

Customer (after a week of silence): It has to be delivered end of Dec.

It's fairly safe to say that this project is not going to be a glowing success and we will not be rushing to do more work for them.

PascalHeinen wrote:


                       

I also see this phenomenon in projects and I think that if we generate the requirements the costumer is less involved/impressed/excited about the work that is done. Because of him not having to think requirements through, he will change requirements if problems arise, just to move on with the project. Which leaves a bad tasted in my mouth.

I would like to take that paragraph and add it to my article, I think it sums up beautifully one of the issues.

As an actual answer it is less risky to select a customer that knows what they want and have domain expertise.

But RISK = COST

You can mitigate some of the risk by increasing contingency if you can identify those risks up-front. Hopefully by talking about them we can better recognise them earlier, ideally at quoting!.

I think there is also some discussion about pricing and contingency to come.

Member

Hello Steve,

It seems we have the same costumer Your description of the correspondence is exactly what I meant in my paragraph. Please feel free to add it to your article, I would be honoured.

I'm really looking forward to the discussion about pricing and contingency, this is getting more and more important in my opinion.

Thank you Steve and merry Christmas.

Active Participant

And into moderation it goes!!!

Active Participant

These are the sort of articles I find myself referring back to often, thanks Steve!

I have also recently noted Pascals point that I was not expecting when I started this. I have several projects where the customer doesn't really have a vision or requirements mapped out, expect you to figure them out, and they are always the least happy at the end! ("I thought it would work like this", "well you probably should have mentioned that!")

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
Active Participant

I know I have referred to the Steve McConnell stuff before, but I really feel that a lot of the process stuff regarding software development is monetised to the point of uselessness. Whereas there is a lot of common-sense project management and good engineering practice that people aren't exposed to because it has no fancy buzzwords, books etc. Construx are somewhat guilty of this, but the heart of his stuff is sensible, clinical observation.

I'm actually hearing about projects where people are applying all the latest buzzwordy techniques and expecting that to be enough. Sadly you need experience to navigate the obstacles mentioned above.

In service led countries solid technical experience is hard to come by, and we will be dealing with more and more customers like these, so get those strategies in place!