ONE THING I DON’T LIKE about working for large organizations is the moment when something goes amiss. This one requirement that wasn’t analyzed enough blows out in your face, or that bug you thought was fixed turns out to be alive and well, and all of a sudden, there are meetings, mass emails, other meetings, and yes, yet more meetings to come.

All orchestrated so that the person responsible is found. Why? If the problem is serious enough, there may be consequences, if not, the goal isn’t really finding the guilty party but making sure that everybody else is innocent. Then everybody laughs and the meetings are over, without any follow-up as to how to prevent future mistakes of the same kind.

Either you are serious about finding the culprit and teaching him a lesson, or you realize that software development is part craft and part magic and that mistakes just happen; either way, there is a point to be made. But this?

Small teams do both: they recognize individual contribution and the inevitable shortcomings of every member. Larger groups tend to focus more on member safety; there are business goals, sure, but the primary goal is keeping the status quo. After all, the company is big, so we might just as well do our 9to5 and go home.

It pays to know what your client’s culture is. When it’s an agile, lean operation, quality just might be your job #1.  Other times, you as a software developer, project manager or analyst aren’t really an IT worker but a therapist. Just make everybody feel good about themselves: that’s often what our work is about.

I’VE ALSO HAD A PROBLEM classifying the role of Business Analyst as a bridge between business and IT, but if the Agile movement says IT should understand what business needs, I am not hopeful that just being able to come up with “better solutions than the business people can develop on their own” is good enough. Either business people will never understand technology well enough or IT folks won’t get the business needs well enough; but then, there would still have to bea bridge to cover the gap.

Indeed, when BA is staffed in IT, he becomes a documentor, an interpreter, and above all a tool of IT interests.

Therefore, I am convinced a business analyst on IT projects should be a member of the business team and as such play under their colors – as their advocate. If it means going head-to-head against IT, so be it. So often the programmers know full well what the business *really* wants, and don’t do it because it’s too difficult, costly, etc.

That’s not to say BA should necessarily push all ideas regardless of their merit; as Kevin says, he should be able to propose better solutions – based on his in-depth understanding of his colleagues’ needs. He should work with requirements as every good advocate should – with his critical faculties turned on.

Technorati Tags: business analysis, software development

Johanna Rothman reminds us that testing is not a service but an integral part of development. I would go even further and say that testing is – or should be – excercised regularly at every stage of a software project, and not only there. Testing provides the much-needed touch of reality for our goal-driven activitites. That’s to say, as soon as we define goals, we need to test that they are both desirable and attainable, then devise ways to reach them and again, test them, and so forth.

When testing is left to testers, the following will happen:

• the analyst won’t bother reality-checking the requirements
• the programmer will be casual about the quality and robustness of his code
• the business folks won’t start reviewing the product until it’s been developed

It’s much more costly to change things at the end of the project that at the beginning, and it’s been the agile methodologies that have tried to answer that by giving everybody involved an early look at the product being developed. But that’s not enough. Before a project is conceived, there is a business need that’s supposed to be satisfied, and quite often its importance is sadly overrated.

The biggest tragedy of failing enterprise projects isn’t that they aren’t delivered on time or on budget. It’s that they’ve been started at all.

Sometimes, there’s too much money and too little time to think it over.

THERE’S ONE ROLE missing in all software methodologies known to man.

The therapist.

There are analysts, programmers, project managers, and of course the “stakeholders” – the people footing the bill. And they all want the thing developed, delivered, and used. Yet, come the migration time, the Big Bang roll-out, blades are drawn out and mouths get dirty and there’s yelling and ghashing of teeth.

Because no one really knows if the thing is going to work.

The uncertainty is driving people nuts. Even if all known bugs are resolved and closed, there’s still plenty of unknowns. Maybe the testing wasn’t as thorough or honest. And maybe we haven’t thought of all the use cases.

And with the KPIs and quarterly bonuses on the line, no wonder that putting a system into production is such a drama.

It’s as if you built a bridge not knowing the first car to cross it would make it to the other side.

But you know what? Rarely do information systems have such a life-and-death import. Dollars might be at stake, lives – not as often. Which is why, at the end of a project, all team members should have a sit-down with a licensed psychologist who would tell them: good job, and if you screwed up and that printing routine isn’t going to work, too bad but life goes on. And you’re gonna fix that on Monday.