RiC#Code

When projects fail, people often think:

• we didnt have enough resources
• we didnt have enough time
• we didnt have the right tools/technical knowledge

This is the real reason why I think most IT projects fail:

Why? Because clients usually don’t know what they are asking for, and need to see the possible end-result before they know something about what it is they are talking about.

If you continuously show the customers, what it is that they are asking for, they will work WITH you to get what they want, no need to be over protective and patronizing about the fact clients don’t know about technology, their job is to want something, its a collaborative work to learn together, both developer and client, how to write down the client’s wishes in a way that will produce a happy ending.

Main point being:

• In requirements gathering: ask stupid questions.
  • Ask WHY
• Prototype, refactor, show & tell, repeat

Should seem common sense, but you would be surprised how many times people don’t ask “WHY?”, because it would seem silly!

Asking what would appear to be stupid questions (or even embarrassing questions to some) is the number one priority in any project as far as I can tell!!

Its learning to walk before you can run, and FIND OUT if you really need to do x,y or z, it also helps you keep an eye on the end result!

Some people will start a project just to have something to do.. don’t be too surprised to see that its those people who greatly contribute with the 60% or so margin of project failures in software development.

Do something for a reason, other than avoiding to be idle!!

I you do engage yourself in doing something (for someone) and you don’t ask WHY, congratulations! You are like some project managers I have had to work with in the past, who, when the project fails, would then quite happily use the initial 3 bullet points as the reasons for the failure of their projects.

Projects that may succeed even under a no “why” questions asked mentality:

• self serviced
  • you don’t have to ask because you are feeding yourself, these CAN be successful, but if you think about it, even in this case you would greatly benefit from asking yourself those same questions before you start going on a D. Quixote mode to self servicing idiocy, performing tasks that could be avoided or addressing needs more efficiently.
• projects without a success metric put against them
  • These can succeed even when they fail, because no one can actually tell what’s going on. These projects not only exist, they thrive!

How can asking WHY help with saving a project?

If you know why something is being done, its easier to work defensively and preempt caveats, suggest alternatives to the ideas given etc etc

There is another huge failure benefactor:

Once the ill conceived requirements gathered from a “lets not ask stupid questions” mentality is finalized and written in stone, that same kind of project manager will try to push on and move a project forward JUST to meet the requirements which in fact are non satisfactory (or worse, not necessary).

Its exactly because different wishes need to be written differently, that the process of requirements gathering becomes too elusive to even the most experienced project manager.

Pushing on in trying to implement wrong requirements, without paying attention to the CURRENT needs of the end customers (something that should be done continuously) means wasting good time money after bad.

There is absolutely no point in saying the “that’s what the spec says” , yes you have to follow some pointers, but these need recalibrating, readjusting and rethinking continuously!!

The customer is always right! right? They pay the bills, or the bills are paid thanks to having someone happy with what you have to offer!

If the product does not do what the customer wants, they will not use it..If they don’t use it.. you get my point. (I hope)

There is a related thought process currently named: Agile, its all about keeping in touch with your customers, and being ready to change. (and being quick about returning something for evaluation)

If I understand it correctly: Agile is about having you have the customers change the requirements AS YOU GO, and do this with you, not against you.

But I want to keep the focus on the importance of asking questions:

• http://www.theregister.co.uk/2007/06/25/thoughtworks_req_manage/
• http://wiki.github.com/aslakhellesoy/cucumber (saw it here)

“There are no stupid questions, just inquisitive idiots.” Ask away.