I always had my personal approach to methodologies. What I think is useful, I take; what I think is useless or harmful, I leave.
That should be true every time you want to get something done, every time getting to the result is the main thing. However, more often than not, the conforming to the methodology appears to come first.
The methodology debate in IT has been an hot debate and Agile appears to be winning. I have nothing against Agile or any other methodology, I have a lot against abusing the ideas underlying them.
Every methodology has its take about how the project is approached, how phases should be identified, who are the stakeholders, who needs to be informed, which are the documents and their format etc. etc. etc. Each of them is useful and gives suggestions about how a project should be managed. The basic idea, however, is that you are able to break down the process into elementary building blocks, everything will be easier. What's the saying, plan you action and then action your plan. Do small, manageable, chunk of works and, if you do enough of them successfully, eventually the project will be successful too.
How to identify them, is open to debate.
Unfortunately, pretty much every methodology lacks two crucial insights to be really effective:
- It doesn't tell what to do.
- It doesn't tell how to do it.
What is the best solution to implement a specific dimension, to design a data mart or to broadcast a dashboard? No methodology is telling me that. You will say that this is the domain of designers, rather than project managers' but, then, depending on the choices you do, your "chunks of work" change. The methodology may tell me "first, choose the technology" or "do some design, first, then do something else", but the choice influences the domain of methodology itself.
Then, once I have my plan, the methodology is not telling me anything about how it is going to be implemented. How can I tell which are the best small choices that I need to make to complete the plan elements? The plan success depends on the quality of execution as it depends form the soundness of the original idea. Methodologies may offer a sort of broad guideline on that but the detailed information required to to do the right thing in the right situation, again, is not within the real of methodologies.
What keeps puzzling me is the amount of literature about methodologies (including this post, actually ...) while there is so little literature about the what and how. Better, this subject is left to the market players, who, obviously, have a biased view.
Mind that I am not advocating technology agnosticism; what I am advocating is a discipline about comparing technologies, patterns and practices like in "comparative law" or "comparative language and linguistics".
What I would really need is a book that tells me things like "mind, if you choose My SQL as your database, at some point you will have to tune the xyz database parameter for your environment. It is a cumbersome task because requires to understand this and that etc. In Oracle, on the contrary, you don't do any of that but you do this etc. etc."
This would be a real help in bringing a project over the line. A methodology can only tell you "assess your choices". Well, I think I really do not need that kind of suggestion, I would do it anyway.
So, if the choices you do affect what you need to do in a way no methodology can address, what is the point of having one?
Actually, there is no point, every methodology is reasonably neutral; the people applying it are the real factor. The project success doesn't depend on the choice of the right methodology but from the right choices done within the context of the methodology.
At the end of the day, the only reasonable methodology is:
- Decide what it needs to be done
- Do it
If methodologies fail to offer the crucial guidance to accomplish the crucial choices, than people become crucial.
There is no substitute to a person, or a very small group of persons, who have in their head all the subject matter expertise required to manage the project.
It is the "wide" knowledge I have already advocated as opposed to the "deep" knowledge that it is so popular today.
The most successful project leaders that I have seen were those who were able to move effortlessly from a database design session to a stakeholders meeting going through an analysis session with the users.
These people used a methodology as a sort of frame of reference, to provide bits and pieces helpful to keep everything in order, but they do not hesitate to deviate from it every time their experience tells them it is the right thing to do.
Maybe we are all to much tied to pre-defined roles and personas than it is really necessary.
What do you think?