2

I've been placed in a new position, to manage "projects" for a help desk/tech support organization. Some of the projects on my list have arbitrarily been removed, because they were not considered a project. For example, one was to use Microsoft SCCM to push out an update of a newer version of software, to about a dozen computers. No justification for this decision was provided. I assume it pertained to 'project' size.

I would like to define criteria, attributes, etc to help me provide something we can use, to determine which of the work we perform would be considered a 'project'. Any suggestions ideas would be appreciated. Thank you.

Improve this question
1

2 Answers 2

Reset to default
2

While in theory about anything could be defined as a project (get coffie, buy a pencil etc.), as a practical matter it is just not worth the overhead of managing small tasks as projects.

Perhaps you would like to define "small projects", that is tasks that will not be managed as full blown projects using criteria such as:

  • Time - can in be done in x person-hours or less.
  • Duration - will it be done in x days or less.
  • Cost - will it require the expenditure of more than x dollars.
  • Number of people - can it be done by one person (or x people).
  • Outside involvement - will it require resources from or impact anyone outside the firm.
  • Safety - are there special safety concerns like protective clothing, reporting requirements etc.
  • Legal - is there a potential legal liability to the firm.
  • Other - whatever else is important to you
Improve this answer
1

For what it's worth, in my former company a Project was anything above 50 man.days...

The rule was as follow : For projects with 50+ man.days :

  • must be managed by a PM

  • must follow PMBoK in-house variant methodology

  • full fledge reporting, etc...

For project with a smaller workload (cunningly dubbed as "small projects") :

  • could be managed by PM if any available, but could be managed by developers, or any operational person

  • we had a "small projects" variant of the methodology with a lot less artifacts

  • light reporting

In my view, the rationale is that under a certain complexity / size, project methodology puts too much overhead compared to the benefits. In other words, if there are 10 days of work for 2 people, putting a project methodology in place will not greatly improve the odd of wining / losing

Improve this answer
1
  • This is a fairly common model, in my experience. The 50 day cut-off is probably a bit higher than I have seen in other areas: 30 seems a bit more common, but the number is not important in terms of the principle. The main issue that I have seen is that your customers will try to squeeze you to get everything under the 50 day limit as it suits them to have less governance, as they are not paying for what they see as unproductive overheads. You therefore need to be very sure that your estimating is sound, and be prepared to justify yourself if (for example) you end up with a 52 day estimate.
    – Iain9688
    Jan 7, 2012 at 16:50

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.