Aug 21, 2009
Print this post
Waterfall Beats Agile for Visibility on Projects
Different project management techniques impact the type of information you can collect on projects and therefore the level of visibility you have on your processes - both for single projects as well as for reports across all projects.
One of the advantages of a more classic, Waterfall approach, is that time is a variable that can shift and be measured. With this approach you:
- create a task list or work breakdown structure,
- assign resources,
- assign estimated hours,
- enter start dates and due dates for each task.
Then, you can measure how long it takes to actually complete the tasks in several dimensions.
- First, in terms of calendar dates: when the task was started and when it was completed.
- Secondly, you can measure in terms of duration: the number of days it took to complete.
- Thirdly, in terms of actual hours: the amount of people hours worth of effort it took to complete the task.
When measured and kept over time it creates a robust data set that can be used to improve estimates on projects.
If you bill by the hour or by project, this data can help improve your pricing and profitability by providing visibility into the actual time it takes to do the tasks or projects you are charging for.
If you bid on projects, this same data will improve your understanding of the variables you can look at when pricing your bid.
In a more Agile project management approach, time is generally held constant and it is the functionality or amount of work that shifts. The amount of work that can be accomplish shifts according to the time allocated, the skill set of the team and the complexity of the work involved.
This can provide a benefit for the project manager -they don’t have to worry about schedules and effort estimates in the same way as a Waterfall approach. It also makes it easier to track progress and shut out distractions for the team.
However, it comes at a price of reduced visibility and decreased data for management to use to make strategic decisions. The variables often left to management for decision making then become ones of:
- hiring more people,
- working on the team’s skill set,
- firing people or
- limiting project scope to the constraints of the team’s historic performance over a fixed period of time.
It limits the information that can be generated from projects and therefore the data that can be used for strategic decision making, portfolio management or long term planning.
[...] Waterfall Beats Agile for Visibility on Projects | Vertabase Blog http://www.vertabase.com/blog/waterfall-beats-agile-for-visibility-on-projects – view page – cached Different project management techniques impact the type of information you can collect on projects and therefore the level of visibility you have on your — From the page [...]
I think you’re referring to strategic visibility across projects as opposed to visibility within a project?
Within a project, the type of information generated by the typical waterfall project is in my experience either irrelevant or not worth believing. The typical phenomenon I see is every status report is green until the very end of the project, at which point you have no time to do anything to recover.
Managing to and developing internal capability based on believable data seems to be a good strategy. I’m not sure how WBS, assigning resources, and burning estimated hours is not a blatant case of wishful thinking in terms of assuming knowledge you don’t have, ignoring actual resource capacity, and measuring progress on effort rather than outcomes.
If the status reports are inaccurate that is a case of bad data. The project manager doesn’t have accurate information or isn’t interested in publishing updated information.
There is no methodology that can cure wishful thinking.
I generally see this type of problem when the project manager is set-up as the gate-keeper of information. All project information has to pass through them and they have to spend time gathering this information. They then generate reports to their managers. In these circumstances wishful thinking is often incentivized and there is a lot of room for politics to get in the way of accurate data and good project management -particularly on large scale, long-term projects.
While methodology can’t cure wishful thinking, understanding the project manager’s role can. A project manager should be a facilitator, bridging the smooth flow of information from the stakeholders who want the project and the teams charged with making it a reality. In this framework, information is simply a reflection of reality which the pm and stakeholders can use to make decisions with -regardless of whether it is green or red. It is data.
Hi Mark,
The point I’m trying to make is that the problems come form an underlying systematic cause which can only be solved by re-designing the overall system. Re-thinking roles is only one part of that.
The reason for Agile is the belief that “waterfall” approaches are systematically likely to cause particular types of failure.
Hi Jason,
That’s where I disagree. I don’t think there is anything inherently wrong with Waterfall or anything inherently better about Agile. There is a time and place for both -or for a blended approach, picking the techniques that work best for each pm, circumstance and team.
So often the problem is in the practitioner rather than the practice.
The goals of the project, not just the deliverables, should dictate the approach used for the project. This includes recognizing the effort involved in completing the project as a valuable use of an organization’s assets. The “output” of that effort should be maximized by getting as much data from the process as possible. Of course, without impeding the efficient completion of the deliverables.
This article makes several assumptions which are incorrect. The first is that Agile produces reduced visibility. Agile does quite the opposite; it encourages more visibility than a traditional project. One aspect of this visibility can be explained with the following example;
Given that the iterations of work are two weeks long
And the team has completed 1 iteration,
When the project manager wants an updated estimate at completion
And the team estimates sizes the uncompleted requirements based upon the work completed
Then the project manager will have the new estimate with minimal time involved by the team and minimal effort of the project manager.
Agile does not reduce data provided by traditional projects. One can still complete a WBS (which is really the product backlog in Agile). One could task items and collect additional data points if desired. One does not see those activities occurring in Agile as much as in Traditional projects because the structure of Agile projects enables people to see that those additional items do not actually help the project move faster or produce better decisions. Traditional approaches tasks everything out in the beginning of the project and enter start and end dates. The PMBOK recommends the concept of “progressive elaboration” which entails detailing only what is known, but refraining from detailing anything unknown because those tasks and dates are likely to change. Thus, Agile actually follows the good practices of PMBOK better than the way most Traditional project managers do. In conclusion, Agile does not have the disadvantages discussed in the comments earlier; instead, Agile shows teams that have a choice of doing only what is necessary that many of the “Traditional” data generation is unnecessary and not helpful.
Brian,You make a good point regarding the time it takes to get information and the accuracy of the information. However, one of the tenants of Agile is a reduction in documentation. A Waterfall or a blended-approach, tends to create more project artifacts and metrics. These provide increased visibility for management. While the number of artifacts may not directly impact the value produced for the customer (in fact -sometimes it is an inverse relationship: the more artifacts the less value created), they do provide management with a greater degree of information and visibility into the aspects of the process/team that are important to management. Not all corporate cultures are directly and purely aligned with customer value. There are other stakeholders involved. Project artifacts and additional metrics help give those stakeholders the information they need.