How the latest ‘agile' project management methodologies may help to bring IT projects in on time and budget
27th August 2007 The challenges of developing and implementing software based projects has been a big driver of project management thinking more broadly. The main problems in software projects come from difficulties in estimating the amount of work required to write, debug and then integrate different sections of code or the compromise between carrying out meaningful testing and repair of code while trying to maintain a brisk schedule of software releases.
A number of methods have been developed to try to improve the results obtained from these projects with varying success. PRINCE2®, for example, is the second iteration of an attempt to manage large IT projects more effectively. Ironically, it is probably more popular in non-software projects than the purpose for which it was intended.
Methods such as PRINCE2® are not ideally suited to software development as these ‘predictive' approaches try to understand and define the future in detail. That is relatively simple in a construction project where the underlying methodology is known and accurate benchmarks exist for say, the duration of major tasks and the resources required. This focus on defining the future in detail is less well suited to software as the tasks are not understood in the same way and change fluidly during the course of the project.
To counter the weakness in ‘predictive' approaches, agile development methodologies aim to adapt work quickly to rapidly changing situations. They assume things will change so fast that planning in detail is a waste of effort and replace this with excellent communication and flexibility.
An agile team may only have detailed the work for the upcoming week. Work in the following month may be defined as new features and bug fixes to be incorporated. This is clearly a much lower level of detail of task and resource planning than would be seen in a ‘traditional' planning approach.
This new approach to development is often credited to the creation of the Agile Manifesto. This was written in 2001 and describes principles that are at the heart of most agile methodologies – valuing the items on the left in this list over those on the right.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Using an agile approach means that software iterations are delivered more frequently than in traditional development projects. Instead of months, there could be a new release daily. This creates issues with the ability to test the software and the desirability of such an approach will depend on whether you are updating live software used by clients or purely internal development releases.
The lack of formality of documentation in the project means communication becomes even more important and the ability to have frequent, discussions with the involvement of customers is vital.
Agile methods can work well in software development particularly when programmers are experienced and used to working in an agile way. The team should be small and preferably in the same location. Ideally you don't want a floor or a wall between parts of the team. The more difficult it becomes to hold discussions within the team, the more problematic the project will become. The method is well suited to an environment in which there is constant access to the ‘customer' and requirements change rapidly.
However, agile methods are less suited to situations where the team is large (>20) or does not sit together, or the organisational culture cannot support the devolvement of responsibility to individual programmers. Neither does the approach work as well when program management techniques concentrate on long term budgetary and resource based planning. Other factors that may render an agile approach less suitable are if programmers are relatively inexperienced or uncomfortable with the approach and requirements are stable.
The other major theme developing in project management is that of collaboration. This is driven, in part, by the move to outsourcing that means project managers need to control and coordinate teams outside the boundaries of their own company. At the same time, formerly ‘big ticket' software has moved from the mainframe, to the server and finally onto the desktop – becoming a low cost or even no cost item. This means there are new tools and web based software allows teams anywhere in the world to share information, manage permissions to change documents, update status and change estimates.
These collaboration tools may makes things easier than they were, but the fundamental task remains the same. They are like Microsoft Word. This package has changed over the years, but it is still fundamentally doing the same job, even though it is much bigger and flashier than it was. The key to collaboration remains doing the fundamentals right. New software or a methodology such as PRINCE2 may prevent you making errors but it won't actually make you run things well. That remains the skill of the project manager.
Richard Jones is the author of Project Management Survival , published by Kogan Page, hardback, 254 pages, £25, www.kogan-page.co.uk
