Contact

On The Nature Of Portfolios - Managing Investments - Projects

On The Nature Of Portfolios - Managing Investments - Projects

“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the Solutions within Lean Portfolios but an exploration of the Problems to understand whether the Solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.

Managing Investment

The past few blogs have been exploring some of the detail of Epics, primarily feedback and flow which themselves became topics for investigation as a result of investigating the prioritisation mechanic Weighted Shortest Job First.

There is still more to explore with how Epics are set-up but the next few posts are going to take a detour into Managing Investments and explore some of the detail of how the money is handled.

Projects

I’m probably committing heresy within the Agile Community by even mentioning Projects, but there is nothing wrong with Projects.

Projects are not inherently evil, they’re abused

Projects are a funding mechanic that brings together People and Work in order to achieve an Outcome. Once the outcome is achieved, the work is done and the people are released to go elsewhere. It’s a great mechanic for one-off endeavours where the group of people that do the work are not the people that will own and maintain the output once the work is done.

Funding Mechanism : Value Stream vs Project

Figure 1: Funding Mechanism : Value Stream vs Project

The problem with the Project mechanic is that it starts to fall apart when applied to IT systems, because it is rare for a piece work to be a one-off; most IT systems are being continually developed. A funding mechanic that stops the money for a group of people when they need to be retained1 doesn’t make much sense. Dismissing the people that were involved in the initial construction is allowing knowledge to escape from the organisation; knowledge which often needs to be retained. Also the Projects in many organisations are drawing from an existing workforce and it’s not uncommon for individuals to end up working on multiple projects at the same time; work is being done in parallel with all the overhead that that entails.

A mechanic that funds long lived, stable teams with dedicated team members would be more appropriate; hence SAFe proposes funding Development Value Streams, that are realised through Agile Release Trains. An investment is made in people which generates capacity to do work; work is approved to consume that investment.

Separate Funding from Execution

Separate the Funding mechanism from the method of Execution. Projects or Development Value Streams are Funding mechanisms and shouldn’t dictate the method of Execution. The method of Execution could be the traditional approach of schedules, Gant charts and phase-gates, or it could be very Agile using iterations and feedback loops.

Many of the arguments from the Agile community against Projects arise because people conflate Project Funding and Sequential Delivery together when they are separate.

Is There Still A Place For Projects?

A few years ago I was working with a major Middle-Eastern Airline and they posed the question of when would a Project be the appropriate funding and governance mechanic?

After some thought; the following logic emerged.

Horizontal Axis determines Funding Mechanism


The horizontal axis represents “The Change” that is being enacted; is it a “One-off” change or part of a “Continual Flow” of changes? If it is a “One-Off” then the transient Project mechanic is appropriate; if it is “Continual Flow” then a Permanent mechanic, such as a Development Value Stream, that can process that flow is appropriate. The mistake that is often made is to consider each individual change as a “one-off” rather than to step back, take a more Systems Thinking view, and see them as a set of changes to the same underlying thing. The horizontal axis deals with the Funding mechanics.

Vertical Axis determines Execution Mechanics


The vertical axis represents “The Problems” within The Change; do they need to be solved or have they already been solved and The Change is enacting solutions? If problems need to be solved then Agile approaches that can deal with the uncertainty inherent in problem solving are most appropriate. If the problems have already been solved and all that is required is to follow the instructions then sequencing mechanics are most appropriate. The mistake here would be to think that a solution exists when that solution is really a sequence of problems that still need to be solved. The vertical axis deals with the Execution mechanics.

These two axis combined produced the follow quadrant diagram:

Quadrant Diagram


To illustrate this with some real-world examples:

The Middle-Eastern Airline is in the process of building a new airport terminal, this is a one-off activity that isn’t expected to happen again for another 20years. It also requires skills and expertise, design and construction, that don’t exist within the Airline’s workforce whose skillset is targeted at maintaining and flying aircraft and looking after guests travelling on those aircraft. As a one-off activity that needs external expertise the Project mechanic is appropriate. The work receives the funding, construction contractors are employed to do the work and they go once the work is complete.

The act of designing the airport is problem solving; the result is a set of drawings, schedules and instructions for the aforementioned construction contractors. The architectural design, the structural issues, crowd movement analysis are all problems to be solved. An agile approach would be appropriate since it deals with the uncertainty inherent in problem solving, therefore the Airline should run a Project using Agile techniques; fast feedback, prototyping and regular interactions between architects, structural engineers and customer2.

The airline has a Ticketing System that issues tickets; variants of the Ticketing System have been in-place since the airline was founded and there will always need to be some way of determining who is eligible to fly. The system needs continuous updates as the airline explores new ticketing opportunities and as the regulations around flying evolve. Setting up a Development Value Stream that supports, maintains and improves the Ticketing System3 would be the most appropriate mechanic. As long as the airline issues tickets there will need to be a ticketing system and that ticketing system will need support, hence a permament team supporting it.

The airline regularly services their aircraft; there are well defined procedures that define what needs to be checked and what remedial action should be taken in the event of an issue being discovered. The problems have already been solved; there are instructions for dealing with the issues; they just need to be enacted. This is Operations; doing the activity. It should be predictable; metrics and measurement can be gathered around how the activity is performed and used to improve future repetitions of the activity and also planning and prediction for future repetitions. Classical Lean from manufacturing.

Real World Examples


A Rose By Any Other Name Would Still Smell As Sweet4

In the Agile world view there is nothing to stop an organisation setting up a Development Value Stream to deliver an Outcome, staffing it with external contractors and once the Outcome has been delivered and handed over to the Operational side of the business then the contractors are let go and the Development Value Stream ceases…

Should you use projects?

Probably not for IT work; or by extension anything that is continually manipulating underlying assets such as mechanical or electrical designs.

They are an ideal tool for one-off endeavours; but you have to very critical when assessing whether something is truly a one-off endeavour.

Why mention them?

Whilst a SAFe Portfolio is deliberately constrained, by definition, to managing Development Value Streams; real world Portfolios may still need to manage the occasional one-off activity and running it as a Project might be an appropriate method. Remember to separate funding from execution; Projects can be Agile.

Perspective counts

Clients and suppliers can have different perspectives on the same piece of work. From a client perspective is might be a one-off, and therefore a project, because they only need the work doing once. From a supplier perspective, where this client piece of work is just one piece of work out of many that is being done, a Value Streams approach should be taken.

What Next?

Next stop is Participatory Budgeting; SAFe provides a lot of information about “what you need to do” in terms of process to follow; but the “Why are we doing this?” is often missed out. Therefore an exploration of where Participatory Budgeting came from and why it evolved is worth covering and then a dive into some of the subtleties of the process that are easy to lose sight of when trying to stage a Participatory Budgeting event.


#1 If they are full-time employees then employment law and contracts may mean that they can’t be dismissed once the work is complete.
#2 It’s only a Project from the perspective of the Airline; if you view this from the perspective of the Architects then this is just one piece of work amongst many that are flowing through the Architect’s design studio and the Architects could be operating in a similar manner to a Development Value Stream.
#3 The Airline provide (and retains) business knowledge in the form of Product Management and Technical Strategy in the form of System Architects; the engineering effort is contracted out to a 3rd party supplier.
#4 William Shakespeare, Romeo & Juliet, Act II, Scene II.

Contact Us