enterprise

What are we trying to accomplish here?

thaxtonmLeave a comment

In one of my first roles I started working as a production support business analyst for a brand new suite of applications that sat between sales channel front office users and back office operations users.  The applications went live for a merger and obviously total chaos ensued, so most of my early application life cycle experience was very rushed/put out fires/do what needs to be done.  

But eventually the application settled into maintenance mode and we started to add brand new capabilities to the suite.  I had a good time in this new business systems consultant role because I learned a lot about the application’s highs and lows, but also about the business needs for the application.  I had a lot of good experience when it came to what worked and what traditionally didn’t work and I liked having that perspective on these new projects.

Like I’ve mentioned before, applications start with requirements gathering and go on to more and more technical design assets.  This was back in 2006 or so and Agile or Iterative development hadn’t even been brought to the table at this employer; so we were very much waterfall.  We engaged IT early to help make sure we didn’t commit to something that was totally unobtainable, but for the most part the business drove these discussions (as they should).

But when you take stakeholders with years and years of experience using legacy processes or applications and try to talk about a new way of doing things, you might run into a lot of calls and meetings that get buried in the nitty-gritty details of some very specific topics.  Like “how big should this field be” or “should this section come first or second” or the horrible “this is how it used to work/this is how it’s always worked”.

My technical side would always love to get into the weeds and start problem solving code right then and there: “well if we put these values in a look-up table and expose an admin utility we can manage this logic without additional deployments” – things like that.

But after awhile I learned to sit back and let the experienced voices talk and just listen.  And I’ve got to give a lot of credit to my manager because he knew that if I wasn’t speaking out about the problem or topic right then and there, I was thinking ahead.  And he always took a second to pause and call me out even though he already knew what I was going to ask…”What are we trying to accomplish here?“

I found myself on so many calls buried in the weeds and guts of details of problems that I always tried to bring at least myself and hopefully the larger team back up a hundred feet or higher and figure out if what we were arguing about really meant that much to the endgame.  It was about finding some perspective.

This was in no way a workaround to persistent stakeholders or stubborn management.  It was just a way to gut check the meeting and make sure everyone was on the same page.  Sometimes it work; sometimes the topic was pushed aside for more important concepts.  Other times it didn’t work at all.  Like I said, experience talks and even though I didn’t see the higher purpose doesn’t mean it didn’t exist.  But sometimes just asking the question helped me and probably a few others reestablish themselves.

On the technical side now I can get buried in code and look for immediate solutions to problems from QA or UAT.  But I always try to take a step back and make sure that we’re working with a defect or change request that will make a difference in the long run.  This has been especially important in a large organization: change can come very, very slowly.  So the decisions we make and the applications we build now need to fulfill their goals because who knows when we’ll get a chance to address a missed need down the line.

“The Business” before IT

thaxtonmLeave a comment

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.