This book, which covers the years from 1993 to 1995, is a depressing view of the inside of a multimedia project run by young, Generation X Microserfs who sincerely believed in the company vision. Although, with a company that large, that diverse and that disorganised, I think the vision couldn’t be seen for the re-organisations.
The book follows a group of 20 somethings from the initial ideas of the multimedia project (called Sendak until it’s official name of Explorapedia was chosen,) through to almost the delivery stage. And there are two over-riding themes that contribute to the almost failure of the project: unclear lines of control and indecisiveness.
Let’s look at these in turn.
Production Manager, Project Manager, Art Director, Lead Programmer and Chief Coffee Maker. (Okay, I make that last one up.) Throughout the multimedia project detailed in this book, the roles people undertook always seemed to be fluid in their meaning and responsibilities. One reason for this was that, as Microsoft was growing so fast, internal people were often promoted over taking in external hires and so some quite young staff ended up in fairly senior positions. People who once worked as equals, were now supervisor and supervised. Which might not be a bad thing, but without the proper training, could be quite catastrophic in the personal and professional relationships of all those involved. Here, this was experienced as the previous Art Director on another project was now the Producer (or the other way around, or the Production Manager – I should have taken notes while reading it,) and it wasn’t always clear who had what responsibility. So, one person was sometimes jumping in and doing the other’s work, and as the project went on, there would be re-organisation after re-organisation which lead to mass confusion about who exactly the decision makers were.
We trained hard, but it seemed that every time we were beginning to form up into teams, we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising; and a wonderful method it can be for creating the illusion of progress while producing confusion, and demoralisation.
– Petronius Arbiter, 210 B.C.
It just seemed to be the Microsoft Way.
The other problem with this project was the scope of what was being produced. The clearest voice of reason in all of this was the cranky programmer, who knew quite well when things had to be finalised, and not changed in order to have the code finished and tested to meet the ship date. The programmers, as the ones doing the work in the last stage of the design and development process, always appeared to be the group that had slipped and missed their milestones, rather than the designers who had missed their deadlines at the beginning of the project because of an inability to make a decision, and stick to it.
And here’s where the traditional Project Management Methodology and also Agile Project Management Methodology can fail: once a decision has been made, even though it’s software, it costs a lot to go back and re-engineer something. This project almost failed because the scope was a wibbly-wobbly kind of thing that the team never really got a hold on, wrestled to the ground and took control of. As such, late in the design and early development stages, fundamental changes were introduced that changed the game (literally.)
So, what can be learned from this? Make sure that the client (even an internal client) knows that a change in scope means changes in time and cost. It’s an immutable law of Project Management, and I know we all know it, but sometimes we need to state the obvious. Also, experience pays off – in software development most people are in their 20s, and now that I’m not, I can look back and see how inexperienced I used to be, and how much there really is to learn about process management.
The project shipped, many people were burnt out, angry, demoralised and just plain over it. But in the end, as we all know, we just get back up again and walk into the maelstrom for one more go, because we believe this time it will be better – it just has to be.
Finally, one criticism of the book: I kept getting lost with regards to who was who. Sometimes the author would use a person’s given name, and then later in the book, their family name, and then back again. So, as people changed positions, I didn’t know who the Project Manager was from the Producer to the Production Manager. It’s a small quibble, and really in the end it doesn’t distract from the book.
But overall, it’s good to see that the problems we might be having now, aren’t new. And that we can learn from history, as short as the history of software development is.
