Exploration is about finding the new. It it fuelled by our curiosity and creativity to find the new point B world that we are not yet aware of. We start in our point A world, and the journey is at least to some extent about art, creativity and the challenge to break new ground. There are many business situations where it is not possible to plan for, or to clearly articulate, a future state in a non-ambiguous way. I believe that programmes are better than projects in dealing with quite a few of them, as proper governance, guidance and sense-making is key.

Beginnings are delicate times

A common enterprise approach to deliver new business outcomes is to setup a pre-study with the intent to detail down the future. It includes a best guess of the technology needed. The project management and steering group hope that the estimates and ideas are good enough to match the time constraints that are either deliberate or real. And then all involved are pushed to deliver exactly as per the plan despite the deviations that inevitably occurred due to the unexpected and unknown, but significantly more complex, parts.

Unhelpful and painful project experiences

Painful project experiences are neither healthy for morale nor trust and provides a less than good foundation for the next big project. There should be a better way.

Agile methods help us on the technology side, and sometimes on the business side of things as well. These methods may not be suited to handle the communication plan, change management, business roll-out and/or physical construction projects that can be rather complicated, costly and with needs to manage them in a project-oriented way. These activities together are better steered as programmes than combined “projects”. We need methods to manage interdependencies between the constituent parts, and help manage collaboration between the initiatives to deliver the sought business benefits.

The steering group and the experts

I get extra excited with what happens early in the management of new initiatives, the interplay between the early project team, the steering group and, if already formed, the reference group. Good and meaningful goals and roadmaps are defined, benefits are identified, and deliverables get broken down into their constituent parts. Unfortunately, without enough domain expertise, it is hard to assess how hard the deliverables will be to deliver. It is wise to bring in experts to take a hard look at the deliverables and really listen to what they have to say: are the deliverables unambiguous and clear enough to be part of a project? If not, this text may shine light on other options.

To define a future, we need to know our capabilities

I have a background with various roles that connect teams that build technology with process and capability managers, in initiatives ranging from small ones, to larger ones up to 50 people. In the management of these projects, we have seen that whilst the completed deliverables is not yet very clear in the beginning, there is still a lot of technology that can be prepared. The technologists often just need a general direction to get going, while the finer details usually needs quite some time to develop for the business representatives. We also see that the technology will take significantly longer to build than the business has patience for. They usually need to see the technology to fine-tune their view of what will be possible once the technology exists. There is a natural tension between the teams in the apparent catch-22 situation.

To move from point A to point B

We start at a known point A world, and move towards a yet unknown point B world, a world limited only by our imagination. Agile software development was created to accommodate ambiguity and the emergent nature of knowledge about the end result. In the move towards the new point B world we are expected to have a general direction and willingness to decide on just the immediate, and most important, next steps. We need to trust that the steps will be the ones most helpful to implement now. The agile process expects us to learn and uncover the details of, to emerge, the new point B world gradually over time. Read more on the personal journey from point A to unknown point B worlds in Amy Whitaker’s book Art Thinking: How to Carve Out Creative Space in a World of Schedules, Budgets, and Bosses, I borrow from her way of expressing the journey in here.

Deliver strategic capabilities through programmes

Agile delivery is a mature delivery method, however most companies are not yet mature enough to budget innovation as Operational Expenditures, and to operate their business as continuous innovation. There is also a need to scale up innovation, which often does not lend itself to do using OPEX, and should rather be done with CAPEX, Capital Expenditures. What we see is a need to encapsulate these initiatives, to build new strategic capabilities, into programmes that bring the sought business benefits.

No matter if the initiatives are big or small, the importance should be placed on whether the expected outcome is clearly defined – likely a project – or ambiguous/unclear – a programme. Parts of the benefit realization may be clear, and those parts should preferally be managed as projects for efficiency, while others aren’t, and should continue either as pre-studies or as emergent agile development initiatives. The governance that comes with proper programme management is crucial for this fruitful coordination.

Programmes are not big projects

Thiry makes the point that programmes are not big projects is his PMI Conference Paper on Agile Programme Management paper, especially now that corporate strategies are in constant evolution. He describes agile programme management not necessarily as big programmes. The key is that they deliver benefits that are of strategic importance or are part of the strategic plan.

In working with several large enterprises, I still see too many projects allowed to be run with a less than a clearly expected outcome. This is a far too common practice: to evolve the technical solution in more or less defined ad-hoc methods, that often, incorrectly, tend to go under the name of agile methods. It is a sad state of affairs. The common view is to see programmes as large projects. We should look at the realization of intended benefits as what we do, rather than defining outcomes and technical solutions. To run the technology development in ad-hoc mode is often a significant waste of resources, as only limited learning and development occurs. The key to strong agile delivery is the possibility to learn, adapt and evolve; to bring the possibility of autonomy and mastery to the team. The project will stifle the development in it’s search for efficiency, rather than to attend to the work and seek customer or receiver value.

The acceptance of ambiguity and uncertainty

Our increasing dependence on innovation and its implementation rests on our capacity to accept ambiguity, uncertainty and experimentation, and deal with it. The implementation rests with our organizing of the efforts in the direction of business benefits rather than to forcefully define the exact outcomes that will soon be dated no matter what we do. We should rather define projects only for outcomes that are very clearly defined, and expected to neither change, or challenge use to think differently when they are completed. To be clear, what I believe we ought to do, is to define programmes in ways that bring both the technology realization and the business change effort into common initiatives, and not separate them. We need to, within the programme, have to accept that they are different in nature, and do follow a different cadence.

Benefit realization in smaller increments

Practically, the organisation of initiatives into programmes allows us to define the benefit realization as smaller individual initiatives and contributions, and use the best methods to deliver each. The building and acquisition of technical infrastructure can be accomplished as soon as a detailed roadmap, vision and expected business benefits are defined. The detailing of change efforts can be handled as a proper project, with the relevant milestones and preparation of each step of the way. The communications and solution marketing can be developed as individual mini-projects, with external or internal initiatives created based on the delivery method that suits best.

Budgets for programmes

Budgeting becomes more manageable as expected expenditures and outcomes for them can be handled differently for the different domains, fixed personnel for agile, fixed cost for projects and risk buffers as needed. The budget is also easier to adjust, as the programme learns the details of what the compelling vision of the future really means practically. The value creation from the agile development streams can be measured, and projects have a higher likelihood to stay within budget as they get clearer without ambiguous, unknown or unclear components.

It’s not scope creep silly

The business and project managers alike may frown and say it’s just a fancy way of allowing unlimited scope creep. Scope creep is a project term for what happens when you know what the outcome was suggested to be, and what gets delivered is different from it. When you don’t know the point B world, the term scope is irrelevant, which is the very reason such a journey can’t be one of a project. Parts of the delivery can have a fixed scope, and is suited for a project within the programme. It is the reason that we should talk about benefits (programme world) instead of outcomes (project world) when what we do is emergent. When we seek benefits and know that we can’t define the outcomes precisely in advance, we should view what we do as emergent work and likely engage in sense-making of the complex reality we see.

Analysis paralysis, or the acceptance of ambiguity

When you can define quite accurately what you want from the start, it ususally doesn’t challenge the receiving community. With the delivery of software, an organisational change or an infrastructure project, the community will be challenged by the outcome, and change their minds; the requirements and the parameters will evolve. More analysis would not make a difference with the latter, the community will perceive the point B world differently from what the could have anticipated. We need to accept that our minds will change over time, and accept the ambiguity and uncertainty, and allow the possibility for further evolution.

The path trodden will be the shortest possible,
yet it may be longer than we had anticipated.

We will need to be willing to trust that we are seeking a direction, rather than a specific goal. We need to know that the goal likely will change over time as we get more knowledge from learning, and wisdom from our experience. We do know that our path to the benefit realization will be based on our best knowledge and what we have learned throughout our journey. The path trodden will be the shortest possible, yet it may well be longer than we had anticipated.

Definitions of done defines projects

To enable delivery of a project, we need to define it in reasonably clear ways, and what every aspect of the outcome will look like during a pre-study, as definitions of done. Failure to define the future state should lead us to refrain from letting a turkey project off the ground. A well-run pre-study should clarify the business benefit we seek and whether the specific outcomes will realize that business benefit. When the Scope, the effect of the Time, Cost and Quality constraints, can be clear, it makes sense to run our initiative as a project. When the Scope is not clear and we can see that we don’t know it in detail, it’s likely that we either need to learn more to start, or be constrained enough by time to take a leap of faith and trust, and build a programme instead. We would then embark on a journey of emergent discovery.

Accept the journey when you have to

A programme is not a big project, it is something else. It is a collection of entities that bring benefits together. The orchestra can be made up of several projects and agile delivery methods. The advantage of separating project concerns from their agile development cousins is that while they each need each other to build the interdependent benefits, they are each less risky on their own.

The agile development parts deal with the complex and emergent nature of building software and technology stacks while the projects can deliver documentation, change management phases, roll-out sequences and repeatable activities. The programme in itself can fine-tune, adapt and develop the vision of the future to navigate as the world changes and new knowledge becomes available. It also brings the governance and senior leadership needed to resolve and support each initiative.

I takes courage to navigate from our well known point A world to a new, and perhaps frightening, point B world. We often feel the urge to define it, the thing we deal with, and shoehorn it into a neat box before we enbark. And yet, it’s not always possible to shoehorn things, and we should instead find ways to choose our actions wisely when presented with relevant forks along the road.