Business Deferred Development

Jon Mead -

Following on from previous posts about Rittman Mead’s development methodologies, I would like to talk about another approach we have been working on over the last few years: Business Deferred Development.

Development methodologies are designed to augment the development process, empower developers and ultimately produce better results. What we were finding was that continual interaction with the business and end user community was slowing this process down. We would get involved in endless meetings with users discussing what they want to see in the system, what data items they wanted in reports and which reports they wanted to see on dashboards.

The problem with this is that the business and users don’t know what they want. They are not used to the tools or their capabilities and at the end of the day have absolutely no idea what they are talking about. We are Business Intelligence consultants and see these sort of systems on a daily basis and I would argue are in a far better position to determine what should be in the reports and dashboard. For this reason we have developed Business Deferred Development, as the name suggests, involvement from the business is deferred for as long as possible during the development of the solution.

This may seem like going backwards, the trend these days is to agile approaches where the business is encouraged to sit side by side with the development team to get early visibility of the system, but we believe this is wrong. Let’s take the example of a simple finance reporting system. Your end user is likely to be someone with an accountancy background, and let’s face it, what do accountants know about reporting and the aesthetics of report placement on a dashboard? They are likely sit beside you continually asking you move columns around a report, or to change title to 1980’s style cyan backgrounds. Believe me you are better off without them.

So how does this work in reality? Once requirements have been established at the very beginning of the project it is key to lock the business users out of the development process. This is done as we believe that beyond this point end users offer very little to the process. As I mentioned earlier, we are professionals, we see these kind of systems all of the time, we have seen so many organisation, product and account hierarchies, we don’t need the business to tell us what should be in them. I mean most end users don’t even know what a dimension is, so why waste valuable development time teaching them, only to have them grapple with the concept and confuse the whole process. I mean you wouldn’t ask your 2 year old son to drive your car, even if they would think its fun.

Once the business users are locked out of the process we get our heads down and do what we do best, develop Business Intelligence solutions, no meetings, no interruptions, no acceptance testing, just technical people doing what technical people do best: code.

So how do we then exit the project? Well we define one report with all the attributes from the dimensions and facts present on it and use this as the focus for a 2 day intensive end user bootcamp. During this process end users are strongly encouraged to listen and not ask questions, you may have had to work closely with management to achieve this, in the early days there was often consternation and perplexation from the users for not being involved in the process, however we found that the threat of disciplinary action if they did not listen seemed to give them the focus that was required.

Once this process is complete we leave, there is no point in ongoing contact, it only encourages people to change their minds, we need a clean break.

So just to refresh the key points are:

  • define requirements as early as possible;
  • keep the business as far away from developers as possible, consider potentially locating in another building, or hiding from the business, if required;
  • always trust developers will know best;
  • release one and only one report;
  • bootcamp the users into understanding the system, don’t be afraid to use disciplinary measures to aid learning;
  • leave at the end of project, Business Intelligence isn’t an ongoing process, its a clearly defined project, when its over you need to get out.

If anyone would like further info, or uses a similar approach I would be interested in exchanging stories.