My participation was on a project while working for HP we used the agile method which is tradiditional waterfall project mangement methodology,as is scrum and RUP what made it successful was that along with using this approach. There was a PMP software mercury which the WBS resided the activities and estimated timelines were indicated as well the resources accountable were mentionned. Projects as you know are about people and each day a review of the past days activities with a look ahead took place early in the morning what also made the project succesful was that we employed a virtual team accross global time zones so that work was taking place continouosly on a 24/7 process.Some were contractor resources some were company you required good support from a PMO and executive representation to ensure that if any obstacles which were of a resource nature occurred senior management could be leveraged to remove that bottleneck. At tghe end of the day accurate Business Process Models were made ,quality training and pereseverence to meet the due dates. Also a central web page where all data repositories of documents and names of key resources were indicated.
I hope this helps.

posted July 19, 2009

Hi Andre

Yes, even came in under cost. Key success factors:
- well defined scope up-front including constraints & assumptions, thanks to detailed discovery.
- regular review of scope and sign-off post analysis & design stages with regular 'authority group' review throughout to manage scope creep.
- excellent project management and carefully chosen staff for lead roles of various work streams.
- committed buy-in and dedicated involvement by senior business reps, totally dedicated to project.
- regular and transparent communication, preparedness to have the tough discussions.

Hope you find this helpful.

Craig

posted July 20, 2009

I believe projects which have a well defined scope which is well understood by the customer and project team and also unlikely to change over the course of project is likely to succeed in a waterfall model. However there is no reason why an agile process will not succeed equally well in this situation. Whereas when scope is likely to evolve , waterfall will most likely fail. My recommendation then is to do agile always

posted July 20, 2009

I was about to say Yes before I saw your criteria; most of the "Successful" waterfally projects were called successful because there was too much invested in their success for them to be called "Failure".

There are still a few "Successful" waterfall projects that I have come across or been involved in. Typical common characteristics - they are enhancements to existing legacy systems, the dev team and the client team had been working with each other for years. I have to say, though, that with an outsider's eye, I would not agree with their assessment that these were high quality or easily maintained.

posted July 20, 2009

Surprising as it might sound, the comprehensive criteria that you have enunciated in your question can all be suitably tainted to paint a pretty good picture of any project.

It all depends on training users' expectation.Even a bad product can be made to appear wildly successful with the correct PR slant and vice-versa. So by that definition many waterfall or agile projects/products may be considered "wildly successful" because the user does not know any better. He gets what he gets and learns to live with it. After all we have lived to cope up with defective operating systems, databases, application servers and erratic web sites.

Even code quality, surprising at it sounds, is relative. I have seen people claim that the code is extremely maintainable only to see that most of the code is duplicated or restricted to giant methods which get cluttered up with all kinds of stuff. So "well designed" by what criteria is the question.

Agile methods help in many of these things. But they don't ensure user satisfaction just increase the probability of it due to their short iterations. They don't ensure code quality. They merely increase the probability of it if you adhere to their best practices of continuous integration and testing along with constant refactoring. A continuously refactored code with a 100% unit test coverage may still not satisfy the user's expectations. It all depends on the yardsticks used to measure code quality and user satisfaction.

Going by your success criteria alone, projects - that may be deemed to be failures - can look pretty good if the criteria are properly tinted to paint a glossy picture. A few thousand advertising dollars can effectively mask any kind of stupidity.

So to answer your question, have I been involved with projects that were considered successful with waterfall methods? Yes, but successful by what standards is the eternal question...

posted July 20, 2009

I always become a little bit ancious when someone wants to discuss which project methodology always causes successful projects and which ones doesn't. Though I do believe that good project methodologies can help planning, reduce risks etc. in a project there are certainly other factors that greatly affect the outcome of the project. So it does concern me that you in your 5 years never have found someone who could convince you they have had a successful project without using your favorite methodology, and I think - as Raja mentioned - that it might be due to the fact that even your stated success criteria can be graded, and maybe they are biased to your world a bit.
For example in some projects the scope is not the least important of the three adjustable factors (scope, cost and time). If you create mission critical software or maybe software for health care it may not be the best option to let the scope slip, maybe the cost should be allowed to slip, etc.
But as you mention it, the main thing is that you have aggreed up front which of the three factors are allowed to slip, and which aren't.

Anyway my contribution to this survey would be that even though I too am a strong believer in the agile approach, I have seen some successful waterfall-like projects in my time, but I don't think I have ever seen a "true" waterfall project, meaning one, where there were no changes incorporated at all underway.

posted July 20, 2009

Yes, I both led and participated in successful “waterfall” projects. Why they were successful? Features to deliver were realistic and fixed, scoping was done correctly, those involved were excellent professionals and properly motivated, while management kept track of progress and protected the team from external “jolts”, such as 11th hour scope changes. If you think this is old school, think again - I know some of the managers who did that went to work for Google and their careers there were very successful.

I’ve seen at least one large XP project that failed. Why? Initial scoping was off-base but features were non-negotiable, which resulted in the cost and time overruns.

I personally consider incorrect scoping the #1 reason why so many software projects don’t succeed. One of the reasons that agile methodologies are considered so successful is because, as you said, “It's okay for scope to slip as long as the customer is happy.” They also reinforce healthy practices such as friendly competition, open communication, and tight collaboration within the team.

So, basically, the agile methodologies are better because they are not strictly software development methodologies but also motivational, marketing, and sales ones. The feedback loop is wider and thus leaves more room for maneuver. Whatever can’t be reached through regular development effort can be compensated by working harder (Scrum “sprints” are called that for a reason), by adjusting what needs to be done (marketing), and by adjusting the customer’s perception of product (sales).

posted July 20, 2009

The answer is "yes". Many times. You might want to note that you are probably referring mostly to Software to IS based projects. There are decades, if not centuries, of experience in other disciplines that may not share IS's concerns and issues.

I will emphasize that "waterfall" is an observational description of a schedule and not a methodology. As in scrum, the key is having the right people involved and the proper level of empowerment, skills, and commitment from the organization and the people to execute.

I would caution from categorizing. The key success critieria that all us Project Mangers are responsible for is getting things done. Methodologies, Processes, Tools, and Techniques are just tools in our belt. Use the right one to ensure that the customer gets what they needs within Cost, Schedule, and Quality.

I would also like to concur with most of the threads and reponses. The key is managing, controlling, and communicating expectations and deliveries. This does not matter which technique that you use. Certain projects, such and white wheet development, are more receptive to a focused fast tracked team approach like scrum while product enhancements or product introductions are more receptive to predecessor - sucessor based approaches.

Bottom line - no silver bullet. No magic 8-ball. Know all tools and techniques and apply them appropriately. ... and it helps if the organization knows what you're talking about.

posted July 21, 2009

Yes, I have had success based on your criteria. The main reasons were:
- Well-defined scope
- Solid project plan (adjusting as necessary)
- Proper accounting of risks, constraints and assumptions
- Including milestones (with sign-offs)
- Constant communication

Of course, having a good team and buy-in from key stakeholders helps.

posted July 22, 2009

Here's what's funny about your question, and the so called Agile methodology. Your still doing Requirements, Analysis, Design, Implementation and Test.
The difference is how many times you do them. Waterfall you do them once. Agile you do them over and over again, and sometimes you never document it. RUP, you heavily document everything you can (well, that's the impression most have).
You could also call it the scientific method, You develop your hypothesis (Requirements), You make predictions about the hypothesis (analyze). You design experiments (Design), you conduct those experiments, and then you evaluate the results.
You could also call it an OODA loop. You Observe (requiremetns), Orient (analyze), Decide (Design) and Act (implementation). Then you feed the results of the action back into the loop.
Or, to put it another way, it's basic problem solving.
So, in my mind, the methodology doesn't matter. Skill, talent in problem solving is the key to the success of any software development project. The methodology is just how you're going to organize your activity.

Links:

• http://en.wikipedia.org/wiki/Waterfall_model
• http://en.wikipedia.org/wiki/Scientific_method
• http://en.wikipedia.org/wiki/OODA_Loop

posted July 24, 2009

I would like to thank Walter Woodford and Jim Barrows for writing the answer for me: great comments and absolutely on target.

Methodology does not matter. Problem definition, solution approach, managing, controlling, adjusting, and communicating during execution do matter.

I have seen plenty of projects fail (and rescued quite a few) because the basics were not followed. One of the most memorable project rescues involved a team that elected to favor a specific methodology over a clear problem definition.

Believe it or not, one of the comments I heard was "We could not possibly fail. We were A***e. A***e teams don't fail".

posted July 25, 2009

Like the other project management methodologies, waterfall project must have a very good planing, thigh control and every stakeholder must be envolved and give their agree to waht was defined with in the scope
Short duration projects (up to 3 months) are always easy to manage because the client doesn't wait too much to get the final product. Above that you must be careful and careful to manage the expectations within the client sponsor and the members of client's project team.

I had some successfully waterfall projects. Answer your questions:
1 - Yes at the customer was happy with the deliverables
2 - The product delivered had the expected quality and one occasion even better quality.
3 - I usually submit the projects to maturation stages where they pass through many tests of all kind. If needed i opt to take more time but i can't accept known technical debts.
4 - Maintenance it's always considered in the proposal, so it's hard to say if the client would considered the procedures easy or not. The client usually have a good usability.
5 - If consider the initial scope and excluding the procedures that are from client's responsibility, usually i don't have date slips. Some times what happen in bigger (>3month) duration projects is that the client may find new features that want to include on a scope revison and agree with new and extended deadlines.

Cheers,
Paulo

posted July 25, 2009

Yes, there were many successful projects at Mutual of Omaha using that criteria. They used "waterfall" within the context of your question. There were also numerous failures using that approach.

In my experience, Waterfall or Agile, the more important elements of success were the following:
Clear scope and success criteria
Active, engaged sponsor
The right staff - not just skills, but attitude and team focus (probably even more important for Agile projects)
Active change management
Emphasis on communications to all - team, stakeholders, etc.

If a project is set up properly at the start, it doesn't prevent problems but they can all be overcome. If a project is not set up properly at the start, almost nothing can correct those problems later. My biggest regrets on failed projects is starting them at all - almost all had flaws at the beginning that we felt we would be able to fix after we started.

posted July 25, 2009

I second what Eric says, but add one more very important point - good, thorough testing and QA.

Which methodology is used is not as important as good planning, staffing and testing.

posted July 25, 2009

Andre,

You must be working with a small set of students.

I have been on several 'waterfall' projects and they have been successful.

One comes to mind in that there were set specifications and a set delivery date. We were able to complete the project on time, on budget. The customer was very happy in that because of a lack of hard specifications on the operational speed, a design element that was left to the developer, we exceeded their performance requirements by a couple of orders of magnitude. The net result was that the base platform could be utilized by other projects, further reducing their costs. (All within cost and time constraints.)

In addition, they were easily able to modify and enhance portions of the system over time and with ease.

I guess you were trying to sandbag this question, but there are a lot of fixed bid, fixed specification projects that developers can say 'Yes'.

The only catch is that in a lot of other cases, the customer thought that they knew what they wanted, and that they then had to modify the specifications mid stream, or upon delivery and UAT, the end user wasn't happy with what was delivered, not because the project failed, but that the end user did not give enough information during the requirements gathering phase. You blame the developers, but its not their fault.

It usually takes a highly skilled professional to deliver a 'YES' here and *we* do exist. ;-)

HTH

-Mike

posted July 25, 2009

The "waterfall" model has been found to work better for product which are more in the stable state or more into the sustenaince mode. The number of unknowns are far low in number and the scope is fairly well defined. Take for example the legacy AS400/RPG systems. There are other variants of the Waterfall which talks of 'incremental development' which are more manageable and give you an option of refining the overall system with learning from the previous iteration.

The last few years my experience with Scrum has been great and definately a recommended for all product development activities , specially for R&D type of work.The key success factors are Flexiblity to change, Collaboration , Working Software over a process heavy model.

Links:

• http://phillips.rmc.ca/courses/493-1998/lectures/waterfall/waterfall.html

posted July 25, 2009

Absolutely.

Have also been on successful Agile projects.

The key is the right project manager rather than the methodology. Project management has to be about facilitating information rather than trying to impose control -regardless of the approach used.

Links:

• http://www.vertabase.com/blog

posted July 26, 2009

I am no expert in project management but I have been a part of project teams which used "waterfall" and "scrum" methodologies. And both types of projects were successful. I would say "successful" because my answer to all of your questions is "Yes".

There could be many reasons for success. Parameters like project-size, team-size, requirements, planning, tracking, risk management, customer communication and proper contract management. There could be many other parameters which have an impact on schedule, cost and quality but the parameters I just mentioned are the ones which we took care of.

"waterfall" is good if you start with clear requirements. For example:- porting a product to a different platform, re-writing a legacy product using new technology, automating an established and well practiced human process.

"scrum" is good if you virtually have no requirements at all. i.e. while the requirements are being gathered. The team can research on and prototype using technologies to be used for similar products. We can start recording these activities, research, prototyping etc., in the backlogs. If someone is new to the process then he is also get used to it by the time we have some real requirements.

The essence of both the processes is proper review and tracking. In "scrum" it is done in the shape of daily stand-up meet. Although some may argue that this is not tracking. In "waterfall" if we do similar, i.e. timely, review & tracking you will be successful provided the "clear requirements" clause is true.

Important learning here is that "scrum" can be used for all types of projects. Whereas it will be risky to use "waterfall" in unclear requirements. In both the cases Risk Management should be part of team culture. Fix them before they materialize.

posted July 26, 2009

I have seen several projects succeed with waterfall as I've seen many fail, either in regards to deadline, budget or both. The differentiator was always the Project Manager's competence. This makes sense because it's a methodology that concentrates all the responsibilities on the PM.

The bottom line is that methodologies are just tools. They help but ultimately it's the people that have to make projects work. However, nowadays it is obvious that waterfall is not the best tool, at least for any medium to large size project.

PS: I don't understand Alexander Hankewicz's answer. Waterfall is the antagony of any agile methodology. How can he say they "used the agile method which is tradiditional waterfall project mangement methodology"? Just doesn't make sense, sorry.

posted July 27, 2009

Hi Andre
Multiple success criteria have to be defined for various stakeholders

All the points that you mentioned hold correct success criteria if you evaluate a project manager

For a product itself ROI could be one success criteria.
Irrespective of development methodology following are some standard success criteria

1. Successful and complete identification of stakeholders and formal closure of requirements as early as possible. Scope must be freezed.

Though mostly people think that it is OK to slip scope as long as client is happy but scope slippage can have very negative impact on schedule , quality and cost. And of course client would not bother if it is negatively impacting you only.
2. TCQ(Time, Cost and Quality)
3. Resource management. It is most most important and mostly overlooked aspect. You may deliver a high quality low cost product within timelines. But in order to achieve that you may put extra pressure on your team and you end up seeing very high attrition. In the end, probably you wouldn't have right skills to take next project :) . I believe it is one of the success criteria as what impression a project itself leaves on the team, after its completion and during its progress.

There can be project specific success criteria as well. How I manage them is as follows:-

1. Scope boundaries identification as early as posible and formal signoff from all stakeholder holders
2. Definition of success benchmarks in terms of technology, quality, scalability, maintainbility, client expectations
3. Thorough periodic review of current development status with the benchmarks set.

posted July 27, 2009