System and mindset reset, part 3
August 28, 2018
I’ve enjoyed some moderate success as a project manager over the years. Even though I’m probably digging my own grave here, I believe that we need to unlearn decades of project management training and methodology to work more effectively in future. This doesn’t simply mean that we need to embrace agile project management methodologies.
We need to go a bit deeper, and return to the original purpose of project. The reason for setting up a temporary organization – a project – was to introduce change. The assumption behind the concept of project is that an enterprise is not able to introduce change as part of normal daily work. This is arguably a valid assumption if the change is a major one-off change with multiple stakeholders. However, the changes most of our clients are facing today are likely to be smaller and come in faster, and the requirements are best known by the business experts at the customer interface.
Since change is constant, it follows that projects are constant, too, and the result for most of our clients is that their project portfolios are bulging. Project managers are fighting over resources with each other. Many employees are involved in several projects at the same time and focusing on any specific initiative is increasingly difficult. As a result, projects are not fulfilling their purpose of introducing change, but are in fact holding the organization back.
The natural response to this situation is to try to improve portfolio management and project management methodology overall. If our projects are not delivering, then obviously we’re doing something wrong. If we increase control and require more exact estimates and detailed plans then certainly things will improve? Well, only to a certain extent. If we have exceeded the organization’s capacity to absorb project effort, then more administrative effort will only make the situation worse. When external requirements for changes are coming in faster and regardless of the previous ones that remain unprocessed, many companies are locked in a desperate drive to deliver more projects with fewer resources.
Dependencies between projects increase exponentially even if the number of projects increase only linearly, which leads to an increasing number of delays and showstoppers due to constraints introduced by other dependent projects. This is a very unfortunate race to the bottom that can only result in poor project results and burnout of the most conscientious experts.
This is where agile methods with their limited and strictly prioritized backlog can certainly help. When applied correctly, these methods drastically reduce the number of overlapping projects and force radical prioritization. Agile and DevOps are practical approaches to introduce change faster and to cut software development timeline, but in addition to practical approaches the mindset must change. Business must direct changes, and be enabled with the skills and tools to implement the change. This capability must be built within the organization in the longer term.
The natural role for people like me who have worked as external project managers in the past will be to act as coaches to build this capability. Future business requires experts who can create service that adds value for the customer and continue to run and adjust it for as long as the customer requires. And future business leaders will need excellent technical skills to confidently take decisions that seem to lie exclusively within the ICT domain today.
In addition, the Lean concept of value stream – clear sequence of activities to deliver value to customer – is very helpful here. If we organize the enterprise based on value streams, and perceive the changes that impact our value streams as constant improvement, rather than separate projects, prioritizing the initiatives based on their customer value and focusing on value comes naturally.
This kind of organization structures are becoming increasingly more common among our clients, especially at companies that are applying the Scaled Agile Framework (SAFe). There have been some teething problems on occasions where SAFe has been simply plastered on top of existing structures and practices, and the required mindset change has not been fully understood. It appears that agile practices are only of very limited use if implemented bottom-up, and the project proliferation problem is best addressed through value stream thinking, driven by leadership.
In summary, we can envision a future where we will not work as project managers but as capability builders within our client’s value streams.
What do you think? Do any of these challenges ring a bell for you? Or are you picking up different signals? Please let us know!