Write business requirements as a Hollywood manuscript

Writing business requirements is not easy, so how can we improve ways of working with requirements?

Example from Final Draft

Example from Final Draft

One option is to look how they write a manuscript in Hollywood.

A film manuscript is described scene by scene according to a well defined structure,

  • The location where the scene is
  • Description of the scene in detail
  • What the actors do
  • What the actors say

and everybody in the business understand how to read this manuscript.

Based on the manuscript, you plan the production so that you have everything needed when shooting on set, not more, not less.

If you did a poor job during planning, you need to redo your shots or persuade the producer that you make some slight changes to the agreed story so you will be ready on time and within budget.

Business requirements are like scenes in a manuscript. The less detail we have when starting production, the less chance we have to know what we deliver.

The other problem in filmmaking how to avoid a fiasco, e.g. that our dearest film become a turkey instead of a Golden Globe winner and box-office-hit. 

In the manuscript, and when writing a storyboard, you have assure that all pieces fit together for the feature film. Sounds like a large IT project, where somebody should be responsible for the whole, not only the separate parts.

How to review a solution design?

Often, I don’t have the detailed knowledge of a product, programming language or a system, so what I do is to review the basic foundation for the solution design.

If you can’t explain why, what and for whom, the chance of making a design that fulfils a need is very limited. 

The design may not work in real life or there may be problems later in the project, so I agree with Greger Wikstrand that requirements management is a process during the whole product lifecycle. 

When staring a review, I present this short list to involved parties as a template of how to make a thoughtful review in a consistent manner.

  •  Principles and guidelines from the strategies
  •  Purpose and goal for the project or product
  •  Value and cost for the calculated lifetime
  •  Business need and/or business requirements
  •  High-level information model
  •  Functional requirements 
  •  Non-functional requirements or product requirements 
  •  Solution design including integrations to other systems 

The next step is asking them what parts they see as their responsibility and ask if they have a processes supporting their work, or if it’s more or less an ad-hoc approach. I don’t evaluate their decisions to omit different parts or selection of methods, or the lack of. Depending of the size of the project, complexity, time, importance, skills etc, those decisions may be correct.

What I do, is to analyse the parts and make a risk evaluation and point at those things can go wrong. If the risk is to high and the reward is to low, or unknown, my recommendation is often to halt the project and to redo, re-schedule or change the scope. Eventually make some proof-of concept development for critical parts. 

However, the normal outcome is a lot of yellow and green lights for the different parts. The recommendation from me is therefore often to adress the concerns in the development and to be followed up by the project manager. 

This method for review works very well for waterfall projects, but if you see each sprint as a small waterfall, this approach is also usable in agile projects. As the scope is much narrower, the effort to make such an assessment is also much smaller. 

So, if running an agile project, ask yourself who is responsible for each bullet from the list above and if is it described in some kind of documentation.