I have previously stated a view that Requirements gathering does more harm than good.
‘Gathering’ generally has the connotation of collecting something that already exists. As if ‘Requirements’ were sitting out there fully formed waiting to be collected. What value does a Business Analyst add who asks a client for their requirements and writes down whatever they are told? I wish this was uncommon practice but I fear it is not. If I were to ask my clients what their requirements are I am mightily impressed when they say ‘we don’t know’. By demonstrating the ambiguity and inconsistency in the answers who claim that they do know, it is relatively simple to discover that they do not. I don’t believe they should know, and I believe that we are doing them a disservice to let them think it is expected of them to be able to articulate an unabiguous and consistent set. But all this begs the question ‘What is a ‘Requirement’ if such a thing exists at all?’. That’s for next time. For now, I will sign off by saying that in my view whatever we do needs to be active and not passive. We need to help clients to identify and remove ambiguity and inconsistency. Without giving the game away we also need to help them seperate ends and means, to distinguish their goals from the features of the solutions which satisfy them.
Permanent link to this post
(236 words, estimated 57 secs reading time)
What is a business? How can (or should) an expert business practitioner relay his or her knowledge to another interested party? Trying to understand these questions leads down a path of debating the merits and demerits of understanding through metaphors, and understanding through models. This eventually ends up with a discussion of roots in philosophy of science.
During the Seiad project in 1977, Ian Simmonds and I had many discussions about understanding business, filling up the whiteboard in his office at the Watson Research Center.1 My studies into business strategy reflected the two primary foundations: microeconomics — Michael Porter is a leading proponent of this approach — and organization theory — with roots in the research of the Tavistock Institute, and the sociotechnical systems thinking from Fred Emery and Eric Trist. Add onto that my personal bent towards decision support systems — Peter Keen‘s research while at CISR at the Sloan School at MIT was highly influential — and a strategic view of marketing that can be described as Market-Driven Strategy, as described by George Day. These all represent models of business. Read more... (989 words, estimated 3:57 mins reading time)
I believe that we can do a much better job of doing two things. Firstly linking business goals to the projects and programmes that deliver them. Secondly, co-ordinating business change in delivery projects and programmes with IT change. Systematic treatment of these two things together capture the essence of what I think of as ‘Business Architecture’
In order to explore these two topics, and to make it more fun, I’m going to suggest that requirements gathering does more harm than good. I have some clear views about why I think it does, some of which differ from current widely held views. I also have some ideas about how we can do better.
I’m hoping that you will join in by providing your views about whether you think it does more harm than good, if so why, and what you think we can do about it.
Permanent link to this post
(146 words, estimated 35 secs reading time)
What are good foundations for understanding business, in an age of pervasive digital information? I’ve found systems science to be helpful, and ended up on a path where I’ve become deeply involved with the International Society for the Systems Sciences. The origins of this trajectory started at IBM in 1997 with the Seiad First-of-a-Kind project, leading to a 2-year assignment through the Advanced Business Institute.
In 1997, I had moved out of the IBM Consulting Group — the services unit that became IBM Business Innovation Services, and then IBM Business Consulting Services — into a Sales & Distribution unit (in the Boston area) called "Consumer-Driven Solutions". This business unit had the ambition to bridge the gap between clients in the retail and consumer products industry segments (as defined by IBM). In the confluence of changes at IBM, I led a proposal to lead a First-of-a-Kind project, that included customer-facing consultants from the Object Technology Practice of IBM Consulting Group1, scientists from the Watson Research Center2, and industry experts hired as consultants into the Consumer-Driven Solutions unit3.
The Seiad project essentially had three goals: Read more... (1049 words, estimated 4:12 mins reading time)
The question of the relationship between technology and human social systems can be seen as a matter of coevolution. That is the genesis of this discussion of factors and implications involved in coevolving technologies and human social systems.
Technological tools and organizational methods have been coevolving rapidly over the past two hundred years as the world’s population has grown from an estimated one billion people in 1800 to six billion people in 2000. Technological tools, ranging from steam engines to electricity, from automobiles to airplanes, from telephones to computers are all ways of helping people accomplish work. Organizational methods, ranging from factories to assembly lines, from M-organizations to franchises, from call centers to outsourcing are ways of organizing and managing people and other resources to accomplish work. The rapid coevolution of these technological and social innovations creates a number of challenges for businesses and other enterprises.
The world of business today is increasingly competitive and uncertain. Managers are faced with decisions about outsourcing and cost cutting, business process integration and productivity, partnerships and investments for growth. These are issues at every level from departments to business units, from enterprises to industries, and from regional to global economic planners. Read more... (452 words, estimated 1:48 mins reading time)