Comments on: When Technology Trumps Philanthropy http://www.tacticalphilanthropy.com/2007/11/when-technology-trumps-philanthropy Fri, 09 Dec 2011 20:42:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Suzy http://www.tacticalphilanthropy.com/2007/11/when-technology-trumps-philanthropy/comment-page-1#comment-979 Suzy Tue, 20 Nov 2007 16:40:11 +0000 http://tacticalphilanthropy.com/2007/11/when-technology-trumps-philanthropy#comment-979 Good post and great response. I have said for years that our organization doesn't have a tech problem, we just need a translator between our tech people and our program people. Neither side is able to get across to the other what each needs for the relationship to be successful. Now, can someone blog a piece on that? Good post and great response. I have said for years that our organization doesn’t have a tech problem, we just need a translator between our tech people and our program people. Neither side is able to get across to the other what each needs for the relationship to be successful.

Now, can someone blog a piece on that?

]]> By: David Noble http://www.tacticalphilanthropy.com/2007/11/when-technology-trumps-philanthropy/comment-page-1#comment-956 David Noble Mon, 19 Nov 2007 07:17:01 +0000 http://tacticalphilanthropy.com/2007/11/when-technology-trumps-philanthropy#comment-956 This is a common problem, where the "business" people and the "technical" people need to collaborate. In an ideal situation, the technical people estimate the cost and risk of implementation and the business people set priorities and decide what gets implemented, taking into account the cost and risk. In some cases, getting good estimates might require spending some extra time doing investigation or experimentation. For those situations, the business side needs to decide whether or not it's worth the time to figure that out. It sounds like a few different things could be happening in the donor form scenarios: 1. The time to implement the desired solution exceeds the amount that IT expects would be acceptable from a business perspective. 2. IT knows they don't have the resources to provide the desired solution. 3. IT doesn't have a good idea how much extra time would be required, possibly because they don't know how to do it within the existing system. 4. IT people are stupid buttheads. While #4 is always a possibility, it might be worth figuring out of something like #1 - #3 is happening. Is the cost of doing it right definitely prohibitive? Would doing the forms right would mean that some higher priority project couldn't get done? Is the number of folders a problem because it requires a risky or time-consuming procedure to create redirects or folders at the top level? Or are there already thousands of entries in the top level, which can have a measurable impact on system performance. Unless the root problem really is laziness, it sounds like there's a communication gap. Why does so much software suck? Most cases can be boiled down to a few root causes: A. Basic communication problems. B. Technical people making business decisions, and vice versa. C. Technical people not having sufficient time, people, or money to build a good solution. D. Technical people not having the skills or knowledge to build a good solution. Looking at that list of obstacles, it's amazing any good software gets written at all! It's more difficult and expensive than a lot of people realize. Especially when software tools and building blocks have been created in contexts with the same set of obstacles. This is a common problem, where the “business” people and the “technical” people need to collaborate. In an ideal situation, the technical people estimate the cost and risk of implementation and the business people set priorities and decide what gets implemented, taking into account the cost and risk. In some cases, getting good estimates might require spending some extra time doing investigation or experimentation. For those situations, the business side needs to decide whether or not it’s worth the time to figure that out.

It sounds like a few different things could be happening in the donor form scenarios:

1. The time to implement the desired solution exceeds the amount that IT expects would be acceptable from a business perspective.
2. IT knows they don’t have the resources to provide the desired solution.
3. IT doesn’t have a good idea how much extra time would be required, possibly because they don’t know how to do it within the existing system.
4. IT people are stupid buttheads.

While #4 is always a possibility, it might be worth figuring out of something like #1 – #3 is happening. Is the cost of doing it right definitely prohibitive? Would doing the forms right would mean that some higher priority project couldn’t get done? Is the number of folders a problem because it requires a risky or time-consuming procedure to create redirects or folders at the top level? Or are there already thousands of entries in the top level, which can have a measurable impact on system performance. Unless the root problem really is laziness, it sounds like there’s a communication gap.

Why does so much software suck? Most cases can be boiled down to a few root causes:

A. Basic communication problems.
B. Technical people making business decisions, and vice versa.
C. Technical people not having sufficient time, people, or money to build a good solution.
D. Technical people not having the skills or knowledge to build a good solution.

Looking at that list of obstacles, it’s amazing any good software gets written at all! It’s more difficult and expensive than a lot of people realize. Especially when software tools and building blocks have been created in contexts with the same set of obstacles.

]]>