Who needs a methodology? Just do it. Photo: Spring 2013 Hackathon at Columbia University, where participants were challenged to build — over a weekend — software programs for New York City startups; by Matylda Czarnecka, hackNY.org, CC license.
You’re about to launch a big ERP project.
You need a structured methodology. The lazy/easy thing to do is to use the one your software vendor or consulting partner uses. Don’t automatically accept this. Understand first how their methodology works (it’s usually designed to maximize billable hours). Then use common sense.
A methodology is simply a way of doing things. A methodology for doing laundry could be: 1) separate colors from whites; 2) wash whites in hot water/cold rinse with bleach; 3) wash colors in cold water; 4) hang dry delicate fabrics and put everything else in the dryer on medium heat for 30 minutes.
But there can be variations in laundry methodology depending on preferences and beliefs, such as 1) throw colors and whites together in a cold wash and cold rinse so colors don’t run; 2) throw everything in the dryer on delicate cycle; 3) check periodically for dryness; and 4) pull out anything that seems dry.
IT project methodologies are practically an industry – templates, software, books, training programs and consulting engagements.
The “waterfall methodology” used in Microsoft Project and adhered to for decades by many in the project management field is arguably flawed from the beginning, at least according to some. This methodology assumes that task completion is a function of the number of man-hours, total time duration, and dependency on completion of one or more preceding tasks. Viewed on a chart, the timeline of the project looks like waterfalls cascading from left to right, top to bottom, as time progresses.
Frederick Brooks, the computing legend who pioneered IBM’s System/360 mainframe computers launched between 1965 and 1978, says in his seminal book The Mythical Man-Month that “the basic fallacy of the waterfall model is that it assumes a project goes through the process once, that the architecture is excellent and easy to use, the implementation design is sound, and the realization is fixable as testing proceeds (but) experience and ideas from each downstream part of the construction process must leap upstream, sometimes more than one stage, and affect the upstream activity.”
Brooks also says the planning process usually and mistakenly assumes that the right people will be there, available, focused and engaged, when they are needed, and that when they perform their work they will do so in a linear fashion, with no mistakes and no need to backtrack and start over. In the 21st century, this is simply not the case in many organizations.
I don’t prefer one particular methodology – I think the way to work depends on what you’re trying to achieve, by when, with whom. I also think the imposition of a particular methodology – if it doesn’t fit the project or the team – will actually detract from success.
I do like at least one part of the Scrum methodology, called a Sprint. It could be a one week or two week “Sprint,” but the idea is the same: everyone needed for a particular stage or segment of the project is brought together and forced to stay together until their part is finished and tested. Just get together and get it done.
Have you seen the videos where a house is built in a day? Here is just one. How did they do that? Lots of preparation, teamwork, intensity, focus, urgency.
The idea of a sprint in an IT project is the same: skilled people intensely focused on the same, singular objective that must be achieved within a fixed period of time. I like it because sometimes it’s the only way to get the brains you need to complete something without the endless distractions of everyday work. Attention deficit is rampant in organizations today — exactly the opposite of what successful enterprise software projects need to be successful.
Which methodology is best? For your project, the best methodology is the one that provides structure in a common-sense way with simple, easy-to-use tools that you think your team will, in a practical sense, actually stick to.
