Project methodologies are like sample code.

Joseph Cooney and I were talking over lunch today; being the geeks that we are (OK - I’m a geek, I’ll let Joseph plead guilty himself) the subjects discussed were quite varied, for example, the reason I chuckle when ever I tell anyone that I used to use WSAD (WebSphere Application Developer).

The reason is that internally I pronounce it “Wery SAD”. For some reason I visualise Mr. Chekov saying it. Anyway, thats not what I wanted to blog about. One of the subjects that we discussed was project management methodologies.

We both agreed that it is easy to get jaded about the whole project methodology discussion when I came out with the comment that “project methodologies are like sample code”.

Joseph commented that I seem to be always ready with some kind of pithy analogy. Honestly I think that when medical students pick apart my brain they’ll find that the neurons have aligned themselves into a pattern that looks suspiciously like a Dilbert comic strip - that and fork() is the most commonly called function in my brain - back onto the subject of project methodologies.

Project methodologies are like sample code because like sample code they outlines practices that look fantastic in the limited scenarios presented but once you try and use it in the wild you are suddenly confronted with complicating factors which make that practice unworkable.

Requirements analysis is like painting the Sydney Harbour Bridge.

This analogy emerged out of a lunch-time discussion too. The analogy goes like this “requirements analysis is like painting the Sydney Harbour Bridge“. Sounds cute, but what does it really mean?

Well, painting the Sydney Harbour Bridge takes a long time, in fact no sooner have they finished they need to go back to the beginning and start all over again - I’m sure other bridges have similar problems or worse.

The point is that when you have a scope that is so large it is effectively impossible to survey all the requirements and expect them to be stable for the duration of the analysis phase. The larger the scope, the harder it gets.

I guess this is why I am skeptical about project methodologies that advocate nailing everything down to the nth degree before getting started on getting some value back to the customer. Methodologies that seem to work are the ones accept this volatility and set some broad visions but try to constrain detailed requirements analysis until just before implementation.

The vision needs to be defined just enough to get some unity across the deliverables but still allow some wriggle room.

Just-In-Time-Requirements-Analysis (JITRA) means that end dates need to be a bit rubbery which some people have trouble accepting, but my argument goes something along the lines of “the project team is going to work as hard as possible, but no harder, which means that the project will be delivered as soon as possible, but no sooner”.

Lunch-time Discussions

My flurry of blog activity today emerging out of a lunch-time discussion has got me thinking about what an important thing sharing a meal with fellow developers is when it comes to professional development.

I think others agree too given the rise in the number of Geek Dinners, particularly in Israel, Portland and Seattle.

Project plans and other works of fiction.

Recently I’ve been involved in wrestling some project plans into submissions for a project that is currently in flight. When I came on I established a simple iterative development plan to reach a particular delivery milestone in the project to get things moving while a more holistic plan was being developed on a background thread.

In contributing to the holistic plan I’ve started to think of project plans as works of fiction. Its not that I think the dates in the deliverables in this new plan are fictious, but I feel that sometimes project plans focus too much on the “what”, and not enough on the “how”.

This could be considered one of the big differences between the “big plan up front” and “iterative development” approaches. Both plans contain a list of “what” is to be developed, but in iterative development the resolution is much lower until your reach the point at which you need to start development (beginning of the iteration).

Tools like Microsoft Project certainly seem to favor “big plan up front” project management, but I am determined to figure out how I can bend the software to my will