July 7, 2011 at 10:31 am
Elliott Whitlow (7/7/2011)
I was with a large organization that unfortuantely the business analysts were more than happy to throw development under the bus to prevent them from being blamed for a bad design or an implementation that wasn't popular.
There's a company that I used to do work for that was much like this. Business blamed IT if things weren't implemented 'correctly'. IT management and the business analysts both put all the blame onto the dev team no matter what. Usually the specs were so vague as to be useless, business was not in the slightest bit interested in getting involved (except to scream about things taking too much time and costing too much).
There were several cases where things were developed to spec (a spec that business had signed off on), but when done it was deemed to be wrong and all the blame went straight to the developers.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 7, 2011 at 10:47 am
GilaMonster (7/7/2011)
Elliott Whitlow (7/7/2011)
I was with a large organization that unfortuantely the business analysts were more than happy to throw development under the bus to prevent them from being blamed for a bad design or an implementation that wasn't popular.There's a company that I used to do work for that was much like this. Business blamed IT if things weren't implemented 'correctly'. IT management and the business analysts both put all the blame onto the dev team no matter what. Usually the specs were so vague as to be useless, business was not in the slightest bit interested in getting involved (except to scream about things taking too much time and costing too much).
There were several cases where things were developed to spec (a spec that business had signed off on), but when done it was deemed to be wrong and all the blame went straight to the developers.
Once this process was in place for us and the CIO was fully on board. The business was "educated" over time that they were an integral part of the process and if they gave vague requirements and signed off on the functional specifications then IT wasn't going to take much from them. We wanted good requirements so we could actually develop what they wanted. Dev didn't start coding until they signed off, which was an unfortunate side effect of their resistance. We couldn't trust them. We just weren't going to commit to 600 man hours of development and 3 people basically full time without agreement. Over time things smoothed out and largely everyone was happy, overall development time was about the same, but costs were down and quality was up, it also cut down on rework because mid process changes were reduced. If you want to see generally dysfunctional project management just work with government.
CEWII
July 7, 2011 at 10:58 am
Elliott Whitlow (7/7/2011)
Once this process was in place for us and the CIO was fully on board. The business was "educated" over time that they were an integral part of the process and if they gave vague requirements and signed off on the functional specifications then IT wasn't going to take much from them.
And that's where the company I know really fails.
There is no CIO (she resigned last November). The Head of Applications (who now runs half the IT dept) bows to business and will just take their demands and pass them on to the IT staff with no push-back at all.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 7, 2011 at 11:24 am
GilaMonster (7/7/2011)
Elliott Whitlow (7/7/2011)
Once this process was in place for us and the CIO was fully on board. The business was "educated" over time that they were an integral part of the process and if they gave vague requirements and signed off on the functional specifications then IT wasn't going to take much from them.And that's where the company I know really fails.
There is no CIO (she resigned last November). The Head of Applications (who now runs half the IT dept) bows to business and will just take their demands and pass them on to the IT staff with no push-back at all.
I would consider that a failed IT organization. There will always be more work than resources and without even trying to evaluate whether a requested change or new app makes sense and will reduce costs you are just basically screwed. Don't get me wrong, I want to give the users what they want, but I have seen more than a few requested that to implement were huge, like over 160 hours to implement and test. We calculated IT time at over $50/hour (we didn't chargeback) to guage costs. So 160 hours x $50 = $8000, they estimated that this would save one person about 10 hours a month, and their time was estimated at about $30/hour. Their ROI was a little over 2years. While there were other projects in the 200-250 range with ROIs in the 6-12 month range. The one request got pushed and I don't think ever got done and probably wouldn't. There were just too many projects where we could get a lot more "bang" for our buck. Having senior leadership fully involved in the process really helped, it put them on the spot, and it was easier to see why the project for their group(s) were further down in priority. I mean EVERYBODY thinks their projects are the most important to the business, but in reality some are more important than others. The one exception is projects that are required due to regulatory or other legal requirements, they tend to end up high on the list, especially if there are fines or large legal exposure involved.
CEWII
Viewing 4 posts - 46 through 48 (of 48 total)
You must be logged in to reply to this topic. Login to reply