The importance and possibility of trust

Dear Bob …

I read your Advice Line post, “Problems with project estimation,” (2/5/2007), in which you stated that trust is a precondition for successful project estimation and execution.

Trust? TRUST?!?

No one trusts the IT guys in the room. They make more money than the business people, and business people always think IT projects take way too long. The business people want something, but don’t have time tell you what it is once, let alone being part of a project every day. I can almost never get a single room dedicated for a project.

I can’t start by asking how the business operates, I will be laughed out of the room, or my boss will be asked to get someone who knows the business already.

Trust? Companies will out-source IT in a minute. You have to provide a service, fast and accurate, and then move on to the next thing.

…and I agree that estimating is often useless — try estimating the requirements, let alone the actual development — but people want to know what its going to cost, because they have options like buying a package, or cloning something from another part of the mega-corporation. So avoidance is not a solution.

…and unless you get the business people on the project, participating every day providing needs and feedback, then you are going to need those documents, because the development work might be shipped overseas before you know what happened.

Sorry, but that’s the truth.

– Distrustful

Dear Distrustful …

Huh. I thought it worked that way. Maybe it’s because, when my consulting company, IT Catalysts, works with clients that have dysfunctional IT organizations, one of our top priorities is to find ways to reestablish trust between IT and the rest of the organization.

It can be done, and yes, it is that important.

The folks in IT earn more so they can’t be trusted? Last I looked, trust wasn’t dependent on equality of compensation. IT projects take longer than business people would like? Sure they do – so do construction projects, product development projects, and just about every other kind of project. That doesn’t automatically result in distrust. It can, and often does, especially when IT says, in effect, “Trust us – it has to take this long.”

It certainly does when IT fails to involve its business partners in the estimation process.

You say business people want something but don’t have time to tell you what it is? That’s the heart of my point: You shouldn’t ask them what they want. When I’ve asked how a business collaborator wants to change how the business operates, I’ve yet to hear any respond, “What? You don’t know?”

Sometimes they do sound surprised that anyone in IT has any interest in the subject, but that’s because we’ve conditioned them to expect questions about how they want the software to operate. We in IT are supposed to be the experts in what software can do. Our business counterparts are supposed to be the experts in how they want to run their business better.

That’s why they should be involved in projects of any size, every day. The projects aren’t IT projects in the first place. They are business change projects. Of course business people should be involved.

The only way we’ll get to a sound design is to collaborate, with software engineers helping their business counterparts envision a new way of operating while business participants make sure IT’s view of the business is realistic, not oversimplified and idealized. That requires trust. The surest way to build it is to expect it. The surest way to destroy it is to assume hostility is the natural state of affairs.

I won’t claim that’s the truth. I don’t have access to the truth.

The best I have is my experience. That tells me this works, and works quite well.

– Bob