Where We Stand
The role of the project manager in Agile is often a complicated one. While there is little concrete direction by many of the frameworks, it is often understood that a traditional project manager may often find themselves moving into a Scrum Master or Product Owner role. The intent behind this guidance is clear, there’s no need for a Project Management Office (PMO) where we’re going. I disagree. Let me introduce the Lean PMO.
The fundamental difference that I would like to see, as the PMO adopts Agile, is the move from push to pull. Traditionally the PMO can be seen to act as a controller of work, managing the flow of work across the system. We know that in a complex system, this is where madness lies. In order to “improve” predictability, excessive policies and control mechanisms are implemented. We lash everything together in the hope that we can somehow control the work enough to be predictable. Quite often, this also involves the control of people. Unfortunately, in our desperation to prove our 12-month-old guesses “correct”, we compromise on the hidden aspect, quality.
Problems with Push
There are myriad opinions on the negatives of operating in a pull system, but here are a few of my biggest concerns:
- Decisions being made in isolation, often far removed from those who are “accountable” for executing on the work
- Work does not necessarily have strategic alignment with the overall outcome for the group or organisation
- In a push system, we typically see multi-stage functional handoffs, this results in organisational fragility. Ever been in a situation where the whole thing grinds to a halt because one key person is on holiday?
- As a result of narrow and deep specialisations, there is a general feeling of low empowerment
- Poor visibility and transparency as a result of disconnected units
- When work is being pushed through a system, its momentum is often maintained through HiPPO (Highest Paid Person’s Opinion). When we have differing, or non-existent, prioritisation, we are not likely making decisions based on economic principles
Switching to Pull
So what sort of things could we expect from moving to a pull-based system?
- Improved predictability. A reduction in waste will lead to narrower histograms when we map our lead time, this reduces variance and will improve the predictability of our work items
- The ability for teams to self-organise based on capability and capacity. This, in turn, improves autonomy and reduces waste
- By implementing a pull system, we are better able to ensure a smooth flow of work into, and through, the teams
- When teams pull work according to their capacity, we reduce the frequency and severity of “crunches”. This is where work backs up against an ‘immovable’ wall, such as a sprint end date. By reducing this intensity of work at the last second, we expect to see less required overtime and improved time for innovation
- Given enough time to complete work appropriately, we should also see an increase in quality. If we’re constantly struggling to hit deadlines, then it’s usually quality that gets cut
So where does this leave us?
So this is all well and good, but where does the PMO sit in all this? Historically we would have it in the middle, attempting to control the flow of work across the system. In the Lean world, I see it as perhaps the most perfectly placed entity within an organisation to facilitate change.
The traditional aspects of portfolio management can move to the strategic. Instead of attempting to manage work when it becomes entangled in the system, we can assist in managing the flow of work into the teams themselves. By reducing our overall organisation work in progress (WIP), we would expect to see a decrease in lead time as a result. For greater detail into strategic PMO, see Flight Level 3. By focussing of strategic initiatives, we drive down accountability into the teams for operational or tactical work.
I started compiling a list of behaviours and roles that I would like to see a Lean PMO model. However, the inimitable Mike Cohn has not only got there first and also done a better job. I don’t necessarily agree with all of Mike’s points, but would like to discuss some that I do.
Responsibilities of the Lean PMO
Coaching and Training
Moving away from a controlling role enables the PMO to become a support function across the entire organisation. We commonly see this as part of the journey to Teal or Green, entities previously inextricably linked to the value stream become an expert pool that can be pulled into the teams on demand. The PMO traditionally has incredible expertise in a number of specialist areas, such as governance, reporting, tracking. I propose that this expertise becomes available to teams according to their need.
The PMO is often the deepest and broadest source of data within an organisation, let’s start using it as effectively as we can. At a glance, I expect we can pull much of the following directly from historical project data:
- Lead time
- Cycle time
- Failure demand
- Defect rate
- Flow efficiency
- Blocker data
- Work item profiles
This is an amazing opportunity to start helping the teams track and learn from their own metrics. By showing the art of the possible, we can inspire continuous improvement across the entire organisation.
Value Stream Mapping
With the PMO focussing more on the strategic level, we should be in a better position to understand where we’re experiencing bottlenecks in the system. Briefly, Value Stream Mapping (VSM) is a Lean technique where we can map the activities required to deliver value to the customer, from request to completion.
By mapping out these activities, we can begin to understand where non-value adding work is creating bottlenecks in our system. We often focus on improving the “doing” parts of work, but these are rarely the areas that can benefit most from improvement. When focused on the “doing” work, we are simultaneously isolating ourselves from the customer and neglecting areas that would deliver greater value. Personally, I don’t care nearly as much about streamlining a 1-hour test activity as I do about reducing a 3 day wait for test capacity to become available.
VSM is often implemented within teams as part of their Lean journey, but I would argue that there is greater benefit in applying this practice at the strategic level.
Neatly segueing into my next point, becoming data-driven and mapping our value stream allows us to start crushing waste. By waste, I mean the non-value adding activities that negatively affect our key metrics.
Software waste is another article in itself, but here’s the list originally developed by Tom and Mary Poppdieck.
- Partially done work
- Extra features
- Task switching
- Management activities
Do any of these resonate with your context? The PMO is in an ideal position to begin tracking and assisting the teams in dealing with these activities. By applying waste-reducing theories at the strategic level, we can benefit the entire organisation, ultimately making lives that much better for our customers.
Building a Lean PMO
I firmly believe that the PMO, (Project or Portfolio), is one of the most perfect bodies for change in the modern organisation. Moving from push to pull and control to coach, repositions the PMO as a critical function for positive and evolutionary change. By modelling these new behaviours and supporting the organisation’s transformation, we can significantly increase the chances of success for the adoption. Furthermore, it leaves valuable change agents within the organisation once the consultants have left the building. This is one of the most important aspects. Transformations often fail because they stall. By leaving organisational capability to continue supporting it, I expect to see improved chances of sustained benefit.
As a coach at DevOpsGroup, I have been fortunate to apply some this thinking in a very practical way across a number of organisations. In my next article, I’d like to share the method by which I’ve been able to assist these companies in their transition to the Lean-PMO.