How Big is Your Project?
Interesting LinkedIn Responses
Quite some time ago, under the banner of Project Manager Community - Best Group for Project Management on the Internet, an interesting question was raised. The following are some selected abstracts that I thought contributed useful information.
Dave R observed: I often get asked: "How do you distinguish between a large and a small project. Ideas would be welcome." About 150 responses were received. Here are some of the responses that I feel are the most insightful. They are not necessarily in the same chronological sequence, and some editing has been applied for clarity and conciseness.
Bill D: Dave — I'm assuming that this is not just idle curiosity, but that you have a need for making such a distinction. If so, I'm guessing that you want to differentiate large and small projects for purposes such as project manager assignment, or the appropriate application level of project management practices.
If so, I think "large" and "small" is not the right split. I think that evaluating project management complexity is a better approach.
Steve K: Perhaps the first step is to decide whether the activity should be a project or not. While the work may have the appearance of a project (defined budget, timeframe and scope), it may very well be within the capability of the business-as-usual staff.
If it is to be a project, I agree with Bill. The level of complexity is the key.
Adam W: I have come across this question many times and I am not sure this is the right question. I think ultimately the question is — "How much control do you [or] the management team want to apply to a certain change (project) to reduce the risk?" There could be a financial line drawn, complexity, new technology, people resource level, etc., etc. I think it is good to work out the risk tolerance of the management team, and the amount of control the delivery/technical teams will actually allow, and still be effective.
Samira K: I absolutely agree on all comments with respect to complexity, but I would like to add a few more factors. In my experience in the Telecom world, size of project is dependent on complexity, budget, as well as the impact on systems/databases, and impact on the Customer.
Matthew P: I think "large and small" are terms that best lend themselves to work effort/man hours to deliver the solution. When classifying a project, I think terms such as "material/non material" or "complex/non complex" better allow for other factors to become inputs into the classification such as organization risk and estimated cost. Risk alone can deem a project complex or material if the risks level is high, even if the capital costs or effort to deliver is low. Vice versa, a low risk project with a high effort/cost to implement could be considered complex solely because of the large scope of work.
For a given organization, inputs such as cost and risk thresholds can be established to create a scoring system for objectively defining a project's classification.
Bill D: I'm still a bit puzzled about WHY we want to classify projects as small or large. Is it:
- To guide assignment of the project manager?
- To decide on what management rules to apply (e.g., choice of project life-span, level of control, frequency of reporting)?
- Something else?
Marta I: Bill, thanks for asking — why do we need this kind of classification? In every project you'll have stages with more or less complexity (or even chaos) and with more or less resources/money needed. Consequently, you have to change your management approach (or, as Mike wrote, "amount of governance") according to the project stage and particular requirements. Only in this way can you "achieve a balance of control vs. delivery which matches the project against the organization's risk appetite."
There are no big or small projects. There are complicated, complex chaotic and stable stages of a project. It doesn't mean we don't need any classification. Classification is a kind of a good (theoretical) compass. It gives orientation for choosing the right management approach. It's the experience of the project manager that transfers it into project management best practice.
Mike P: Bill D. is bang on — what are you going to do with the answer (irrespective of which question you've decide to ask)?
For example, suppose you ask the complexity question and discover: you have 3 highly complex, 5 medium complex, and 9 low complexity projects. So, what next?
Rather, the key decision is: How much governance is appropriate for each project (now that you have a better understanding of their characteristics)?
It is usually at this point that you remember that nobody wants lots of governance anyway. So the horse-trading begins on number of reviews, gateways, checkpoints, hand-offs etc.
This is where the true skill of the sponsor, the stakeholders and the project managers come in: To achieve a balance of control vs. delivery that matches the project against the organization's risk appetite.
Bill D: I think the last few posts reinforce my contention that "small or large" is the wrong question. Size (however that is defined and measured) doesn't matter nearly as much as project management complexity.
Stephen M: Small, medium and large, are relative to any company so why discuss it?
Take a $5 million project for example:
- To ExxonMobil it might be small
- To a medium size chemical company it might be a medium size job.
- To a local IT company, it might be huge.
Doug L: Yes, what is large for one industry is small for another; so one needs to find different ways to measure.
For example, in the petrochemical sector the infrastructure projects cost enormous amounts of money and the turnover figures are huge, but in other sectors the figures are much smaller but could have an impact on how large the percentage of the population is affected in conducting its daily life.
Erik H: To answer the original question, "It depends on what you are measuring and for what purpose you are asking!" Secondly, although size in some instances can be objectively measured such as in duration, dollars, tons of concrete, number of team members involved, to name of few, it is a very subjective and therefore relative term. What is large for one is small for another.
~~~~~~~~~~ OOOOOO ~~~~~~~~~~
So there we have it. Asking the question: "How do you distinguish between a large and a small project" only has meaning if first there is a clear statement of background such as:
- What is the context of the question, e.g. industry sector, company, department, project type, circumstances, etc.?
- What measurable aspect of the project are you referencing? And,
- What is the purpose of the question in the first place? In other words, what are you going to do with the answer?
Nevertheless, that seems to be the wrong question in the first place. A better question focuses on some of the project's individual measurable attributes such as how large is the:
- Complexity,
- Impact,
- Estimated cost,
- Risk,
- Expected number of man-hours
- And so on.
|
