Emily’s Rebellion

Emily knows her part of the business well and she can see that there are some inefficiencies in the way the team does things now. The system is a set of screens for data-recording, and isn’t oriented towards stepping through a transaction from beginning to end. In fact, there is no clear delineation between transactions.

Emily hasn’t been closely involved in an IT project before. She feels intimidated by the IT dudes who say “tell us your requirements”, and by their talk of “functional specifications” and “user stories”. She doesn’t understand all their talk about object orientation, unified modelling, data driven, etc. She feels inadequate for not understanding what they are talking about and what they expect from her.

The business analysts confuse her even more by showing her their previous work – one showed her a document that listed requirement after requirement for a hundred pages and more. Others showed her their one-sentence user stories that they said the IT guys could develop a system function from. User stories seemed like easy work for her, but Emily is awestruck by the magic that was promised by this new “agile” approach.

Emily can’t understand how the IT analysts and developers could ever hope to develop a coherent system that could meet all these individual requirements in a joined-up way. There seemed to be an unspoken assumption that a new system that supported a better way of doing business would emerge, as if by magic. After all, an improved business operation – not just a new system – is the point of this investment, isn’t it?

Emily needs a structure to think about her business needs in a different way. It strikes her that most of the processes are actually quite similar, it is only the content (the data, workflow, the output) that varies.

When a customer chooses to use a service that Emily’s business offers, they first submit a request, just like a shopping order, or an application for a permit. This customer request is an event that the business must deal with and provide a response back to the customer – fulfilment of the order, or a decision on the permit. Businesses exist to process such events, no matter what kind of business it is.

Emily thinks that an approach structured around a straight-forward pattern like this might simplify her task of specifying the business requirements. Looking at each task in turn, she could focus more on the business workflows, data needs and business rules, and less on system functionality and screens. She would be able to retain a holistic view of how the business could work more smoothly, processing its transactions like a clock ticking over the minutes from one state to another.

But could the IT team consume her new way of specifying requirements? Would her small rebellion succeed?