Is it important to have a clearly defined methodology from the outset of a project?

Question

I'm a final year undergraduate student studying software engineering. 1 module for my final year consists of a development project of approximately 6 months.

I'm completely new to this level of project management or even duration.

Last year on industrial placement the longest a personal project took was 23 days, I was provided a specification for a bespoke "add - on" and returned a solution, with details of the testing I'd carried out.

I'm curious as to whether defining the approach I want to take upfront is really that important, having never used a specific "branded" approach?

If I do need to declare a methodology and an approach none of them seem to have a point at which they identify they may not be the most suitable. I'd rather put my hands up and say "Ok, xyz hasn't worked out for me. I'll try this...." rather than get stuck in a series of increments, iterations, flowcharts and not really make the most of my time.

P.S. There doesn't seem to be a "homework" tag as per SO to indicate this is related to a study project.

Answer 1

Not only is it important, it is required. It is impossible to plan your project, that is to determine who you need, what you need, when you need it, how much it will cost, how long it will take you, if you do not have a method of attack.

A simple analogy: if you want to travel across the country, can you do so if you have not yet determined the method of travel? If you want to see the country by car, a plane ticket will do you know good. If you have to get across country in a few hours, walking is not an option. If you want to really experience the vibe of middle America (or wherever you live), doing so at flight level 350 would not meet mission.

The mission dictates methods, which dictates the plan, which dictates the resources.

However, a method is not to be deployed without consideration. You do not take a prescribed method, post it on a wall, and say, 'everyone, go do that.' A method must be tailored for your mission and environment. In fact, this is how methods evolve and new methods are found. A good rule to follow: NEVER implement a method as prescribed.

You do bring up a great point: what happens when your method is not working out as you thought it would. It is unbelievably difficult (read, it feels impossible) to back out of your chosen approach when you are way into it. It is a sunk cost bias, where we have a tendency to stick to something because of the investment already made. Sunk cost should never be one of your criteria, but it almost always is. Can you imagine going to your customer and telling them that the method you proposed $1.5M dollars ago is failing and you need to go in another direction? It happens and is the right business call, but incredibly hard and risky.

So chose your method wisely and after significant critical thought. Modify it to fit mission and environment. And be flexible enough to abandon it if you erred in judgment or other factors are interfering with success.

Answer 2

"Ok, xyz hasn't worked out for me. I'll try this...." rather than get stuck in a series of increments, iterations, flowcharts and not really make the most of my time.

Note, that your comment about xyz not working, I'll try.... is one of the greatest concepts surrounding iterative development & planning. Don't be fearful about getting stuck in a pre-defined project plan. Relish change if it is required, tweak your process, make changes to be faster and more efficient.

• Define the problem definition. What are you building? Why? Let the problem definition describe the goal or problem rather than dictating a solution.
• Set milestones, break out pieces of deliverable functionality.
• Plan for increments that deliver these pieces of functionality. Try and deliver the "riskier" pieces first in the event there are un-forseen issues encountered
• At the end of an iteration or increment review how things went. Are you on track? Can you do something differently? Can you try something new?
• Record your progress. If you don't know what you completed, how will you know if your on track or if your improving?

Every project has course corrections throughout its duration. That said you want to mitigate the number of corrections and the size of them. You also want to balance the number of new things you are trying.