Finally, we are back online after a malware attack took out the earlier site!
Managed to replace most of the earlier posts but would like to do much more capture of Enterprise Release Management knowledge.
Why not register on this site or join/contribute to the ERM group on LinkedIn.
Let’s grow the awareness of ERM’s value as a community.
Posted in Backstory
The interplay between change and complexity is a major contrubitor to our tendency to flip-flop between agility and control. I discuss this tendency in my ERM book and show that it goes beyond the more recent agile methods. More importantly, it can be expected to remain an on-going theme in the debate over the right level of governance and oversight needed to manage skilled professionals like those found in technology projects.
I found the change-complexity grid (shown at left) useful during my PhD research for categorizing different viewpoints in the literature and it remains key in identifying the “method gap” shown in the fourth quadrant; characterized by high change and high complexity. This is the difficult environment that ERM is designed to address by means of a release-centric approach to managing multi-team/ multi-project environments .
The new dashboard represention, aka the Release Matrix from my PhD, and its associated techniques are derivable from the matrix and can help coordinate and schedule work across several teams. As a simple, self-organizing framework it offers improved communications and visibility across interdependent collaborating teams.
In writing on the need to scale agile methods in software development I have extended the familiar “embrace change” mantra, first introduced by eXtreme Programming, to encompass complexity. Have a look at the article published in the Agile Journal entitled Embracing Change and Complexity.
PS: Can I just add that I really dislike the image they chose to attach to it!
I vividly recall the event that started me on the road to writing Enterprise Release Management: Agile Delivery of a Strategic Change Portfolio. The experience was unsettling for me as an advocate of project management best practice, and forced me to address the real-world challenges faced by those managing projects in the enterprise.
The catalyst for my ERM research, and ultimately the writing of the book, was an innocuous incident as I was leaving the office late one evening. As I made my way towards the door I noticed a fellow project manager still hunched over his desk. I casually asked what was keeping him back at work so late. He said he needed to send out last-minute instructions to a contractor to include an important fix in their release scheduled for the weekend. I knew then I wasn’t going to get home in time for dinner!
I explained that I had just sent a similar message to the very same contractor. It was about a different feature that also needed to be included in that release. But I had no visibility of his project’s requirements and he knew nothing about mine– yet both our projects impacted the same contractor. How were these distinct instructions to be interpreted? What were the implications of these two changes being in the same release? Would they be compatible with each other? And what tests were needed to ensure compatibility?
A few hours later, with the whiteboard filled and urgent phone calls made to the relevant managers our impromptu release planning session came to an end. I finally headed home, frustrated at the loss of my evening but also relieved that we had averted a potential disaster. The lack of visibility between the two separate streams of work gnawed at me. How could something like this happen in a relatively mature project organization which was diligently applying current best practices?
Like many practitioners in the field, my colleague and I had stumbled upon a key limitation of the accepted project paradigm. In multi-project environments like most enterprises, the hidden dependencies between projects can make successful deliver a challenge. Some fundamental assumptions about project management breakdown and we have to accept that projects no longer exert the same control as they once did. In the enterprise, projects are not greenfield but are vehicles for delivering change – and those changes are no longer isolated.
The event that was the impetus for my research into management of a change portfolio is becoming more commonplace as our reliance on core IT systems and business processes cause projects to become interdependent and intertwined. Addressing these dependencies requires what I call a release-centric management approach that seeks to bundle or package projects into enterprise releases – much as we routinely do for more granular changes. While it may seem like a heresy to question the traditional project management thinking, there is mounting evidence that we are facing distinctly different challenges today. My book aims to both make that case that it is time to look to release management and offers new enterprise-level techniques to ensure that a change portfolio is delivering what the business needs – without the last-minute, chance identification of inter-project dependencies as occurred that fateful day.
There is some irony in writing a book about a more agile development lifecycle and having to go through a painfully waterfall publishing process.
As someone working in software/IT I naturally planned to write my book using an iterative process, expanding and refining on key features (chapters of the book) as the product took on a coherent form. After all, words are just text and so it is relatively simple to have passages updated, moved or replaced just as we change source code. Even MS Word has the ability to track changes, compare versions of a document and highlight the differences. I have often used these features to write whitepapers and articles, collaborating with contributors and editors across the world by sending new versions of a document via e-mail and tracking the modifications we make.
So the analogy between book writing and software is really not that strange (one would think!) even if change tracking in documents is less sophisticated that software version control tools. Yet I discovered that the process used by book publishers is rigidly waterfall. I was informed that is because page formatting is sensitive to even minor modifications, but one suspects that it may be because “that’s the way they have always done things in publishing.” Certainly reducing the number of iterations removes the complication of managing changes and while I can appreciate that viewpoint, I also expected publishing a book to be a much more collaborative process. An overly rigid waterfall process can serve to exclude those best able to review and contribute to the quality of the end product. And as an author, I felt somewhat left out of the final stages of the product lifecycle – simply a content producer with little input into the finished product.
So, I may as well confess that I still have not gotten over the fact that my book has a boring textbook style cover and I am clearly grumpy about the fact that my “much more elegant” cover design was rejected. As well, each convoluted sentence or minor error in the finished book causes me frustration as they could have so easily been fixed – certainly as a part of a more collaborative final review phase but also if we had used a more flexible medium than paper. With e-books there is no real inventory and the update effort and cost significantly less.
From first-hand experience I can tell you that in any publishing effort it is important to try and retain control over the final product. However, that is not easy while traditional publishing houses are the principal means of distribution and dissemination of information. The publishing industry literally views a book as a product, but in this era of electronic publishing that assumption is being tested. While authors still want the prestige of having a publishing house distribute our books, as a digital medium e-books will clearly be disruptive. The next iteration of the publishing industry can benefit from the experiences in software and we can hope that publishing becomes a more agile and inclusive process.
An indispensable perspective for business leaders, IT professionals and project managers working to effect positive change in their organizations, this innovative book presents a new paradigm for the management of evolving business and IT architectures. Enterprise release management takes a holistic view of change that offers a synthesis of traditional management approaches, including portfolio, project and change management, enterprise architecture, and development practices like configuration and release management.
Instead of simply focusing on portfolio prioritization and selection, this practical reference establishes an end to end release framework which ensures initiatives are planned and prioritized to streamline portfolio execution and delivery. Benefits of the release-centric approach advocated include reduced execution and operational risk, improved demand management and optimized release throughput. This unique book introduces a new intuitive notation that supports strategic change and the release life cycle, providing executives and managers with the tools they need to chart and track the course of their business.
• The Evolving Enterprise
• Embracing Change and Complexity
• The Enterprise Pattern
• The Project Paradigm
• Release-Centric Planning and Design
• Delivering the Enterprise Release
• The Enterprise Release Paradigm
• The Enterprise Release Life Cycle
• Practicing Enterprise Release Management