My first role as a consultant here in Charlotte was at a mortgage processing project for a big bank.  As a recent college grad I sadly knew absolutely nothing about mortgages nor process.  

I was able to learn both of those topics along the way but something that took me a bit longer to understand was this concept of “the business” and “IT”.

As a nerdy CS grad I thought I knew what IT was: developers and system administrators telling computers what to do and making sure the computers were running well.

But “the business” was new to me.

So apparently at most large companies (maybe medium and small ones too) there is a sometimes-hard and sometimes-soft line between people who want technology to do things (“the business”) and the people that make the technology do those things (“IT”).

For this first role[1] “the business” consisted of representatives from mortgage sales and mortgage operations management – you know, the teams of people that do the busy-work of mortgages (origination, approvals, servicing, compliance, etc).  These stakeholders would talk about more than just where fields go on web pages; we’d cover topics about how the users interact with the applications, how the legacy systems-of-record interact with the new application, how to handle gaps in the process, etc.  “The business” were the people that knew what they wanted out of the technology solution, and as a consultant it was my job to translate their needs to different types of specifications.  Sometimes I created a “Business Requirements Document (BRD)” – which was essentially a document that detailed everything these folks wanted the application to be able to do for them and their user community.  Next might be a “Functional Design Document (FDD)” – a more technical approach to requirements that covered not just what the application should do, but a little bit about how it was going to do things.  And then on “IT” side they were creating things like Architecture Specifications and Technical Design Documents.

Most of the time “the business” didn’t care about how things would work, they just wanted them to work.

It wasn’t until my next role that I settled into this middle-ground.  My role was called a “Business Systems Consultant” – always the fancy titles.

I learned to sit on calls and digest business requirements and business process needs but always have technology off to side: “how would this drop-down get populated? how often does this rule change? what is the frequency of this use case? where else can this functionality be used?”  

At the large financial services companies “the business” stakeholders weren’t always from super senior management; they were process owners and department leaders that lived the day-to-day work and were the best source for context and need.  Sometimes they were SMEs (subject-matter-experts) and sometimes they were process engineers and sometimes they were consultants fresh off the street with business case studies and prior-project experience.  “The business” normally paid for the IT work.  “The business” had to build the business case that said “if we spend $100 on this project, we’ll avoid $1,000 in regulatory fees next year” (pretty simple case).  “If we spend $100 now we’ll save $5,000 over the next 5 years in process improvement while also reducing operational risk” (slightly harder business case).  “If we spend $100 now we won’t make any more money but if we don’t, we could lose $10,000 in the future” (good luck with that).  And sometimes “the business” didn’t always get the final say.  For example if some infrastructure component was going out of vendor support, IT might have to spend $100K to move an application as-is to a new supported platform but maybe they could throw in a few small enhancements or changes to put some smiles on “the business”.

“IT” was way more than just developers and admins – we had analysts to write some of those requirements, architects to pattern and fit the application to standards, managers to assign resources and forecast costs, leads to handle hours and development plans, developers to code, infrastructure to setup environments, etc.  “IT” was just as deep and “the business”.

So I was able to appreciate this divide in large organizations but I also increasingly found myself frustrated that there was a divide in the first place.  This was post-Y2K – every knows how computers and networking and the internet work.  Don’t make “IT” such a black-box and don’t make “the business” out to be so clueless and needy.

So how do “the business” and “IT” work at other companies?  I honestly don’t really know…when I went to Big Blue I was curious to understand how an IT company ran its business and I learned a lot about sales and marketing – especially industry trends and standards and competitive drivers.  I realized that fixing “defects” in products doesn’t always make the cut for a release – just like change requests were prioritized by “the business” for the mortgage or brokerage applications I knew.  My experience has still been that business drives IT…I haven’t had a chance to work the other way around.

[1] Remember that this was around 2003 – “Lending was huge” is a major understatement.