Thursday, 30 December 2010

Change on the way for Digital Project Management?

As the last posting of the year, it is traditional to step back, review the past and try to project into the future. So here we are. Is digital project management at a crossroads? Should it be? Where does it serve us and where does it fail us? Pretty strategic questions, in keeping with that backward/forward look, don't you think?

We could feel a bit complacent because we've championed Agile software development methods where traditional waterfall methods of software development were found lacking. Agile engages changes, moves iteratively in small development cycles, incorporates more feedback from the client and users and so on. Yes, it did have a few glitches like how to cost the process so that a company didn't just address the old problems without getting paid for the work. But the important thing was that the software development process changed fundamentally.

Now there is chatter about employing such software development processes wider in business processes. Imagine that. The implications are huge. The keys in the process are the faster response to perceived need and small, incremental steps. Others in business want these too. It isn't just a large percentage of IT projects that fail; many business projects fail to achieve their objectives. So business analysts have been assessing the situation and have become attracted to the concepts of agile. Various new names have emerged to define the business processes but we'll be able to recognise the origin. Neil Perkin, New Media Age 2nd December in, 'Digital could give firms the agility to change', equates the need for agile processes with a coupling for companies to accept failure in a cycle of revision where the failure is fed back quickly and remedied. This is rather like the fast release of agile code, the checking on its feasibility of use and the revision of the code accordingly. Change has to be embraced in companies in a culture of innovation and 'well structured experiments'. He quotes McKinsey (2005) about putting 75-80% of a budget into proven media but the rest into these experiments. (You need to register for the full article)

Other advocates of applying such processes to other business problems can be found at:
Maybe all this will have impact on the way we scope projects for new clients. Perhaps we'll have to educate them in which processes they might want to employ to dictate the way they want their project managed. They may need to consider what strategies their company wants to use in general business and which they want in project management as a result? Complex stuff - but what dreams used to be made of!


  1. The last couple of years has certainly seen an increasing adoption of Agile project management for digital projects as clients increasingly embrace the notion of the 'perpetual beta' and want to get to get to market quickly. I have found myself hiring developers who can use this approach, advising start-ups to adopt it and working as the interface between a global corporate client and an internationally renowned agency as Agile programme manager and 'product owner' alongside the agency 'scrum master'. To do it successfully means you not only have to adopt the agile processes but also an agile frame of mind. You need to be comfortable with a level of uncertainty which is inherent in the approach and that is often the crunch point. Clients usually want certainty about the 3 core elements of any project management scenario - namely time, cost and specification. With Agile you probably know you will get a series of defined 'sprints' over a given period, however what goes in them can vary, the resources to deliver them may vary and consequently the final cost, time and specification will vary. It can and does work and makes for an interesting and challenging journey not for the faint hearted but worth the effort.

  2. Hi Stewart
    Thanks for the commment. Love your 'need to be comfortable with a level of uncertainty'. I can see it would be a crunch point. There is a big leap though from using Agile methods in software production to using Agile methods for all PM, don't you think? And yes, it would be difficult for clients who want hard definitions before granting the contract, especially when they might not have been adept at defining things themselves!