Vision

Marsden Project Services: the Company’s Vision

Project managers often seem a bit like referees in a sporting contest: if they do their job well, no-one notices them, if they do it badly, everyone is aware of exactly how they messed it up.  How to avoid messing it up?  I think the keys are:

  • Planning.  Plan as early and as thoroughly as you can.  Before you start to construct or deliver anything, in other words before you do any ‘doing’, do lots of planning.  And before you do any planning, plan lots of planning.
  • Seeing the bigger picture.  Make sure you never lose sight of the business needs and benefits of the project.  As a project manager what you are delivering isn’t really the physical finished article – a new information system, a building, a bridge, or an out-sourced business function.  What you’re delivering is the business capability that this end product will bring about.   Keep your attention on what things the project is dependent on and what is dependent on it.  If the world changes before the project is finished – if there is a new technology or method that will do things better, if the targeted return on investment can no longer be attained – it might be better to bail out of the project
  • Communicating.  Consult and engage widely before the implementation stage of the project.  Make sure everyone involved, everyone who has a stake in the project, knows what is planned and how it is intended to happen, and minimise the extent to which any of these stakeholders can trip the project up.
  • Getting things done at the earliest available opportunity.  This might be fundamentally against human nature: why do I find I have a pile of shirts to iron late on a Sunday evening, when I’ve had all weekend to do it?  But this is perhaps the essence of project management.
  • Programme managing.  Projects seldom exist in isolation, they are usually part of a portfolio of projects that needs to be planned, prioritised, approved, scheduled, funded, resourced, implemented, reported on, reviewed, completed, if necessary deferred or cancelled, evaluated and archived in harmony with the other projects the organisation is carrying out.  Programme management.
  • And, if at all possible, have some fun while doing it.

“I support my professional body, the Association for Project Management (APM).  www.apm.org.uk.”

Bill Marsden, 11.11.12

 “The biggest fragility in a project is often just the inability to be able to explain to people why you are doing it, and when you’re going to do it, and what’s going to happen.”

Lord Coe (interview in The Guardian, 12.11.12)

“I’m not necessarily his biggest fan, but I agree with this – and the Olympics and Paralympics were fantastic.”

Bill Marsden, 11.11.12

Some Thoughts on Agile Project Management

Clearly, it is becoming more widespread… and I’m worrying that by sticking to traditional PPM principles I might be falling behind the times, becoming old-fashioned.  But, I find that the principles of Agile PM challenge some of my firmly held beliefs about project management, and about how to approach business in general.

In the following remarks, I am thinking of business projects (information systems, organisation mergers, outsourcing and so on), rather than projects in the engineering, infrastructure or construction fields.

If I can give a crude summary of my probably limited understanding of it, Agile PM urges us not to fix the project’s scope so firmly, not to make detailed, rigid plans for delivering the project, not even to think it is finite, but instead to accept, as Eve Mitchell of PWC(1) has it, that “Change is a ubiquitous feature of modern life.”  And that “Organisations across the globe are changing their working practices and business strategies to embrace the complexity and interconnected nature of a rapidly changing business environment and a shifting global economy.”   The article explains that embracing the complexity means acknowledging that it can’t be controlled.  So is the traditional ‘waterfall’ method of managing projects self-defeating?  In striving to plan, delineate and control, do we only make it inevitable that we will be punished for our inevitable failure to see into the future, that scope-creep will have to be accepted, putting strains on the project’s budget and the quality of the work delivered?  Would it be better to accept that any project that will take more than a year or so to deliver will have so many unknowns that its final form will only be known when it has been reached.  The benefits claimed for Agile Project Management include early receipt of benefits, a client-focussed approach, greater involvement of stakeholders, better ability to respond to a changing environment and re-position the project to pursue a revised set of objectives.  Traditional Project Management can often be criticised for a failure to respond to change in the environment such that by the time it is completed – the information system or whatever it may be – it is no longer fit for purpose.

Agile PM emphasises (according to the ‘Manifesto for Agile Software Development’, http://www.agilemanifesto.org/):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

So is it time to ditch the traditional methods?  I’d be interested to see research; is it working in practice?  Being an old cynic, I have a suspicion that some of the firms promoting such an approach might have a vested interest in keeping the objectives and scope of their projects loose and constantly changing – so they can keep earning fees from re-defining them.  I have probably seen this practised.

For my part, I think that the traditional and the agile approaches can each benefit by adopting some principles from the other, and that Project and Programme Managers should be prepared to be flexible, and tailor their approach to the nature of the project, the client and the stakeholders, and be agile where it will work.  It’s an interesting debate – and I’d be happy to hear of the experiences of practitioners.

Bill Marsden, 15.4.13

Mitchell E, “Are ‘waterfall’ and ‘agile’ project management techniques mutually exclusive?”  Project Manager Today, March 2012, pp 22-26.

Some thoughts, in the form of a diagram, on the Programme Management process…

The following is perhaps a bit generic and simplified, but it attempts to describe how I see the Programme Management function in an organisation that has to carry out multiple projects, of varying types, aimed towards different business objectives, and sponsored by different business units/directorates. Because I am highlighting the Programme Management role, the flow chart has simplified the corporate management, project management (implementation) and operations areas.  This isn’t because I think they aren’t as important, but I wanted to fit the diagram on a single slide with a focus on Programme Management.

Bill Marsden, 19.11.12