The Business

  • Comments posted to this topic are about the item The Business

  • As a consultant, I do use the term "the business", "the client" and "the customer" nearly interchangeably.

    When talking about them internally to my DBA staff, I usually say "the customer". When talking to the tech staff of my customer, I usually refer to THEIR staff who orders the business rules and requirements, as "the business". especially for my larger health care clients, THEIR tech staff refers to their internal folks who requested db/app changes as "the business".

    So every step of the way seems to be marked by terms which bestow customer service that WE need to provide to the people writing the checks.

    In my shop, I find it very important to take care of our customers. Which sometimes can mean bending over backward to give them what they need, and other times that can mean fighting to the death to resist them making the order to shoot themselves in the foot.

    I don't think we should be afraid to speak up to "the customer" and inform them of the ways of their folly. We wouldn't be doing our job if we were just yes men/people. But that should also be balanced by them having certain business strategy which may require an imperfect implementation of something, and we're certainly in no position to work against them and refuse.

    But we should fight - in the sense of reasoning and educating and pushing back several times.

    My smaller customers don't really know the ins and outs of the tech stuff and just want their SQL Servers to keep working. And they trust that my own decisions and changes to their systems are in their best interest and not my own. And they are.

    Jim

    Jim Murphy
    http://www.sqlwatchmen.com
    @SQLMurph

  • As an internal IT department we always refer to "the business" whether it is for IT or anything else. The ITIL Foundation course is compulsory for IT staff here and it teaches a service based approach and provides a structured framework for IT. The business is treated as a client with a single point of contact through the helpdesk and formal incident management systems.

    On the down side we are thus somewhat isolated from the business and being in a seperate building have little contact with operational staff and physical production even on this site, let alone at the other sites around the country. In previous jobs I was closer to the "shop floor" and thus had a better knowledge of the practical doing of the jobs which I could put into use when writing software.

  • Good post.

    I'm a consultant thou so I take these things for granted. IT departments that does it too gets more positive response from the business.

  • Good points. The one thing I would also add here is that I personally get frustrated with is being forced to solve a five thousand dollar, or even a fifty thousand dollar problem, with a five dollar solution. I also understand that throwing money at the problem is not always the correct approach either. However, I can't count the times that I, as a DBA, have had to make my systems jump through hoops for months, sometimes even years while constantly putting the databases at risk, simply because the "business" wouldn't upgrade their hardware. The reason given was because their "budget" could not support it. However, CEO and upper echelon IT managers bonuses contuned to increase every year during this time period, while the front line troops were forced to take pay cuts. Please spare me the "they come out of two different buckets" argument: I have heard that convenient excuse more times than I care to remember. -D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • I am a BI consultant who works in a small consulting firm which works for a bigger consulting firm which, in turn, works for a final client (IT unit of a major bank). Ultimately, the IT unit works for "the business".

    The bad thing in this organization is that the business sees IT too much as a provider and IT sees the business too much as a customer. So much, that both parts are forgetting that the business is really only one.

    IT unit's productivity metrics are quite different than business' metrics and -worst of all- do not include any "customer satisfaction" metrics. This leads to completely different visions. The business thinks that IT is expensive, square-headed, very procedimental, too slow, and inflexible. And IT thinks that the business never knows what it wants and is very bossy and capricious.

    A project that is "a great success" for the IT unit (in terms of budget, time, quality, etcetera) is often perceived by the business as someting completely useless because it does not fit its real, evolving needs. And vice-versa: some projects (and even non-projects!) giving great satisfaction and relief to specific business pains are considered IT failures because "the metrics are bad".

    IT people's bonuses are based on productivity (lines of code, function points and the like) and level of adhesion to procedures (ITIL, CMMI, etcetera), and not related to business' satisfaction.

    So, the business is hiring IT profiles in their departments in order to work around the procedures and discipline of the IT unit. As a result, there are little "This is my problem; what are the options?"-like questions for IT, and many "Build that table, prepare that file"-type orders. And many "Yes, bwana" responses on the IT side. We end building "space pens" very often.

    Due to my sub-sub-contractor relationship, I do not have much influence over final users and managers, since everything must follow the "official channels".

    This is the problem; what are the options?

    Now, I myself am trying to get hired for the business' ranks.

  • My "client" is state government. It might go without saying that almost every directive from above comes without any thought of how to achieve it in an IT sense. Makes life interesting.

    <><
    Livin' down on the cube farm. Left, left, then a right.

  • We have found that the farther IT is from "The Business", the easier it is to be looked at as an expense, and therefore, regarded as such. It's easier for them to question the value of the service when disconnected like that. So I try to steer us more into the business end, even with all the crazyness that goes with it. The whole of the company should equal more than the sum of its parts, including IT.

  • I'm also in government. I hope my shop is not typical. I overheard my IT director complaining about how a project did not go well because the department requesting it did not provide proper specifications. We usually have a meeting at the beginning of a project, other than that, there is no process, no methodology for how to get specs. At my previous, non-government jobs, it was similar, the primary difference was that the programmers would get blamed for the project not going well.

  • There's an interesting tug-of-war going on between IT and another large business organization within my company. IT is trying to tell the business which tools to use and processes to follow, where the other organization is trying to tell IT that they should decide what their processes are and what tools will help them, and IT should support them.

    Personally, I think the business organization is in the right - although if there is a better way to perform something, IT should work with the customer to introduce the new tool/concept. When it comes down to it, IT is and should be a customer service organization, not the driver of the rest of the business.

  • There is a lot of gray area between those two extremes Dizzy. I prefer to start with a partnership in mind and work it out from there. We are supporting many pieces of hardware and many old MSAccess projects that were started by "the business" and grew beyond their ability to maintain. Everyone's time could be better spent.

  • WolforthJ (3/16/2011)


    There is a lot of gray area between those two extremes Dizzy. I prefer to start with a partnership in mind and work it out from there. We are supporting many pieces of hardware and many old MSAccess projects that were started by "the business" and grew beyond their ability to maintain. Everyone's time could be better spent.

    That's basically what I was trying to get at - "partnership" is a very good term for it. That's where IT should step in & have discussions with the business organization if there's a better way to perform work, especially if it benefits the whole company rather than the single organization. But we certainly shouldn't be dictating to others how to do their jobs.

  • Dizzy Desi (3/16/2011)


    WolforthJ (3/16/2011)


    There is a lot of gray area between those two extremes Dizzy. I prefer to start with a partnership in mind and work it out from there. We are supporting many pieces of hardware and many old MSAccess projects that were started by "the business" and grew beyond their ability to maintain. Everyone's time could be better spent.

    That's basically what I was trying to get at - "partnership" is a very good term for it. That's where IT should step in & have discussions with the business organization if there's a better way to perform work, especially if it benefits the whole company rather than the single organization. But we certainly shouldn't be dictating to others how to do their jobs.

    Here here!! Now if I could only get the rest of my state department to read this forum. 🙂

    <><
    Livin' down on the cube farm. Left, left, then a right.

  • What do you do when management in the I.T. Department has the same attitude as the business side? I am working really hard to get them to understand that even though SQL server is very powerful, is not a good thing to consolidate multiple databases onto one server...and that I need a development server!

  • I think the biggest issue when it comes to partnerships between business and IT is where the two try crossing into each others domains. Broadly speaking I think you can sum up the ideal relationship as saying that business handles the WHAT, while IT handles the HOW. So the business should decide on what they are trying to achieve, what they want outputted in terms of reports etc, what the budget is, what the processes will be etc, and then IT should determine how that can be done.

    IT don't generally know enough about the business to determine the whats, that's not their expertise, and the business is unlikely to end up with something fitting their requirements if IT take the lead there.

    Similarly, business aren't experts in IT, so shouldn't try to define the how, that's what they pay IT for. I've lost track of the number of times I've had business clients say they want X, Y and Z done, without any background of what they want to achieve. When you actually talk to them about it you often find that while their method will work, it's no longer the best way. The best solutions change over time, and if they have A, B and C instead, it'll do the job better, faster, easier and cheaper than their solution.

    The tricky thing at times is having that discussion without coming across as arguing with the client!

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic. Login to reply