Fear Is Not Your Friend
I like to consider myself as a programmer. I know how to manage a project to meet times, and stuff… But i don’t like to be that guy that just yell at everyone asking for things to be done now and fast.
I prefer to hire professional people, that i know i can trust entirely. Trust is built from the ground up.
But anyway, this is not what i’ll talk here.
My way of tackling requirements
I’ve been working on a project for almost 3 years now. You could think that now it’s boring, but actually, most of it isn’t… I’m still developing new functionality and we’re still innovating, and getting that “Whoah, nice!!” from our customers…
I’ve been developing business software for almost 15 years, so, if there’s something that i’ve learned is that you cannot put words on the user’s mouth.
You need to pay attention to what the user is requesting, and understand why is he requesting that, because the implementation could be potentially very simple if you ‘get it right’. The objective is make the life easier for the end user, that is something that you must always remember… The customer don’t pay you to use X technology to make you happy, he’s paying you to solve business problems… HIS business problems!
Project Background
The problem is, that the first year the project was managed by a project leader that used fear techniques on the end users to make them say what he wanted to hear.
For example, we visited several end user, i asked some questions, and then i proposed some functionality to be built to solve the requirement. Then, this guy showed us his proposal, very different to mine, and i saw that his proposal wasn’t solving the problem.
Next, we visited again the users just trying to figure out the problem again, but now, the project leader would tell them that other users don’t work that way, and that what they say is what we would develop, so the user need to pick the project leader’s idea because if not, it will be a lot of risk that the requirement would not work on other companies.
The end-user ends up picking the project leader’s idea to protect himself and blame the project leader.
What happened next, is that the requirement built does not fulfill the problem… That was obvious from the start!, but now the project leader is blaming the end user for making that decision…
This happened LOTS of times… When the project was starting i didn’t had access to the End User, because we were outsourced just to developed what we were told by the project leader.
Over the first year, we developed the system about 3 times. And i mean, every single window was re-programmed several times. Database was changed lots of times.
The first week that i arrived, i was asked to do an accounting module… I finished it as requested in two weeks, and it was asked to be changed the week after, and toked another 3 weeks to change it.
So, now you can get a good picture of the project…
The End User’s Fear is your WORST enemy
After a year and a half, and after the project was deployed into production, the “Business Mans” started to see that the problem was the project leader. So they dumped him out.
But now, there was another problem. NO ONE wanted to make decisions.
Every user had fear to take a decision. I asked them for requirements and they didn’t talked to me clearly, because they felt that they will be judged like when the police got you: “everything you say can be used against you”…
Unfortunately i don’t see a solution anymore. Everyone is sealed now, and protecting their own interests. Up to the point that if they screw up something, they blame it on the system.
My way of doing things
That’s why i rejected the idea of using RUP or things like that before.
Once, on another project the customer told me “i know that i’ve signed your RUP documents, but that’s not what i want”… You could say “ok, but i’ve built an economic plan based on that documents”, but then we can argue all day, because the customer doesn’t want what he’ve signed.
The customer MUST BE in full trust with you, and you must be in full trust with him. In all ways, timing, work done, work to be done, and what i think that is most important, economically.
Some customers don’t value your work, and if you don’t value your work, then you’re screwed up! The customer must know that you value your work, he must know that everything you do costs money, because software development is expensive, and when i say expensive i mean it! Because you need intelligent people working on software using part of their 24-hours a day time to make software…
How do you value your time? Ok, now value your customer’s time also!
We must have a win/win strategy here, the customer must be happy with your work. And you must be happy earning money or whatever makes you happy with the project.
Just, remember not to infer fear into the end user, because he must be your ally, he will be the first to defend you when something goes wrong. Believe me, i’ve seen it happen lots of time.