Say what you do. Do what you say.

I love the sound of waterfall in the morning

From time to time, I’m asked to review proposals for IT research projects. This morning I was part of a team reviewing two projects. Before the meeting with the companies behind the proposals, the review team discussed the proposals. We all agreed that the project plans, clearly waterfall, were unsuited for a research project, with its large amount of uncertainty.

I joked “The proposals I’ve seen always contain a waterfall project plan. When questioned about that, the companies always reply ‘Well, that’s not how we were planning to run the project‘.” Usually, they say they will use an iterative and incremental approach. This time was no exception: waterfall plan, iterative and incremental execution. Well, why don’t you say so in the the proposal?

Why do these companies write proposals with one type of project plan, when they have no intention of ever following that plan? Why do they think that a waterfall type plan is expected, when they know full well that this is not an appropriate approach for their research project? Last time I used Microsoft Project, I must have missed the “create waterfall” wizard…

The basis of any audit methodology (whatever you may think of them) is: Say what you do. Do what you say. It isn’t more complicated than that.

The one that got away

There’s always an exception to the rule. In 5 years, only one proposal had a decent project plan. A plan which took into account the risks. They had short iterations and scheduled plenty of evaluation and re-assessment points in their plan. They used SCRUM and some parts of XP.

When I asked them why they chose SCRUM, their CEO replied. At first, he sounded a bit apologetic and started to explain why they had made this “strange” and “unconventional” choice. But soon, he started to tell how SCRUM had changed the way their company worked. They had experimented with many methodologies. This was the first one that people actually used. This was the first time the CEO really felt he knew what was happening in IT and he could steer it. “Today we have our projects under control, instead of the other way round.” I don’t often hear a CEO talk so enthusiastically about a development methodology.

At the end, he said “Well, you may think it’s a weird way to work. But it works.”.

Something that works. How very weird…