Waterfall-style project management requires disciplined, deliberate planning and control methods. Managing an IT project in an orderly sequence, understanding the demands on people and resources in advance, and utilizing measurable, attainable requirements each step of the way is what traditional project managers have done for years.

The unfortunate reality is that the larger in scale the project, the less likely the project will follow the carefully developed sequential flow. Perhaps clients are not able to clearly define their objectives in advance or anticipate changes in needs, or, perhaps, specific steps in the process require more time or resources then have been originally planned. Additionally, a carefully thought-out step that inevitably takes longer than expected ushers in the unavoidable domino effect. One miscue at any phase, and the entire project timeline is negatively impacted.

Agile Project Management

By now, it is likely that you have heard of and may even currently be implementing the Agile Development (AD) process. Simply put, agile development helps minimize the risk inherent in software development projects: the risk of delays, changes in scope or requirements, and, ultimately, the failure to meet pre-determined objectives.

The objective of agile development is to compartmentalize the process. Rather than one, overriding and sometimes rigid structure, AD consists of multiple iterations— with each iteration being treated as a project in and of itself. Upon completion of an iteration, an agile development process requires stakeholders’ re-evaluation of project team priorities, prior to moving onto the next iteration. This change in philosophy requires changes in traditional project management— with some changes being fairly simple and other changes being far more challenging.

Impact on Project Managers

Agile development requires that all stakeholders— clients, IT professioanls, and other departments within an organization— play a role in the process. For the AD project manager (PM), implementing clear and open lines of communication with all stakeholders throughout each iteration is crucial to the successful outcome of a project. Effectively communicating with project team members is nothing new for the experienced PM. However, expanding those lines of communication across multiple departments and people is another matter.

Embracing the compartmentalization or iterative approach to agile development is another distinction from traditional project management processes. The concept of successfully completing one iteration before moving on to the next iteration increases the chances of finding flaws before the final rollout— certainly an upside to AD. However, focusing all the key players on each iteration, while staying flexible when inevitable changes or hiccups occur, will be difficult for the overly rigid PM.

Managing your team’s expectations through each iteration is another requisite attribute of the agile development project manager. Each successive iteration should build upon and be an improvement over the prior iteration. Recognizing, embracing, and effectively communicating this iterative buildout to stakeholders is necessary, although not necessarily easy. Traditional IT professionals tend to be more comfortable understanding the entire scope of the project in advance and having a clear mental picture of the end result. Successfully delivering a large scale project utilizing agile development requires stakeholders to focus on the iteration directly facing them rather than focusing on the ultimate result. This is quite a change in mindset and one that may cause consternation for those that thrive on structure.

Another requirement of the effective agile development PM is shifting focus from  lower value activities such as documentation to working features. Gone are the days of pages and pages of flow charts and written, detailed explanations of each step in the IT project. Replacing these formal structures are frequent and often informal discussions with stakeholders— along withconcise visuals. Sticky notes and cards on the wall have replaced reams of flow charts. AD does not, however, mean an absence of documentation. AD merely places emphasis on working software over architectural diagrams.

Conclusion

The shift in culture, the demands of stakeholders, and a more open development environment certainly need to be recognized and addressed when implementing AD. As important as any paradigm shift for the project manager is the proclivity to recognize and embrace the change in his or her role. Rather than the traditional command and control approach to managing a project, agile development certainly requires leadership , but, notably and additionally, calls for leadership and collaboration. For the experienced IT leader, this shift may prove to be challenging. However, you are likely to find such a challenge well worth facing.