IT departments typically staff themselves with a group of folks known as business analysts.
These folks have the responsibility of talking to folks that work in the business and translating their needs into a format that more technical folks can understand, because for some reason or other, most managers think that developers are unable to speak the same English that everyone else does.
IT is consistently cursed with getting the requirements wrong. Users, it seems, are horrible at actually reading the requirements documents they are given, worse they always seem to hate the great software that IT gives them. IT management typically has two solutions to the problem
1 - put a change management system in place that prevents those customers from actually changing their minds
2 - invest in better capability in requirements facilitation and documentation
None of these assumption address the underlying cause of churn in IT requirements, which is that today's customer economy has created an environment where the benefit of many IT requirements are based entirely on assumptions. When these assumptions turn out to be wrong (and they often do) the business has no choice but to change direction, and fast.
Faced with this challenge IT either jumps into heroics mode or shuts down into change request mode, or worse some weird mixture of both.
No amount of requirements gathering expertise can fix this problem.
For the IT Analyst function to be relevant in today's world requires a different set of skills. What is required is an IT Analyst who is well versed in how to reverse engineer a business plan and associated IT solution into a set of testable assumptions that can be implemented, and validated by order of highest risk.
This analyst needs to be able to combine business knowledge with enough technical savvy to walk business customers along a journey of validated learning, guiding stakeholder through pivot or persue decisions. They need to employ techniques like Business Model Generation, Service Design Thinking, and Customer Development to provide the business with a richer ecosystem of tools to brainstorm what the future should look like.
In short Business Analysts need to become Business Technology Innovation Experts if they want to more than mere order takers.
From my experience asking end users what they want from their IT systems is going to be a waste of time. They will tell you what they think they want, but given that they are not knowledgeable about the technology they come up with very poor solutions to their problems.
ReplyDeleteThe IT analyst should ask what they want and then follow up with WHY they want it. It's the why that is so important.
Oh your work group needs administrative access to this network share? ok. WHY??
The IT analyst quite often lacks confidence to challenge the assumptions and demands of the business leaders and as a result let the business leaders down.
My first week on the job as entry level IT. Yes I have root to the network; that's a given. When a line of business manager came and asked me to give his work group rights to that share, I did it. He was a line of business manager, I was a lowly IT schlep. That was a painful mistake, that I was very lucky to have because I never made it again.
It turned out the work group didn't need enhanced access to the network share. They just were not using it properly.
Nice post. Good to see some recognition that the work of the BA must change fundamentally. For Analytic-minded organisations (a.k.a. bureaucracies, corporates) functional silos are so integral to doing business that we cannot hope to see their demise.
ReplyDeleteBut for significantly more effective organisations, and organisations wishing to become more effective, i.e. those of a synergistic mindset, silos are a throwback to the dismal past, and have no place in their worldview . So, likewise, for BAs. It is therefore not helpful to say that Business Analysts need to change skill sets or become something else (which just adds up to renaming the silo). No. In synergistic organisations, silos are gone and folks are much more multi-skilled and capable of working across functions. So the very notion of a narrow specialist like the Business Analyst passes into history, in favour of e.g. 'T'-, 'Pi'-. or even 'Cthuhlu"-shaped people.
- Bob
Of course, change management isn't *necessarily* there to stop customers from changing their minds.
ReplyDeleteIt's there to stop them changing their minds capriciously (ie without some level of business case) and without ensuring that everyone who needs to know is fully aware and has given suitable inputs to that business case.
I use it to limit costs. Without an agreed upon set of requirements the project can go on forever. Not bad if the contract is time and materials. If its a firm fixed price contract and you don't have an agreed upon set of requirements you are either going bankrupt; or you are going to have a very unhappy client.
ReplyDeleteHmmm. You mean as opposed to a role that's been in place for a decade and has in most cases obviated the role of BA? UX Architecture.
ReplyDeleteThat said, your recommendations for techniques like Business Model Generation, etc. might be even more relevant -- I've worked with a lot of UXAs who don't operate with those types of approaches and thus compromise their solutions.
But there's something even more fundamental here: the role of design and where it fits. This is a critical 'aha' that I discovered by crossing business models. I 'discovered' it when immersed in the commercial building industry. It's a great analogy.
I was once at a presentation by someone who was helping existing commercial construction practitioners realize some changes they would need to make to adapt to the influences of 'going green' (as embodied in the LEED certification movement). This individual was explaining how they needed to change their entire approach while still using an existing model: the specifications document. The lightbulb went off...
But it was my deep immersion in the industry that helped me see the rest. It made me realize that development (which operates from a 'center of the universe' perspective) is a sub-contractor -- not a general contractor -- effectively leaving the role of general contractor missing (along with all of the responsibilities that go with it). The whole process of design is not something that happens at the sub-contractor level (which is the way we're still doing it today), but it is something that happens when various architects come to the table and hash out and really challenge the possibilities. In the end, what comes out of the process is not a set of requirements, but a vision for a design, with plans that include specifications. The sub-contractors then, respond to the specifications with a bid (noting what they specifically plan to deliver, often adjusted for market conditions and/or costs). Requirements aren't shared upstream at all, but are simply the things that the sub-contractor uses to guide their own efforts in fulfilling the specifications. The focus is on fulfilling the specifications, not the requirements.
Knowing the difference between the two is critical.
All of this said, this is only appropriate for specifying the 'big picture' -- the infrastructures. Filling in the little stuff should not be figured out in planning meetings -- that's like decorating the rooms (not to be confused with bit-twiddling UIs).
The bigger issue is that most organizations (especially IT) have no idea what real solutions architecture looks like. If you were to find an architect inside of an IT organization, most frequently (you can 'know' same simply by reading job descriptions) are what I would call 'drafters' -- people who can draw diagrams of hardware installations and the like -- not how to solution a business, and 'fit' the technology to that.
We're talking about fundamentally changing the design of a business with every solution that is put in place. IT over-focuses just on the technology portion of it and not the impact of it (also not to be confused with 'change management').
Paula,
ReplyDeleteyou're resonate is brilliant, amd worthy of a post in its own right, amd one that should be ready by everyone in IT. Design Thinking is really the common underlying theme to what is missing.
That and the notion that knowledge workers need to learn how to iterate on the business solution, technology is an enabler to that type of thinking...