I’ve got a feeling that this is going to be quite a long post because I have spent the last two weeks grappling in my head with something that concerns me.

I’ve never been one for Programmes and Projects – with capital ‘P’s – with all the trappings of templates and documentation and traffic light reports but recently I’ve found myself yearning for more structure and more shape to what I am doing. I’ve started to wonder if – in my wholesale rejection of Project methodologies, I have thrown the baby out with the bathwater.

True it has been a bit of a extra messy time with particular big fluxes of events and issues over time.  Lots and lots of uncertainty – maybe the woolliness is getting to the point when I am lost – and if I’m lost then others around me probably are too.  I have started taking action at work to change this but I do want to explore – if not a Project, then what?

Why not a Project

Perhaps first to summarise, why not a Project….why have I decided that they are not the best way of engaging with the types of situations I find myself dealing with.

Project methodologies – such as PRINCE2 and similiar derived from them – include a number of assumptions:

– they assume you can know up front what you need the end point to be.  This means they do not allow for learning.

– they assume linear cause and effect – if you do x, then y will follow.

– they assume the ‘need’ and the context will not change once you start ‘implementing’

– they assume a clear start point and end point – rather than ongoing development

– they have a tendency to split work up in a hierarchy – programme – projects – workstreams – and then allow these to operate in silos – rather than to recognise any interdependencies and how one Project/workstream impacts on and creates a new context for the others.

– people can be good at ‘technical’ project management – completing documentation etc – but not so good at change management with all the interpersonal skills and facilitation skills that that entails.

My thinking on this very much resonates with the way Ison (2010, 224-229) articulates it.  He talks of a ‘projectified world’ – projects are so much part of how we do what we do it is almost impossible to imagine a different way of engaging with a situation.  He draws on Bell and Morse (2007) as follows:

Bell and Morse describe a project as ‘defined activities carried out by defined people with a defined end point in mind at a defined cost and over a defined period’.  They go on to outline how ‘projects are popular with those responsible for spending money’ and ’embrace a targeted set of activities with a clear aim (and hence cost) and hence accountability that can be maximised’.  This allows, they argue, limited time-horizons for spending the budget and the achievement of targets allow a long-term commitment to be circumvented or even negated altogether.

Ison, 2010, 224

He also echos Bell and Morse’s thoughts that we are so keen to complete ‘projects’ that we give little thought to issues of lasting impact and sustainability of outcomes.

So, why do I feel ‘lost’?

Recently, I have wanted to grasp onto something to give working life more structure, more form and more ‘rigour’ and the only thing that seems to crop up in my mind – the obvious thing on offer is Project management.  I know that mainstream/conventional Projects and the methods I described above are not the way to engage with situations that are full of interdependencies, multiple perspectives, complexity and controversy BUT I am tempted by the fact that:

– the documents act as boundary objects – if you can get everyone to agree to something at least you can start moving forward – rather than get stuck in a spiral of exploring and sharing views and bringing new people on board.

– there is some rigour – you do have to spell out what you are doing and why.  The production of a document helps you know what you know and think through what you don’t know – simply the act of putting language to your swirl of thoughts (as I am doing now) makes you learn more about where you are.

– Projects help you carve up and give names to the different pieces of work you are involved in.  It helps you think – now I am going to focus on xxx, rather than see everything as so inter-related that you cannot act – the trap of holism.  Projects are ways of ‘bringing forth’ or ‘identifying’ or ‘distinguishing’ something you are doing something about from all the rest – in the language of systems they help you draw a boundary and move on.

I know that I am not the only person grappling with this tension – how to have shape, structure, direction without setting in stone and narrowing down.  So with that in mind I have been scouring various OU course books, following up references, taking sneaky previews of books on google books and amazon preview.  This post is as much to catalogue what I have touched on – as I am not sure I am getting to any conclusions.

Lessons from development management

Development management stemmed from those involved in third world development, though many of the principles apply to what we would call ‘regeneration’ in the UK.  Development management accepts that social change is happening anyway and acts to intervene in social change to take it in a ‘desirable’ direction.   In TU870 Capacities for managing development, I read an article by Korten (1984) called ‘The learning process approach’.  Korten contrasted:

A conventional model of development programming – called the Blueprint approach – which emphasises careful pre-planning and  faithful execution of the project plan.  It fits well where you can have allocation of funds for precisely-stated outcomes, reliance on ‘hard data’ and expert judgments, and clearly-stated, costed implementation schedules.  Examples would be physical infrastructure projects.  Korten highlights that the approach is not suitable for rural development – where there are multiple, ill-defined and changing task requirements, unpredictable resource-needs, and constantly changing environments.  His particular criticisms of blueprint approach includes “where there is a need for a close integration of knowledge-building, decision-making, and action-taking roles, it sharply differentiates the functions and even the [..] locations of the researcher, the planner and the administrator” (page 182).

with

The learning process approach – that he drew from empirical data of three successful case studies – these were not designed and implemented but emerged out of a long-term learning process.  Korten observed that the overall process in his case studies could be broken down into three stages – each requiring a different type of learning.  Whilst he describes them as stages, he points out that these are abstractions of a largely disorderly and intuitive process – in essence they are visible in retrospect but were not planned in advance….

– Stage 1: Learning to be effective – developing a familiarity with the problem in question from the beneficiary’s perspective and trying out some promising approaches.  Likely to be common errors and a high resource needed relative to results.  Need rapid adaptive action.

– Stage 2: Learning to be efficient – once have an understanding of what to do, attention is given to learning how to do it more efficiently.

– Stage 3: Learning to expand – redirecting attention to the phased development of supporting organisation/infrastructure so that the activities can be repeated at a larger scale.  Building supporting skills, management systems, structures and values.

Korten’s article concludes:

A basis can be found in current experience for the formulation of alternative and more appropriate programming frameworks and methods based on a learning process approach which recognises that in working with [local] people, our knowledge of what is needed and our institutional capacity to do this are both limited.  There should be no calls for endless research.  But neither should there be continuation of blind action based on inappropriate statements of the problem and ineffectual implementing organisations.  The challenge is to integrate action-taking, knowledge-creation, and institution-building into a coherent learning process.. (page 188)

It’s not a surprise that Korten’s views of blueprint planning are so similar to mine – given that his work has been one of a number of things that have formed my own views.  He gives a strong case against blueprint planning in projects that aim for social change – that is a helpful case to use at work.  But, the difficulty for me as a practitioner is how do I translate his description of what he has seen happening in successful programmes into designing my own work – after all a description is not a prescription.  Blueprint approaches seem to go with an accepted toolkit – the project initiation document; the GANTT chart; the traffic light report and so on.  Korten does not offer any alternatives to these or tips on how to plan for/design in a learning process approach.

Lessons from software development

I have to say this is a place, I never thought I would go.  But it seems that most google hits for project management go back to the world of engineering in general and software development in particular.

Being married to a software developer, I have actually heard of the Agile approach.  The Agile Manifesto explains the principles that underpin the set of practices that make up the approach.  As I understand it agile is a way of working that has developed in response to the problems of the traditional ‘waterfall’ method. So, there is a now familiar distinction…

– waterfall – traditional – assume the customer knows in exactly what they want, linear thinking, define everything in advance then programme, assume nothing changes during the development phase etc

– agile – more flexible, changes are inevitable and so on.

In software development there is a tension between time available, quality of the work and features implemented – this tension is usually represented as a triangle.  In waterfall, you do not compromise on features so time and quality inevitably vary. It works on getting a fully functional product in front of the customer. In agile, your variable is features implemented – quality and time are non-negotiable.  It works on getting a working product in front of the customer to help them develop their understanding of what they want – potentially changing or adding features.

The practices of agile uses some interesting metaphors:

– a story – describes a functional feature of the software described from the perspective of the user – an example would be ‘the user must be able to log-on’.  Some stories are higher level than others and can be broken down.

– a sprint – describes a timebox during which you achieve a certain number of stories – the time is fixed – the number of stories cannot be planned in advance you only know what you can do in retrospect.

– a scrum – is the team of people, with different skills that you pull together for a sprint – together they can do what is required for that sprint

– a burndown chart – is the way of measuring progress as it demonstrates the number of stories completed.  Over time you can get an idea of the number of stories completed in each sprint and can use that to calculate your velocity – your velocity can then start to give you an idea of when you may finish all the stories.

I am not sure how exactly but I am sure some of these ideas can be transferred across to ‘my world’ of organisational and societal change.  I am reliably informed(!) that the original set of people who developed agile ideas were both practising programmers and computer scientists – what they seem to have achieved is good integration of theory-informed practice.

Lessons from the world of design

I better clarify here that this is not a big leap from the last section as the particular author I want to draw on is writing about software but this time from a more theoretical design perspective.  However his work seems to be quoted more generally around design… and when I read it I found he has drawn extensively on a familiar systems thinker – Schon.

Ralph (2010) starts of by highlighting an ongoing conflict between those who view design from a Reason-centric perspective and those who view design from a Action-centric perspective.  Yes, it is that now familiar distinction….

Reason-centric perspective:

[this is] consistent with a cognitivist view of human action wherein actions are executed and understood through a plan and defined as “a sequence of actions designed to accomplish some preconceived end” [Suchman, 1987]. Plans are prerequisites to action. Unanticipated conditions trigger replanning; evaluation is performed by comparing resulting and planned actions and outcomes. (page 140)

Action-centric perspective:

Social constructivism posits that knowledge is derived from social interactions. Building from social constructivism and empirical studies of professional practice, Schön devised the Reflection-in-Action design paradigm, where design is a reflective conversation between the designer and the situation. The designer alternates between framing (conceptualizing the problem), making moves (where a move is a real or simulated action intended to improve the situation) and evaluating moves. Multiple agents may collectively reflect in action using boundary objects (page 142).

I’m going to try not to go off at too much of a tangent just now but my real-time inquiry took me off into a exploration of ‘design’ itself – prompted by a consideration of what can planning and the world of organisational change learn from design.  In addition to reminding myself of Ison (2010) discussion of design turn (as per this post) I found some interesting references and feel quite energised by them. ‘Designing projects’ has a much more creative feel than ‘project planning’.

Lessons from landscape design

Dugal made a comment to one of my posts about a term coined in his work of landscape design – the greenprint.  He mentioned that he first came across the term in one of the OU’s environmental management modules. Unfortunately if I search the term in google I only come across large commercial organisations touting consultancy or green printing processes – so can’t pursue the idea in other literature.

The way I understand it from Dugal’s comment is that a greenprint is a design that allows for growth and development as understandings change.  I can see that working in a very real way in a landscape or garden when you plant things and have no way of knowing whether they will grow in the way you intend them to and need to prune, re-plant or fill gaps further down the line.  But actually, maybe it is also a good way of stopping people locking into blueprint assumptions – referring to your up-front intentions as a ‘greenprint’ with an explanation that you are intentionally designing in learning and development.

Lessons from action research

Those who follow my blog chronologically will know this is something I have been reading up on recently particularly drawing on Coghlan and Brannick (2010).

Action research is an umbrella term applied to a wide variety of activities and methods.  It stems from the academic world as some researchers have sought to move away from the conventional way of seeing themselves as ‘objective’ or neutral observers of research subjects producing knowledge that must then be ‘transferred’ to embrace ideas of active self-engagement, participation and joint knowledge creation.

The general approach introduced by Coghlan and Brannick (2010) talks of an action research cycle that people in an organisation undertake together with the support of a facilitator (who may or may not be the ‘researcher’).  The action research is essentially a home grown ‘change’ project conducted in a way that engenders and allows for changes in understanding and practice (learning).

The cycle proposed is made up of:

– A pre-step: context and purpose – seeking an understanding of the context of the project – why necessary and desirable? what is driving change – externally and internally?

followed by four basic steps:

– Constructing – participants jointly construct a provisionally agreement of what the issues are – as a working theme – on basis of which action can be taken

– Planning action – focussing on first step or series of steps (not the whole journey)

– Taking action –

– Evaluating action – examine outcomes of the action – does it fit with the original construction? what feeds into the next cycle?

So you end up with a spiral of action research cycles.  These run sequentially – each providing the pre-step for subsequent ones – but I guess you could have some smaller concurrent cycles at particular points in time.

What I like about these ideas is they do provide some structure and a role for ‘documentation’.    This is different from usual use of Project documentation which tend to be written in isolation by the project manager as a ‘technician’ and ‘approved’ (or otherwise) by others before becoming a guide for ‘control’ and ‘implementation’.  In action research however documents seem to become a record of where the group feels they are – what they understand at a point in time and what they are going to do about it.  The documentation is more like a co-produced structured group journal and can helpfully act as boundary objects to demonstrate to others how understandings and practices are developing.  There seem to be lots of synergies with the Schon’s action-centric perspective of design described above.

Lessons from systems practice

Perhaps this is something that cross-cuts all my lessons so far.

Ison (2010, 260) points out that there is no set prescription for systemic inquiry, they have to be designed.  So it is with learning process approach, agile approach, action research and systems approaches like systems dynamics, viable system model, soft system methodology, and critical system heuristics.  The point is all these approaches and methods give you are sets of concepts, tools and ideas which you have to draw from and use – a smorgasboard of choices, not a set menu.  In other words you have to juggle the C-ball.

So I set myself the wrong quest – I was looking for a new prescription or recipe to replace Project methodologies – a new ‘how to’ something to grab off the shelf and run with.  But actually it is the idea that there can be a one-size-fits-all recipe or prescription that is unhelpful – any prescription means that you stop taking responsibility for how you engage with a situation and contextualising tools and methods to do what you need to do.  The point is that for everything I do I will always have to start out with the widest possible choices of how to engage and how to intervene – each time the design needs to be unique.

Rethinking project management

I end with a narrative of hope.  As I finally settled down to write this post and bring all my scattered bits of exploration together I decided to follow through on one final author name that caught my eye in Ray Ison’s book.

I’ve learned that from 2004-2006 a set of academics led by Mark Winter at Manchester University responded to criticisms about mainstream project management ‘theory’ and set about redefining the research agenda more suited to what practitioners felt they needed.   The project was called Rethinking project management.  The final report – available here – has at page 5 a really interested table calling for five new Directions in project management research – it really is worth viewing the detail in the table but here are the headlines.

Theory about practice

Direction 1 – to move from the lifecycle model of projects and project management TO theories of the complexity of projects and project management

Theory for practice

Direction 2 – to move from projects as instrumental processes TO projects as social processes

Direction 3 – to move from product creation as the prime focus TO value creation as the prime process

Direction 4 – to move from a narrow conceptualisation of projects TO a broader conceptualisation of projects

Theory in practice

Direction 5 – to move from practitioners as trained technicians to practitioners as reflective practitioners.

Source: Winter et al (2006) cited in Rethinking project management final report.  NB The International Journal of Project Management published a special issue on Rethinking project management – Volume 24, Issue 8, Pages 635-734 (November 2006) – which expands on all these findings.

They stress that these shifts are about enhancing the current position not discarding it.  I see lots of resonance with Systems practice which recognises the expansion of the systematic to the systemic.

Mark Winter, the lead on this work has since published a book with Tony Szczepanek called Images of Projects.  It challenges how we think about projects and says we should not think of projects and how to do them from a ‘single’ perspective.  They posit that the image or pre-conceived ideas we have about a project will affect the action we take – and therefore say we need to make an active choice to see a project from different perspectives to deepen our understanding of what it is and increase our repertoire of possible actions.  Just from looking at the contents information I can see that they offer up seven core images of a project (which they think of as “temporary purposeful action”)

• projects as social processes
• projects as political processes
• projects as intervention processes
• projects as value creation processes
• projects as development processes
• projects as temporary organisations
• projects as change processes.

I am struck by these images and how they parallel some of the questions I have had as I have been exploring the world of Projects – what is the link with change management? what could be the possibilities for social interaction and social learning? how does what I have learned in development management help?    I also see from some of the content that is available through the ‘look inside’ on Amazon and the publishers information that the book draws on some familiar ‘systems thinkers’ especially Checkland (who wrote the foreword) and Schon. It seems that the ideas I have developed through studies and experience have brought me to a similiar – though less developed – place as Winter and his colleagues.

So the project ‘word’ is here to stay – but the way we conceive of them and understand how we do them could be on the brink of a big change – wonder how long these ideas will take to reach local authority managers – perhaps I can play a part in that…. 🙂

References

Bell, S. and Morse, S. (2007) Story telling in sustainable development projects.  Sustainable Development 15 (2), 97-110 [cited in Ison, 2010, 224]

Ison, R. (2010) Systems Practice: How to act in a climate-change world, Open University/Springer, Milton Keynes/London

Korten, D. (1984) ‘Rural Development Programming: The learning process approach’ from Rural development participation review 2 (Ithaca, N.Y. Rural Development Committee, Cornell University, Winter 1981), pp 1- 8.  The research on which this paper is based in documented in detail in a much longer version: “Community Organization and Rural Development: A learning process approach“, Public Administration Review, September – October, 1980, pp 480 – 510