JJ B (2/25/2009)
Here's another idea for, "how do you allocate limited resources among departments?"
How about letting IT decide? I make it my business to know our business. While I generally let management decide my "next big project", my day to day activity of small, medium and large projects and maintenance tasks is determined by me. I can make those decisions effectively because I know the business.
There is only one me and everyone here knows that I have a list of tasks 5 years long. Resources are truly limited, but staff trust me to work on what needs to be worked on. I've built up that trust over the years, by showing good judgment. In our environment this approach works. Staff are generally happy, because I know how to get the best bang for my hour buck.
(snipped most of last paragraph)... I have the big picture and management and staff trust.
I agree completely. This kind of hands-off trust is hard (in some cases nearly impossible) to get established in large corporations. Not so hard in small and medium-sized businesses.
IT must know the business needs of the business as good as or better than anyone else in the company... their success depends on it. More often than not, the IT departments that try to isolate themselves in a wall of "give me business requirements" without taking major initiatives to understand the ins and outs, will fail badly. Someone recently posted on this site (cannot remember which thread, but in last two weeks, and I am drastically condensing the idea here) that it is the job of the business to explain what they would like, but IT's job to make the proper desicions so as to keep the efforts from running out of scope and in the wrong direction.
For an extreme example of this communication, we recently received a request for a "small" application to manage a small business service over the web. This business owner spec'd out 3 web-based screens: one for orders, one for delivery groups to get their daily tasking, and one for invoicing. To him this bit would suit the enterprise, on about 10 tables of data. We spent about 30 minutes asking several questions about his business and what reporting he wanted back out of this application. The conversation included statements like, "If you want delivery groups to get tasking, then you must be able to enter/manage groups at the least, and invoicing would imply you are tracking customers..." etc. We helped bring this owner to the understanding that if we'd stuck to his specs, he would be leaving out the ability to enter/edit employees, teams, delivery trucks, products (and inventory), security, clients, contractors (which are involved in this enterprise), scheduling, and etc. This owner was thinking a few all-in-wonder screens would equate to less dev time and cost. We explained to him that dev time was identical regardless of whether he packed the functionality into a few or task-isolated screens, and that the maintenance and changes to a wonder-packed few would be far more complex (especially when only certain people were allowed to see certain things). This type of ownership of the success of a project is definitely required before we could even to begin to give him a quote on time or dollars.
In most cases, the "business owner" is not this far away from reality, but often does not consider other implications such as:
- Inter/Intra-departmental use of the same data, and centralizing those sources.
- Analytical processes for reporting.
- Other data that is required to meet the needs of the reports desired, that may or may not exist yet.
In another example at yet another client, they had three departments that each had their own copy of the client list served by the company, and none were identical for the codes used for each, nor (obviously) PKs. Only IT would be able to steer that to a single source, and force all systems to ETL or read from a central source for updates. Deciding which method to use (ETL or mod existing apps to new source) is also only an IT decision.