Is Agile Project Management Right for Your Technology Project?
Posted Tuesday, March 29th, 2011 at 1:36 pm by Amanda (4 posts)
It seems that these days, a lot of technology companies are proudly advertising the fact that they rely on agile project management and there are even some who boast the creation of a specialized version of agile. In general, doing agile projects seems to be the all the rage for a lot of folks in the IT field. This kind of hype can make it seem like agile project management is the best, most cutting edge methodology to use for technology projects, but before jumping in there are many factors to consider. The benefits of agile projects are relative depending on what they are being used for and who is working on the project. Just because a development team can handle rapid delivery schedules and adapt quickly to project changes, doesn’t mean a client has the capacity to keep that pace or the desire to have so much project uncertainty when it comes to timeline or budget.
Redirecting your company approach to be fully agile may not be the best solution either. Allocating resources appropriately is likely to be one complication to arise. There can be a bit of an “all in” or “all out” problem with resources; can/should you have some dedicated agile project teams or does the entire company work with agile projects? In our case here at Beaconfire, using a strictly agile approach would be problematic in terms of optimizing resources without having some people overworked while others are underworked. Additionally, if certain project teams are created for agile projects, large chunks of a resource’s time might be demanded by the agile schedules leaving them with little to no time to take on other non-agile project work. This could tie up a resource in high demand that may be valuable to other teams working with a more phased approach.
Another factor to consider is the client base. Clients and project teams work best when there is a mutually comfortable project management methodology. Many non-profit organizations seem to be more comfortable working with a waterfall, phased or overlapping phase approach and it may be difficult for them to adapt their internal schedules to the more demanding pace of an agile project. Agile projects tend to require fast turnarounds on approvals in a highly iterative process and that just may not be a good fit for many organizations, especially those that require committee or task force approval throughout most stages of a project. In these situations it may be more effective to schedule approvals and continue requirements discussions in a more phased approach rather than asking client teams to juggle significantly more phases at once with iterations needing continuous and frequent approval. There are certainly exceptions where organizations can easily adapt to agile projects, but it is somewhat unpredictable and the uncertainly can make project planning a bit challenging in early stages.
It has been my experience that a mixed methodology tends to be easily applicable and adaptable to different client circumstances. Using a phased approach in initial project planning can help set realistic expectations for a project timeline and budget, but there is typically room for some flexibility for situations where the client may prefer more iterations and rapid communication. Starting with a phased approach and adopting some pieces of agile project management methods can help a timeline speed up, but also keep project requirements from spiraling out of scope. Certain projects or clients may easily conform to a more agile-like schedule where decisions can be made rapidly and development teams can pull together to sprint quickly on iterations. However, the resources in this situation must have the capacity to keep constant tabs on the potentially fluctuating requirements while still maintaining other projects that are on a stricter timeline. Small, limited timeline projects with smaller teams are well suited to this as the timelines are unlikely to be drawn out too far and cause conflicts.
One of the main factors in deciding whether a phased project approach could benefit from some agile methods is how much time a client may need for decisions and how large the client team is. It may be a challenge for larger client teams to review and approve every iteration of a project deliverable. For larger teams, it makes sense to schedule the project with longer phases where the team could review a larger chunk of the work and spend the necessary time reviewing it as a group. On the other hand, a project team might consist of only a few people and decisions can be made relatively quickly. In these cases, it can be beneficial to use more of an agile approach to the deliverables where frequent iterations of the work can be reviewed by the client to ensure requirements are being met effectively.
At Beaconfire, we tend to use a more structured, phased approach, while maintaining the flexibility to approach projects in a way that suits each client individually.
