Why change way of life?

Did you fulfil your New Years promise to start a healthier life in January?

Change is hard on an individual level and even harder within an organisation. You must have a clear driver of why doing the change, but also why doing it now and not later.

Every movie is about change. Something happens and the lead characters life are changed forever. Without this critical moment, there will be no movie. Think of Spiderman without Peter Parker bitten by a spider. No signification changes to his life and thus no story.  

When proposing a larger change in an organisation, there is always resistance, but also prioritisation due to limited resources. If you can’t motivate why doing a change now, you will have to struggle for a long time until you get your funding.

Take technical debts as a prime example of doing later syndrome.  Why should I start upgrading my old systems to a new version now, instead of waiting until next year? Why should I start training at a gym this month? I could start in the spring instead.

If you want to get funding for your next project, you should explain why start now and not later. The larger project and budget, the more important it is to explain why the timing is so crucial.

When you viewing the next feature movie, watch for the moment that initiates the change in the beginning.

 

Use of patterns and templates in other industries outside IT

What is the benefit with patterns and templates when working with business requirements?

We could raise our view from the IT sector and instead look on the wide screen. When going to a cinema or viewing on-line, films are grouped by genres to make it simpler for the audience to find what they want. Would you like to see an action movie like Dark Night or a musical as La La Land today?

Save the Cat! by Blake Snyder

Save the Cat! by Blake Snyder

If you want to write a script for a feature film, you will be far better off if you start with a standard plot. Whether you follow Christopher Booker’s The Seven Basic Plot, Blake Snyder’s Save the Cat! or Ronald Tobias 20 Master Plots doesn’t matter.

With business requirements, the same is true. If you use TM Forums work for telcos or HL7 for healtcare, you are using the experiences of other people to speed up your work and avoid common mistakes.

However, using a template doesn’t mean that you don’t need the skill for the craft. Reading Save the Cat! wouldn’t result in an Oscar nomination unless you put down a lot of hard work and talent. 

If you want to write a manuscript, start learning the genres and an basic plots used in them. If you want to write business requirements, learn the frameworks in the industry you are working in.

When writing a manuscript, use the tool you like and could afford, but follow the industry standard structure for a screenplay.

When writing business requirements, use the tool you like and can afford, but follow best practices who to write business processes and business requirements. You will not win an Oscar, but there are other ways to measure success in IT.

1) What is story? http://www.scriptmag.com/features/craft-features/what-is-story-story-types-plot-types-themes-genres
2) TM Forum - http://www.tmforum.org
3) Health Level Seven International - http://www.hl7.org

 

 

 

 

 

 

 

 

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.