The first sample chapter is going to get out of the printer today or tomorrow. This chapter is about requirements. The title is Extraordinary Requirements Quality. It is printed for my next talk at the Develop conference. I have worked a lot on the Games Industry in the past year. I have studied projects from the inside thanks to a major games publisher. I also have played games like never before in my life. Man, I could tell you some stuff about the experience of becoming a gamer when you are not 15 years old! Maybe in a next article…

At the Develop conference, in Brighton, on the 15^th July 2010, I’ll be talking about actions that can be taken by Studios (and in most cases Publishers) to win more projects. One of these moves is definitely to work on the requirements. This is why I have selected this chapter to be published on that occasion.

If you are interested in getting this sample chapter (64 pages), please get in touch with me. We only print 100 of it, so hurry up in case you wish to get one. The easiest is to leave a message here and I get an email immediately saying you did so. I’ll get in touch with you.

Oh by the way, the full set of Project Cycle Optimization principles will be comprehensively covered in the final book:

1. Mentality Shift
2. Skills Management
3. Extraordinary Requirements Quality
4. Team Goal Alignment
5. Communimatics
6. Improved Production Chain
7. Positive Rule Breaking

Most of the book is already written.

What Picasso was getting at here was that in order to innovate you have to know the processes and rules very well. In fact you don’t even want to know them but you want to live them, breathe by them, make them automatic/reflex.

In the software development arena (e.g. the Games industry) do we sometime suffer from not knowing the processes and rules well enough before breaking the rules? I would say so. In my experience, I have been confronted in numerous situations where projects were in danger of failing. When asked about the reasons for being in danger (completed over 50 projects), more often then not I find the following issues (list non-exhaustive):

• The process is not applied
• The code is not fully tested
• The communication points between business and technical team are loose
• The architecture is not described
• The iterations (assuming agile process) are ill defined

Most of the time, when I am looking for the reasons of these issues, I am finding answers such as: “Nobody really applies the process, why would we? We are better the way we do.”, or “No real time for testing by the book, let’s just apply common sense and save money”, or “We are agile, we don’t need documentation.” Ad infinitum.

Am I missing something here? Because to me this looks a lot like laziness hidden behind the ultimate excuse: creativity!

Let’s think about IT !