Collaboration: Working with Non-IT Personnel in Building Technical Solutions

[MCWebsite.Staff]

** This thread discusses the article: Collaboration: Working with Non-IT Personnel in Building Technical Solutions **
** This thread discusses the Content article: Collaboration: Working with Non-IT Personnel in Building Technical Solutions **
0

[scoia]

Collaboration: Working with Non-IT Personnel in Building Technical Solutions

** This thread discusses the article: Collaboration: Working with Non-IT Personnel in Building Technical Solutions **
The statement at the bottom where Chris states that he weighs strong programming skills at 50% in the interview process is very wise indeed. In this "one person does everything" environment, it is critical that that person can understand business language and be able to ask the questions in an interview that uncover what the stakeholders' business needs really are so that all of the code that is built support those business needs. More and more I'm seeing recognition for and movement back to a need for a category of IT staff in even small projects called "business analysts" rather than a soup to nuts "developer" who is supposed to excel at every stage in the software development lifecycle AND understand effective project management. Thanks for a great article!

[bharder@nlrha.ab.ca]

Collaboration: Working with Non-IT Personnel in Building Technical Solutions

** This thread discusses the article: Collaboration: Working with Non-IT Personnel in Building Technical Solutions **
I have a long-standing issue with the effort that most clients seem to be willing to put into systems they will be expected to use and live with. Extracting a reasonably complete requirements definition seems to be a problem. Always. And what is our response to that? It's the Computer Person's problem. What is the dynamic here? Well, clients are probably busy. The fact that they don't have an existing system, or the existing system is inadequate, is part of their workload. And they usually aren't technical in the computer sense, so thinking in computing terms may be an adjustment. However that's just not comprehensive or truly explanatory. Getting a really good system should be entirely in the client's self-interest. Yet I struggle to get anything written, anything really specific, anything well thought-out, anything non-ambiguous. Clients are frequently willing to have a short verbal meeting, but that's easy for them, and settles little but the broadest of project parameters. No, I think there is a pervasive attitude that, if the system developed is inadequate, it's the Computer Person's fault. Those crazy, introverted, inarticulate Computer People! You see, it's an easy excuse. My attitude is a little different. Don't get me wrong, I do my best to fill in the blanks, to make the communications effort, to define the fuzzy/vague/incomprehensible. But in the end system development has to be a team effort. If the clients don't make a reasonable contribution, then they get what their effort reflects. Which is someone else's idea of what they need. How many times has a client come to you with a sketched out idea of what they want? It can be very high level, but actually written down and thought about? How many times has a client expressed real enthusiasm for getting involved as a tester in an iterative development cycle? For me, it's happened maybe once in my career. This isn't a completely universal problem. I've encountered many clients over the years who were excellent. Yet it does happen the majority of the time. Far too often, in my estimation. It is just an easy excuse to blame someone else for a project shortcoming, when one's own effort was inadequate to the task at hand.

[BWierman]

Collaboration: Working with Non-IT Personnel in Building Technical Solutions

** This thread discusses the article: Collaboration: Working with Non-IT Personnel in Building Technical Solutions **
First, thanks to Chris for this well-written article. I suspect that most of those who read it will do a lot of head-nodding in agreement with many, if not most, of the points he makes, but he also articulates some issues that I find myself recognizing that I could undoubtedly do better. I forwarded the link to developers in my department, but I feel like I'm preaching to the choir - most of them will have already read it, heads nodding. If only I could find some way to get management and users to understand and embrace these concepts.