I work supporting and developing Business Intelligence solutions, a job that is all about changing things: updating a table layout in a database, changing an IP address in the ETL, adding users to the OLAP tool – pretty standard GitHub/SourceForge chores and the like. So when I was given a chance to review the new Impackt book, Practical Change Management for IT Projects, I dove in, little knowing how mistaken I was and how happy this misunderstanding was about to become.
Reading the book was like seeing the sea for the first time: wow! There is a whole field of corporate change management, with people planning and rolling out a change in detail!
I work with a large (+10.000 employees, US$1Billion/Year) brazillian federal government IT company and we do plan our rollouts (for new systems, new process, new softwares, corporate culture change and so on), but the book addresses it in a deeper level than we have ever done. The author writes with focus, with the tight and well constructed sentences only those who had done something a lot are able to use. You can see it is so and not a professional polished text because among the concise wording, here and there, you can spot some odd constructions, and sometimes the train of thought is strained a bit too long, even for the native English speaker.
Managing the Change without Chance
If Change Management, the discipline of planning and conducting some change in an organisation, were a shrink-wrapped product, this book would be its instruction manual. It neatly explains what change management is and how the change eventually go around happening (or not.) She explains what are and and then identifies the components of a change (the “Pillars of Change”), the participants, the components of a change program and finally she lays out a project pattern for making the change happen in an orderly fashion. So there is quite a detailed work break-down, with roles, activities, milestones, deliverables, documentation (with templates and credible examples), control meetings. The whole shebang.
Concurrently, and I believe this is what add most value to this book, while the author presents all the information and the method she walks the reader trough every piece of it by using a Case Study set at the beggining of the book. In it, Acme Corp is adopting a new buying system in replacement for an old one. This change must happen in every division of the company and, to makes things look worse, this very system holds a sizeable amount of responsability for the results of Acme. If something goes awry this fictional company profitability might be badly hurten.
The Only Constant is Change
Practical Change Management for IT Projects is worth every penny. If you might be affected by change anytime, buy and read it at once. It seems Change Management is not that widespread discipline as is Project Management so it might be possible your company has never heard about it in that formal way. I am no novice on corporate life and it strucks me with some shame I have never seem it around. I am at ease to confess my loss at it just because the last words in the book are saved for telling you (the reader) the importance of the awareness of Change Management, that this awareness is key to success and how to rise it. Hence, to share those ideas and the book are an important exercise alongside everything else.
The Hands Down
I must admit I became an Emily Carr’s fan. I enjoyed reading the book by its sheer style, the upbeat never-surrender-never-retreat attitude. There is some inspiring grandeur in how she poses the problem and the hardship everyone faces daily, and the feeling she imparts on the need for change just makes you feel good.
Well, now that I said how much the book is worth and much I enjoyed it, I can tell what I didn’t like.
To make it sure: the book is good, you won’t regret buying it. However…
She operates the change management on some level of optimism. Unfortunatelly, real companies seem to be much more difficult to deal than Acme. On ocasion she sets some ideal situation that is simply not every time attainable. Some sort of compromise usually kicks in everything we do but she does not acknowledge that much (she doesn’t deny it, thoug.) For instance, on location 2187 she states the extreme importance of having every event you invite user to to be well planed and features a bug-free version of the product involved in the change. Good luck getting it…
She avoids dealing with all the possible variations and cenarios, or even with a small set of possibilities, so everything seems to be under an “ideal world” lighting. Although the consideration on some variability would enrich the book, taking in consideration its lenght, the templates, walkthroughs, insights and tips, by not addressing this much of variability doesn’t hurt the final results and, after all, makes for a more readable and practical book.
Another thing I can spot as some hidden hindrance to the newly broken Change Manager is that she makes it seem so much easy and success prone. There is nothing wrong here, for with some training and a bit of practicing it will probably became easier to drive a change program. The risk is not being aware how easy it is not. She knows how to do and have come confidence on doing it and she stress constantly a Change Program takes a lot of effort to turn in a success, but she writes very well and easily gets the reader carried away (again, nothing wrong – passion is good. Just kiss with lights on, and with open eyes.)
Finally, I couldn’t find any reference to Scrum or some Agile method. The program has a very conservative look of a waterfall planing. Of course if it works out good, I can’t ask for anything else. But Scrum is such a powerfull way of managing project that Change Management, being all about commiting changes, should be connected to it in some way.
As I said, Practical Change Management for IT Projects is very good and in fact a must have: practical, usefull guide on how to make change happen and how to have some control on it. All in all, a good read in all the senses. Its only downsides are some optmism and a couple of beatifull scenarios. I also miss some relationship with Scrum or any Agile technique, but none of those aspects are really an issue.
There is some changing come my way and I am very happy I have mistakenly turned to this book for some dull code-versioning stintch. After all it was not anything I would imagine, but thanks to this misunderstanding now I can really help make change happening, something I didn’t even know about a couple of weeks ago.