Business Deferred Development

April 1st, 2012 by

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.

Comments

  1. Mike Green Says:

    I assume this approach is used in tandem with the one mapping methodology.

  2. Mark holton Says:

    Nice article , before 12 o’clock too

  3. Cameron Lackpour Says:

    >>don’t be afraid to use disciplinary measures to aid learning;
    ^^^Only in my dreams am I the BOFH. Brrrzzzzzzzttttt!

    :)

    Regards,

    Cameron Lackpour

  4. Jeng Daw Says:

    We have gone through the similar project process, but not get out of the project well. Stock with a lot of data model and report modification activity. Even worse, ETL re-design sometimes. I think the point is how well the requirement is defined. But, there is always a but, as you mentioned there is hard to have clear requirement from users because they really don’t know what they really want. Hey! we are back to the beginning…… Just my experience.

    Regards,
    Jeng Daw

  5. Cristina P. Says:

    Interesting article, even if I’m not so confident about its wide applicability. I’m thinking about:
    1. Time and effort required for collection of proper and complete business requirements, especially when business users “don’t know what they want” or know it only partially.
    2. Effectiveness of business requirements collection, especially when accomplished by business analysts who do not have proper and/or complete knowledge of the tools/product used. Improper or incomplete BRs impact on the effectiveness of the solution and on the final result of the project.
    3. What do you do when you realize that the gap between BR and solution is relevant (probably you will have to go to the key users, explain what’s happening and what you’re going to do about that gap)?
    4. What do you do when you happen to be working for a customer who impose you user acceptance tests or solution sharing points with the users (usually key business users)?
    I’d like to know how you would structure such a project and how you would face customers how’s asking you UATs or sharing points with key business users during the project.
    Thanks,
    Cristina

  6. Henrik Says:

    LOL

  7. srini Cherukuri Says:

    I do agree with the author, practically very difficult to implement. In that kind of environment the Users will be very hostile and will disagree more with the system.

  8. Russell Kocurek Says:

    This is good stuff! Came here for a web development blog and surprised to see this, but then again, you obviously know what you are talking about.

Website Design & Build: tymedia.co.uk