4

I am putting together a project sizing tool to help understand what artifacts are required for projects (E.G., a simple project may not require a project charter, whilst a complex project may require a project management plan).

My initial questions set to help determine the project size are below: -

  • Likely Project Cost
  • Project Team Size
  • Number of Vendors
  • Internal Effort (Staff & contractors)
  • External Effort (Vendor staff)
  • Duration of Project
  • Deadlines
  • Domain Experience
  • Complexity
  • Dependencies
  • Customer Facing Services
  • Scope (systems)
  • Project-specific risks

I am seeking feedback if there is anything else that I should / could add to help determine the "size" of a project? Please explain why that would be important as well as where it ranks in terms of importance.

Improve this question

3 Answers 3

Reset to default
3

As MattiSG says, a definitive list is likely neither possible to generate nor likely to provide you much value compared to the effort in compiling and then working with that list.

That being said, I think that the level of bureaucratic overhead associated with a project can and should be tailored based on a short list of general factors:

  • Criticality of the project to the company. This should be definable during development of the project's business case, quantifying the relevant benefits of success vs costs of failure. The most critical projects should be the most tightly controlled and assigned the most/best PM resources.
  • Complexity of the project. Easy surrogates for estimating this are the number of unique deliverables, milestones and stakeholders. The more complex a project the better and more thorough your planning and documentation will need to be.
  • PM Resources available for the project. If you are averaging one or two projects per PM you may be able to better afford having more thorough planning for all of your projects compared to if you are averaging four or five projects per PM.

I don't think you can necessarily rank these in order of importance, you have to look at things holistically and work to facilitate a discussion with your management team to get a consensus on where to send limited resources.

Improve this answer
3

This is your basis of estimate. I agree with MattiSG in that you won't arrive at a definitive list; however, the exercise of trying to and going through the motions is a necessary one.

I would add to your list:

  • history from similar projects
  • any known heuristics
Improve this answer
2

I'm afraid you're on for a never-ending search. Making a definite ontology of projects is probably a dead-end project in itself. All the metrics you gave most probably already overlook specific details in many domains, and would therefore show a need for adjustment for each specific project.

For example, how would you measure “complexity”? It all depends on the domain, and there might not always be an easy way to evaluate upfront…

Considering the fact (or at least, my opinion) that there is no one-size-fits-all project evaluation system, but acknowledging the need for a quick way to determine the most-likely applicable methodologies, I would rather advise using something much simpler, such as the Cockburn scale.

You may for example simply overlay the methodologies you're considering on the corresponding squares, in a zebra pattern.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.