From Softjourn’s CEO

Certainly the reason for this book is for promotion for the company which the two authors started. The slogan, “Iterate or Die” became the bywords for their new consulting company, guiding how they wanted to provide their services; short projects, rapid deliverables, etc. 

But can we still learn something from this book? 

Probably yes probably, but the reader has to realize the following first:

• The book was published in September of 2008, probably written a year before that at least, thus dating some of the comments,
• The authors are pro outsourcing,
• To the authors, the difference between outsourcing and consulting is that outsourcing cannot provide a business result,
• The authors do not like offshoring because they believe it cannot include consulting or business changes,
• They do not like big consulting firms,
• They do talk heavily about SaaS (Software as a Service) being the wave of the future (for the date of when this book was written, probably 2007 time frame, it still seems like a dated statement),
• Their firm is a certified implementer of Salesforce.com
• They feel they set out to establish a new kind of business and a new philosophy that no one was doing (which is the usual case when starting a new firm),

If you can live through reading these types of comments which are scattered throughout the book, you can learn something from the book.

What I like from this book:

1)      Certainly the basic premise of applying the agile development methodology to the consulting industry.  Actually most of what they talk about can be applied to a software development project or a business process change project.  Concepts such as time boxing, for example, changes can be accepted if they can be completed within the original time box. Otherwise the change needs to be moved to the next iteration.

2)      Appendix A contains their company’s list of “Laws of Consulting Economics”.  Of particular note include the following laws:

a)      2^nd law of consulting economics – “A successful business process trumps cool technology”. they talk about this from a standpoint that every company should have a Chief Process Officer -
CPO.  This person is responsible for the business processes of the company (a business process is a series of tasks or operations that perform what is consider a logically complete unit of work. 

b)      The 8^th rule of consulting – When it comes to success, communication is everything!

c)       The 9^th rule – The concept of having to rely on a “Great man” to come in and save the day, or some heroic effort to make the whole thing work.  Which they say rarely works, and I would have to agree with that. 

3)      The authors refer to a “New Staffing Model”, which is geared towards a particular business outcome.  My first take on this was I thought the consulting industry had already moved to this model long ago, but I guess what the author’s are referring to is the “staff augmentation” business more so, and that industry needs to be more about what the client is trying to achieve rather than I need one person to be a data base administrator and a 2^nd person who will be a systems administrator, and so on. For that industry I would agree that that is a mindset change on the part of the buyers of those services, but one that is necessary. 

4)      Overall the book outlines a repeatable process that readers can base their own projects on.  Appendix E includes Sample Success Plans that can be modified for the reader’s own needs. 

Some points that I thought were interesting:

1)      The author’s example of the 21^st century consultant– sharing one Database Administrator’s (DBA’s) over several projects.  Not sure why this is a novel concept exactly. 

2)      On page 51 the author’s refer to the question, “Why do companies which need to use IT seem to have to transform themselves in to major IT organizations?”  The idea that you would not generate energy if you did not have to, it assumes IT as a commodity. There is little business sense in diverting funds that should support a company’s core competencies into a major IT infrastructure investment (Perhaps if this book had been written a bit later they would have said that this would be a reason to use cloud computing, as this is one of the common arguments now given for “putting your apps in the cloud”.)  My question is; I can’t believe that this argument is still being used to tell companies that they should outsource.  Aren’t there any newer arguments that could be used

3)      On pg. 72, the author’s state that Agile consulting, as they practice it, will reduce the need for offshoring?  Only because they say Agile cannot be done in a distributed manner.  On this point they do not offer any examples from their experience or the experience of others though. 

Overall there is not a ton new in this book necessarily, but the look at the overall concept of taking the Agile Software Development methodology and crossing it over to the consulting industry is an interesting one, the consulting laws are good points and the success plan outlines are helpful. 

Iterate or Die – Agile Consulting for 21^st Century Business Success – By Eric Berridge and Michael Kirven.  2008