Kanban for Portfolio Management
The very presence of the term Portfolio Management (in the Programme/Project Management Office context) in your organisation would suggest your organisation is of the Analytic mindset. This means it is a necessary evil for you right now and Kanban can certainly offer you some help in this space. The first two core principles in Kanban (1) Make all work visible, and (2) Limit your WIP are very relevant.
I’ve used the board design above at a number of organisations to make the portfolio visible and to limit the work in process. The backlog is prioritised with the highest at the top and the lowest at the bottom. I’ve seen some orgs divide this up further to show where the project is in it’s lifecycle – Initial Business Case, Budget Review, Approval, etc. The next column is used to drive out priorities and to give each capability visibility of what they may be working on next. The WIP should be self explanatory but each WIP box links to the backlog of a team Kanban delivery board and you can only have one project in flight for each capability. The done column would normally be self explanatory but it is normally an interesting discussion topic – when is a project done? Portfolio managers have a tendency to roll people off a project before it’s finished in a mad rush attempt to get started on another project. The consequences of this behaviour is evident in the short changed project closure activities. Portfolios are extremely bad at absorbing variation in the form of unplanned demand. Unplanned demand often comes in the form of changes in regulatory compliance, security threats, or defects and completely undermines the “portfolio plan”. The capability column is used to identify how the demand is going to be serviced. This includes internal staff members as well as 3rd party suppliers. The rule here should always be that an individual can only be in one box and not shared across multiple capabilities.
The message to execs and senior stakeholders should always be “what project do you want to finish next rather than which one do you want to start next” – thanks to Mike Burrows for that one!
The most important point that I’d like to highlight is that the Project Portfolio (aka Enterprise Portfolio Mgmt) is just one of many sources of demand placed on the system (org). You need to design a system that can service all sources of demand and absorb variation as the norm, not the exception. If you attempt to optimise the portfolio (even using Kanban) you will sub-optimise the whole. The use of a Portfolio level Kanban should be a stepping stone to a better place, but don’t get too attached to it!
Systemic Flow Mapping – Mature Synergistic Mindset
When an organisation has truly eliminated the chasm between dev and ops, when teams are aligned by value stream, and when you no longer have teams but capabilities, you may be in the Mature Synergistic zone. The organisation depicted in this flow map no longer have any hand off points. All staff that service these value streams act as a single tribe with a sole goal for moving value across the boards as a unit. Most staff are generalists with specialist skills. All types of work are serviced by the value streams, i.e. BAU, defects, maintenance, incremental enhancements. Having separate teams for Support, BAU, and Strategic Projects was eliminated several years ago. Big strategic projects don’t exist, in fact, the whole concept of a project is alien in this world. To have a project initiation, elaboration, implementation, closure is impossible in a world where cycle times are several hours. Having cycle times never longer than days but regularly in the order of hours is nothing special to this org – it’s just the norm. This organisation is constantly reviewing and adapting its capabilities. Staff are constantly striving for the ability to rapidly create new capabilities in response to market opportunities. Working for this organisation is deeply satisfying and very fun indeed. Annual reviews don’t exist. Staff provide feedback to colleagues in real time constantly looking for learning opportunities or simply to vent (yes, they still have frustrations).
Systemic Flow Mapping – Early Synergistic Mindset
This early synergistic organisation has started to orientate team structure by value stream. They still have big challenges around the last mile of delivery by the constraint introduced by operating a centralised release team. The release team themselves are dependent on many other teams within Ops. This operations team are fully ITIL and COBIT compliant. The Head of Dev and Head of Ops are now working more closely together after years of doing battle.
Systemic Flow Mapping – Analytic Mindset
Flow within the Analytic organisation is almost non-existant. The Systemic Flow Map above represents a public sector organisation in the UK. The detail is not that important. What is important though is the number of dependencies from many teams throughout the entire organisation. The chasm between Dev and Ops is present and yet the two are so dependant on one another. This diagram looks complex – because flow in the Analytic org is complex. This organisation is extremely silo’d with many centralised teams structured around skill set / discipline. Politics are rife being driven by tribal traits so each team:
- Has a revered figurehead dedicated to the team’s success
- Possesses objects of value that embody the team’s value, normally in the form of documentation (FRS, Test Strategy, Operational Acceptance Checklist)
- Often develops its own unique language – “it’s a Marketing thing, you wouldn’t understand”
- Act to secure their self-preservation if their security is under threat
- Has many enemies – each other!
These are just a selection of traits covered in the book “Great Boss, Dead Boss” which I’ve found evidence for through my org change work.
Systemic Flow Mapping
Systemic Flow Mapping is a technique for visualising organisation-wide flow, bottlenecks, and constraints. Its aim is to provide enlightenment into wasteful, inefficient, and stressful workplaces helping to inform and shape organisational change using Kanban.
Systemic Flow Mapping facilitates the implementation of Kanban at scale showing the negative systemic impact of local optimisation and provides alternative mental models to affect change.
Organisations tend to have multiple value streams. Most large organisations are complex. Making sense of the various value streams is difficult. I’ve developed this mapping technique to help with the visualisation of multiple value streams in order to understand more about the wider implications and decisions in organisational structure and flow.
I’ve identified a number of organisational structure anti-patterns that I’ll be writing about and will be publishing real examples of Systemic Flow Maps. This is very early experimentation so any feedback would be appreciated.
20:1 ratio of inspectors to developers
20:1 is a common ratio of inspectors to value generating individuals in an Analytic mindset organisation. Ok, so the ratio will vary dependant on the size of organisation but this demonstrates the imbalance caused by the silo nature of most orgs. On a recent government project here’s a list of “inspection” job titles involved in the project:
- Governance & Controls Manager
- Governance & Controls Analyst
- Test Delivery Manager
- Service Acceptance Analyst
- Operational Acceptance Manager
- Service Desk Transition Manager
- Head of Programme Management Office (PMO)
- Quality Analyst
- Quality Manager
- Head of Development
- Service Introduction Manager
- Systems Development & Support Manager
- Project Manager (x3)
- IT Security Manager
- Environments Manager
- Head of Standards & Compliance
- Standards Consultant
- Risk Analyst
- Risk Manager
- PMO Analyst
All of these individuals were involved in a small website project consisting of 1 x BA, 1 x QA, 4 x Devs and is the result of a one-size-fits-all approach. Often these roles act as a sign off gate to ensure quality is present but as we all know you can’t inspect quality into a product.
This is just one of many traits of the Analytic mindset organisation that I will be blogging about over the coming weeks.
Mobile phones and children
If the current breed of Service Management /Help Desk products such as IBM’s Maximo or VMware’s Infra are relics of the Analytical mindset, what would the tools of a Synergistic or Chaordic mindset look like?
Analytical Mindset
I’ve observed many disturbing behaviours driven by the current breed of tools commonplace amongst the organizations locked in an Analytical mindset:
- All of these tools are based on a push mechanism so bottlenecks are prevalent, an expected norm, and not even understood as a problem
- Through the use of ‘specialist’ service groups they create complex workflow processes and thus actually reduce overall flow (customer lead time increases!)
- Service staff are abstracted away from the customer through 1st/2nd/3rd line support hierarchies and thus rarely able to priorities or even start to comprehend the business value of the tickets raised (until he who shouts the loudest intervenes)
- Ticket resolution targets are common, often disguised as SLA’s. In order to hit the targets some staff may prefer to work on low-value / easy work instead of work with a higher business value. They always find ways to ‘cheat’ the target.
- Armies of people are employed to operate these applications and don’t actually service any of the tickets and thus add no value. Often charged with process improvement by implementing more complex workflows and generating reports against flawed SLA’s. And so, the cycle goes on…
Not only do these tools drive the wrong behaviours but also they bake them in as fixed processes without any ability to easily adapt. Numbing the excellence that is human interaction and thinking.
Tools of the Synergistic and Chaordic mindset
I’m not against tools. I accept that tools can be useful in lots of situations and equally applicable in the Synergistic or even Chaordic mindset. If the current tools (designed to control the analytical mindset) are so flawed, what will the new breed of tools look like? Are we starting to see some of these future tools emerge with the likes of Rypple.com? So, here are my requirements for a new breed of ITSM software:
- New tickets raised are placed in the organisation backlog (not allocated to anyone).
- There is only one backlog (or queue).
- Tickets in the backlog are automatically deleted (hard delete not soft) after 2 weeks (orgs to the extreme right of the Marshall model will be less than this, possibly deleted daily).
- Tickets in the organisational backlog are ordered by priority, highest priority at the top of the pile.
- Only the top ticket in the pile can be taken.
- Anyone accessing the application can change the priority of any tickets in the backlog.
- Each staff member in the service organisation can only work on one ticket at a time.
- More than one member of staff may work on a single ticket.
- Anyone in the organisation can take a ticket off the top of the pile.
- A staff member cannot start another ticket until the one they’re working on is complete.
- If a staff member has to stop working on a ticket for any reason to pick up another one then the dropped ticket is deleted (hard delete not soft) and the amount of time expelled is added to the waste stats.
- The application does not support any concept of service groups or teams.
- The application does not require a login nor does it have any concept of users, permissions, or roles.
- The application cannot send automated emails to inform users of changes to tickets.
- Tickets only support 3 states – Backlog, Work In Progress (WIP), and Done.
- Only tickets with a state of Done are persisted long term.
- Each ticket has date/time stamps: date created, date WIP starts, and date when the ticket is Done.
- There is only one free text entry field for a description (limited to 140 chars – not related to twitter!)
- Stats are displayed in the application dashboard. The stats displayed are current throughput, current lead time, current cycle time, and current waste.
- All tickets in the application are searchable via free text search.
I suspect the requirements above will seem unfathomable to the analytical mindset. Think carefully about the consequences of these requirements and the behaviours they will drive.
Mobile phones and children
My 6-year-old daughter asked me to buy her a mobile phone recently. She justified it from a safety perspective so if she needed help she could simply call me and I’d come to her rescue. When I was a child, if I got lost or stuck in a difficult situation I had to figure it out for myself and think on my feet. I couldn’t simply call my parents. I never came to harm, I always found my way home. Again, think carefully about the consequences of this.
Royal Mail Experience
I recently came home to find a little red card had been pushed through my letter box from Royal Mail informing me of a failed delivery. If you’re not familiar with these cards they are a simple pre-printed card which the postman ticks a box and hand writes some details on to. The card doesn’t contain any serial numbers or anything specific to the parcel. I placed the red card to one side.
A couple of days later whilst out and about I realised I was passing the Royal Mail depot so decided to pop in to collect the parcel. I didn’t have the red card with me but I did have ID and proof of address. When I got to the counter I explained that I didn’t have the red card with me. The postie headed into the back and brought my parcel to the counter. He then explained that I couldn’t have it as I needed to bring the red card in. He said all he could do was put the parcel back out for delivery the next day. I suggested he writes me a new card (from the pile of blank ones in front of him) so I can save Royal Mail the expense of another failed delivery. I explained that I wouldn’t be in the next day. The postie then said “don’t worry, you’ll get another red card that you can bring in and collect the parcel from here”.
Lessons not learnt
At a recent public sector client I spotted this end of project “lessons learned” document sat in a cupboard with a layer of dust on it. Nuff said.
Pastures New
I recently joined ThoughtWorks after many years as an independent coach. I made the jump from contract to permanent for a number of reasons:
- On several recent client engagements I hit a number of constraints. Mainly around only being able to be in one place at one time. This is particularly difficult when attempting to introduce improvements to several disciplines, Dev, PM, BA, QA, and Ops. Being able to tap into a wider talent pool drastically improves the chances of success.
- ThoughtWorks share a number of principles of my own and are by far the closest fit for me than other orgs I’ve considered. As a global consultancy, ThoughtWorks provides me with diversity in terms of the variety of clients to work with and the broad range of talented individuals to work with.
- Sense of belonging – a powerful human trait. Although I’ve built many close relationships with clients over the years it’s always been on my mind that I’m not part of their organisation and as such an outsider. Anyone who has worked with me over the past few years will be familiar with my thoughts on tribes. Kind of ironic talking about tribes and not being part of one eh?
