What is the best development methodology? Waterfall? Agile? An iterative model? Something else? Companies and projects are looking to find the best approach to deliver on time and on budget and still keeping the scope. People are arguing in personal discussions and forums highlighting pros and cons about their best one, but I did not see the ultimate answer. Now I can help you to have it!

First of all we have to highlight something. If your people or you organisation is not motivated to deliver, there is no any methodology which will do it instead of them! You have to identify if missing delivery capability before starting to start a revolution with high expectations in a new approach or a new methodology.

I show you three projects using three different methodologies. Two of them were not successful and 1 was. At the end, we will look for the difference between them and trying to find the real success factor.

Caterpillar project

Caterpillar project was introduced to replace customer care and billing solution in a large enterprise. From the first day on, it was defined to execute by waterfall methodology, since the management wanted to keep track of the budget by having full detailed documentation. Before starting the company did not have proper culture to manage well-detailed requirements either in this large complex case.

To keep the original stack everyone was focusing on the waterfall phases, it was the backbone of the communications. They mapped the business processes by eTOM layer by layer. Reaching the deepest level they turned to detailed designing of the solution. It was the first stage when they recognised that the time and the budget were stared to be overspent, therefore some scope-cutting was needed. To avoid loosing of requirements particularly the de-scoped elements, the project introduced a Sharepoint based document management and detailed activity reporting. Thousands of specification pages, hundreds of Sharepoint sites and folders born together with dozens of different reporting and the project was slowly altered to an large sub-organisation, which had budget, culture, some kind of a scope but no deadlines.

Finally the budget and the time were minimum 3 times overspent to about 30% of the original scope. I would not say it was a success although the project still delivered important values to the company.

Octopus project

Same sized company as in case of Caterpillar project, where the organisation is disappointed in Waterfall methodology. They wanted to enhance their web presence by introducing new tools allowing extreme fast changes to follow the online market needs.

The logical decision was to select agile methodology, since they expected that the requirements needs to be tuned in the course of the project because of the  nature of the online world. Since they had no experiences about Agile, they built the environment to make it successful: open space, daily stand-up with entire wall whiteboards, use case management software, dedicated wiki-like applications and so. Dedicated groups were focusing to operate the agile processes and to support the team in their execution.

As the time gone once they recognised large amount of critical issues, like most of the guidelines of base product were broken, many functionality were missing, time and money is over.

Finally they overspent their original budget about 2 times, the timeline was minimum the double as planned. It is neither a real success but the important new functions and capabilities delivered are approved.

Bear project

A large company decided to introduce a discount sub-brand on a saturated market. As it products had to be really cheap, the project had to find solutions, which has low cost. The project was totally separated from the mother organisation and the tam behaved as "pirates" as Apple defined decades before. All the tools they decided to use was cheap: opensource, manual, replaceable; anything what was useful and helpful and that's all. No one really cared about the tools themselves, the only importance was the value they gave.

If you try to ask the team about the methodology they used, the answer will be Agile. But they fail. In the everyday business it seemed to be Agile methodology, although it was a special mix of Agile, Waterfall and V-model. Project management executed the project and the team saw what was necessary.

The project reached it target, keeping the deadline and spent about 70% of the original budget. I believe this is a real success!

Summary

Although the certain implication would be that the methodology drove the last project to the success but I believe it is a false statement. It cannot be the real success factor, since most of the team member didn't really know what they are working by. The key factor was that Bear project was focusing on delivering the target instead of focusing how they are doing that! I would not say that the question "how" is not important since it is, but it is only a factor of the work, but not its target!

A woman’s honour is like a good tailoring: it must not strike the eye, not even to earn praise.

(Jenő Rejtő)

I believe the good methodology is like this!