When it is appropriate, I’m sold on the idea of evolutionary development and delivery based on iterative and incremental phases as one’s understanding of the business domain increases. Even when we had plenty of trained systems analysts, and only primitive ‘waterfall’ methodologies, the requirements were all still vague and full of hand-waving generalities at the beginning of the software development cycle. Under any software methodologies, therefore, continuous customer or stakeholder involvement is very important. From my own past experience, though, the major struggle in development is in finding out who the customer really is, and in identifying the key people in the organisation who really understand the business processes. It’s not always as easy as you might imagine.
‘So which of you guys can help us understand how the returns system works?’
When I started designing large-scale applications for the enterprise, I remember being amazed at the lack of understanding of the essential processes of the organisation that the designated ‘users’, ‘stakeholders’ or ‘customers’ had. When any important application gets the go-ahead, one might expect a general concerted action within the company to assist and ‘make it happen’, in order for the company to reap the benefits of efficiency-savings: Sort of like an Oklahoma barn-raising.
Reality comes as a shock. Let’s take as an example a corporate application: The panel of designated users is seconded from various departments. No manager will willingly part with competent staff. Instead, canny managers see this as a means of cleaning out from their department those staff that are burned out or demob-happy. Departments who are liable to contract or be reorganised by a successful IT initiative will deliberately nominate difficult and disruptive people. This is an unlikely mix of humanity from which to draw insights into what is now called the ‘business domain’.
I’ve seen projects where the developers have failed to realise until too late that their ‘stakeholders’ haven’t grasped the basics of the company’s activities, or who might even want to mislead. In any large organisation it is often an uphill struggle to discover what is really going on. The proportion of people with a broad perspective in what is going on can be very small, and they are too essential to be seconded to an IT project. and there are plenty of people who want to throw sand in the air to disguise how little they are contributing to the company. With staff turnovers increasing in recent years, evolving an effective application from their insights is like expecting primates to write Shakespeare on typewriters.
I remember once tracking down the only person who really understood the full shipping process for the organisation for whom I was developing an app. His office was in a trailer in the back of the car park. One needed rubber boots to get there. I thought to myself at the time ‘is this really a developer’s task to do this?’ Yes, I can say in hindsight, it might be essential. I think the technical term is ‘identifying the real stakeholder’, and it isn’t always easy.
Guest Editorial for Simple-Talk