Comparisons

On many projects, regular status reports are how we communicate progress to stakeholders. On Agile projects, other tools and techniques are employed as "information radiators." Here is a comparison of both approaches, including tips and questions to ask as you incorporate one method or some combination of both that works best for your team and environment.

The weekly status meeting is the cornerstone of project tracking and reporting, and provides an opportunity for team members to bond. But when teams are geographically distributed, it is not always practical. And with real-time collaboration tools, is it really necessary? Let's compare the traditional weekly meeting with other methods of status communication.

When managing your project teams, are you more hands-on or hands-off? What are the key advantages and disadvantages of each approach? In what situations is one approach more appropriate than the other? Can you do both?

When planning your projects, do you use an objective or subjective approach? What are the key differences between each? When is one approach better than the other, and when can they be combined?

A formal reporting structure provides a framework to ensure that stakeholders are aware of progress, available for decision making and able to discuss issues. However, most stakeholders are spread thin across a number of conflicting priorities and regularly scheduled meetings may not be practical. In some cases, stakeholders can be kept informed through written communications and informal conversations. Here's a look at both approaches.

The Business Case Report anchors the entire project: gaining initial approval and funding; reinforcing business objectives around which planning and development efforts are built; and serving as a continuous benchmark for decisions throughout the life of the project. Agile projects typically require less start-up documentation than traditionally managed projects, but must work through many of the same issues.

Assumptions and Constraints are vital to understanding the state of a project — whether you are following a traditional or Agile approach. When and how you spend time capturing them is the primary differentiator.

An Agile project deals with risk differently than a traditional project where it is addressed from project initiation by creating a register of all the things that might happen, how critical they are, what their potential impact is, and what might be done (either proactively or when they become issues). An Agile project looks at risks as they arise and depends on team members to raise them as points of discussion when they become known and to determine the best course of action at that point.