Showing posts with label agile processes. Show all posts
Showing posts with label agile processes. Show all posts

Sunday, 20 February 2011

Project Life Cycles and Project Management

This used to be a simple question - not providing simple answers though - of understanding the planning, the design, the build and the implementation phases of a project. These underpinned a company's approach to developing projects. They were based heavily on IT inspired phases of software development as this was the closest to interactive media development.

So for the early years, the Waterfall approach dominated and for many this approach still does. If you need reminding about the Waterfall life cycle take a look at SoftDevTeam's site and their Life Cycle Selector software tool description. We don't know anything about the tool itself, by the way, but the diagrams and summary advantages and disadvantages descriptions of the spiral, waterfall, incremental, evolutionary prototyping, rapid application development, and V-shaped models of software life cycles , are illuminating. Some are new for us but then we've not been in pure software development.

Check out more definitions of models at Business E-solutions.

The planned and designed inherent Waterfall approach is iterated by Alex Baker recently in Life Cycle Stages of Website Design Process, but it is dependent on the client stating the business goal and requirements – something that proves pretty hard most of the time.
Another take on a life cycle comes from Jason Montague, An Agile Project Lifecycle, and he has a visual denoting the process. He also explains difficulties he's met in organisations when trying to explain the usefulness of using Agile processes. Remember that Agile tried to address the 'refining' of requirements that often occurs during interactive projects. The strict Waterfall software approach did not allow such changes and caused conflict between client and developer, so Agile techniques may help overcome some of the difficulties.

There are masses of Waterfall versus Agile debates still going on in cyberspace if you care to Google it, but few solid answers about the life cycle of an interactive project whether website, mobile, iTV or whatever. Shame, I'll keep looking periodically though and let you know if I find any answers. Meanwhile, how is anyone managing any project!

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!