Methodologies: A Metaphor
I have long held that insufficient attention has been paid by the project management community to the design of project management methodologies, and moreover that there are too few of them. Then along comes author Jason Charvat with a whole book on the subject of Project Management Methodologies.[1] Jason's background is in the information technology (IT) sector and from his experience he suggests that: "There are numerous e-commerce project and development methodologies available today" and that "They vary largely because of their architectures, technology, and target dates."[2] Indeed, later he observes: "At least 20 different methodologies are competing to be the best methodology, and the list of methodologies keeps on growing."[3]
Without explicitly saying so, what Jason has in mind when he talks about methodologies comes very close to the design of the project life span (PLS). For example, he says: "Methodologies affect project management; they affect any project universally in the sense that each methodology:
- Contains project phases.
- Measures progress.
- Takes corrective actions based on defects found.
- Assigns resources to various phases."[4]
And then Jason makes a profound observation: "I introduce and clarify two types of methodologies. Although they go hand-in-hand, there is a difference:
- Project management methodologies (this lays the high level project management framework).
- Development methodologies (this provides the detail on system design and development)."[5]
Hallelujah! I've been trying to point this out for years. I first made a similar observation in Chapter 3 of the Framework book I wrote and donated to the Project Management Institute back in 1991. I have elaborate on this theme in my latest book A Management Framework for Project, Program and Portfolio Integration.[6]
Whether you want to call it a methodology, a project life cycle or span, a process or series of steps, what we are talking about is a journey. A project starts with an idea and ends with a deliverable. The journey is the "bit in the middle", that is, how you get from the beginning to the end. So, Jason is quite right in implying that there are many different methodologies (i.e. journeys, indeed, as many journeys as there are projects!) And since projects are "unique", every journey is unique.
Some journeys are short and simple requiring a minimal amount of steering (read management and control) while others are long and arduous requiring dedication and determination (read high ceremony). Even others are hazardous requiring care and foresight (read intensive risk management).
Then there are journeys that you can take on foot or bicycle (read one or two stakeholders at most). Or ones you can take by car (just a few family stakeholders), or by bus (where many stakeholders not only have to be satisfied, but may get on and off during different parts of the journey).
Then there are hurry-up journeys like ambulance trips (read the need for fast tracking). On the other hand there are sight-seeing outings which may or may not be planned (read research-type projects) where we simply want to discover what is out there or discover places we might want to revisit later (read development activities.).
Nevertheless, whichever type of journey you are contemplating, how well you arrive inevitably depends on the skill of the driver.
Jason is quite right to distinguish between project management methodologies and development methodologies. But when we come to examine his examples we discover that management of the project components all look very similar. The problem seems to be that different people in different industries (read areas of project management application) use different words to mean virtually the same thing and sometimes the same words to mean different things.
But when it comes to managing the technology there are differences according to whether the outcome (read deliverable or product) is physical or tangible in nature (read "traditional"), or intellectual and intangible (read "hi-tech"). In the former case the journey can, or should, be largely predictable and be mapped from end to end. Sure we may encounter some road diversions along the way (read risk events) and these must be allowed for.
In the case of intellectual products, a rather different journey must be contemplated. The reason is that we have a different type of vehicle and a different type of crew. We are talking now about brainwork and brainworkers and the problem is that the brain does not necessarily travel in straight (read logical) lines. There are left and right brain attributes. These lead to the need for a degree of exploration and discovery (read iterations).
Further, the larger and more complex the purpose (read project destination) the more exploration-and-discovery (iteration) is required. This inevitably means a higher probability of getting lost in the woods (read higher risk) and perhaps confusion over not being able to see the forest for the trees (to mix yet another metaphor).
So, to summarize, before setting out upon the journey we should question:
- Do we know where we want to end up? (Scope)
- Do we know what kind of journey we want it to be? (Quality)
- How urgent is it? How long have we got? (Time)
- How far is it? (Cost)
- How likely are there to be road diversions? (Risks)
- How many passengers are we taking with us? (Human resources/People management, stakeholders)
- Will it be under our own steam, e.g. on foot, bicycle or private car, or will it be supported by others, e.g. by taxi, bus, train or plane? (Contract/Procurement)
- What maps do we need to take with us and with whom do we need to maintain contact throughout the journey? (Information/Communications)
And we must also ask:
- To what extent will it involve exploration? (Iterations)
Perhaps Jason is right. There ARE many different methodologies (read types of journeys). But in most cases the differences are in managing the technology, while for the most part managing the project is very much the same - assuming you want to manage the project at all! In which case, just make sure you pick the right methodology for the task in hand. After all, a fast-track sightseeing tour with no time to stop for lunch will satisfy no one.
Bottom line: First take the time to analyze your type of journey, choose your companions carefully, plan accordingly, and take along enough food and drink (read resources) for the entire trip. In other words, pick the methodology, people and tools-for-the-job that are appropriate to your particular project's needs. The fewer mismatches, the more likely you are to succeed. Big mismatches may prove to be unworkable.
1. Charvat, J.,
Project Management Methodologies, John Wiley & Sons, Inc., New Jersey, 2003
2. Ibid, p84
3. Ibid, p96
4. Ibid, p6
5. Ibid, p64
6. Wideman, R. M., A Management Framework for Project, Program
and Portfolio Integration, Trafford, Victoria, BC, Canada, 2004, Chapter 5
|
