Does your specification destroy trust?

I just read a great article in HBR "Does your contract destroy trust".

In a nutshell it was asking if the way you wrote your formal aggreements guarnteed animosity by locking everything down so tightly there was no room to show good-will and the kind of mutual flexibility that good relationships needs.

The application to BA work is obvious - when you produce functional requirements to detailed that every aspect of the system is locked down, and twenty pages of assumptions you may find yourself in more trouble with arguments over scope than you would if you had left things more fleixble and shown mutual trust.

Obvioulsy there's far more to change management than documents and processes - but it's worth thinking about.

There's an old saying that "Good fences make good neighbours" that I tend to use a lot to explain why unambiguous functional specifications can be useful - but this article has made me think about whether having an impenetrable brick wall as a fence would be too much of a good thing.

P.S. I suppose this is one problem iterative methods don't have as much.

You should know SFIA

For those who aren't aware SFIA is a pre-rolled skills matrix by the British Computing Society that defines a number of skills (80 or so) and then what it means to be at each level of that skill.

For anyone involved in career planning, or defining skills matricies, or even looking at where they want to go in their own career it's a seriously useful body of knowledge.

Even more impressively you can probably get some value even out of a give minute peruse of their summary sheets and introductory booklets.

http://www.sfia.org.uk/