Project Management

Please login or join to subscribe to this thread

Small firm - small projects.

linkedin twitter facebook   Estimating  
avatar
Anonymous
Hi all, I've been tasked with implementing a project management system in a small, new engineering firm (10 people) . Having just graduated, and no PM experience outside of school and a PM Certificate, I've been hitting some road blocks. The issue lies in the fact that our project durations can range from 2 days to 1 year long, and there are about 50+ projects active at the same time. Some require schedules and some aren't worth having anything more than a few tasks, others are more intensive with multiple phases. Any ideas or suggestions would be greatly appreciated. Thanks!
Sort By:
avatar
Taralyn Frasqueri-Molina Senior Project Manager| Independent Contractor Pasadena, Ca, United States
My first thought is... look at the totality of what is on your plate and separate out what is a project and what isn't a project (and I guess you'd need to know what the difference means to you!). At the very least, you can separate out by short (2 days) - medium (2 months) - long term (2 years) durations.

Those things you/your team is working on that require only a few tasks to complete and may be on the shorter duration range, probably aren't projects.

After separation, I'd look at what needs to happen sooner rather than later. Not necessarily what's shortest to do, but what's most important to start accomplishing and gaining wins on now.

I think I have more ideas brewing... Very interesting situation you have and congrats on being a new PM!

avatar
Peter Wright Programme Manager| BAE Systems Southport, Merseyside, United Kingdom
Good advice from Taralyn

If you have 50 actual projects are any of these linked in any way (e.g. are they part of a product upgrade and are either activities of the Product Upgrade project or projects forming part of the product upgrade program). Some people will disagree but some tools such as Project Pro can provide a lot of what you need with excel in support, if all of your people have access.

Do not try and implement a rigid structure/Prince2 and raising 101 documents for a project. Look at what your business needs (requirements) for logging progress, reporting and escalations.

Once you have your requirements look at what tools/systems you have and mark down if it meets one of the requirements wholly, partially (stating what it does/not do), or not at all.

Then you can see what gaps you have and work out the most cost effective way to meet the requirement.

Looks at quick and if needed cheap ways for communication - like media wiki instead of implementing a forecst of word documents. There are loads of templates on Gannthead you can also utilise/tailor for project plans etc.



avatar
Wai Mun Koo PMO Director| Intergraph PP&M Singapore, Singapore
Good points from Taralyn and Peter.
I would add that the first thing is to have a proper definition and differentiation between change request (enhancement) and project. This can be based on duration, estimated cost and complexity etc. Next, come up with a method (or matrix) to do project sizing, i.e. to classify the projects into different sizes (e.g. small, medium large), and have different processes and templates for each type of projects to provide some flexibility in managing them.
avatar
Anonymous
Thanks for the suggestions. I've defined projects based on their duration/budget, but my biggest issue in organizing is that it ends up being a huge task list. A lot of the small projects don't have schedules or deadlines, so I've been trying to fit them into an overall schedule by setting internal deadlines. But really it ends up being an organizational jigzaw.

I've flipped between MS Project and Excel. I started with Project but was having difficulties making it work since I was missing a lot of the information. So I switched to Excel but it was too strenuous to create reports, print out schedules, etc. And now I'm back to Project.

What I've done is create schedules for larger projects, then I have one project filed with the small jobs, and I try and work them together in a consolidated project file (all share a resource pool).

Essentially, to make any of this effective, I need to come up with a plan and stick to it, but with no mentor or guidance, I'm looking for help in tweaking it, as I've found the majority techniques found in the PMBOK don't apply (yet).
avatar
Peter Wright Programme Manager| BAE Systems Southport, Merseyside, United Kingdom
Anon,

Looks like you have created a master project file which you are rolling up all other projects. If using project this is likely to be your only option.

By using that approach you will be able to look at utilisations/overallocations etc.

If your projects do not have schedules or deadlines - then they are either not really a project yet but in scoping/concept phase or they are not a priority (Nice to have) so set their priority in Project to 100 instead of 500. Make the more inportant projects 750-1000 and that way if you use the auto scheduler it should take these priorities into account.

Make sure you do a Must/Should/Could analysis of the "Projects" and any in the "could" be set to 10-100, should's set to 400-600 and Must set to 750-1000. You can then modify the individual tasks and increase the priority accordingly even if the project is a different level.

avatar
Elizabeth Harrin Director| RebelsGuideToPM.com London, England, United Kingdom
Hi, just as a note on what we do, we also manage a mix of business as usual and change requests and 'proper' projects. A project is defined (for us) is anything that is estimated to take over 5 working days. We have a project list and a BAU list in one Sharepoint site, so you can filter on different categories like customer or main point of contact. This helps us keep on top of what the work looks like but is no good for scheduling as there is no adequate Gantt chart or calendar view option on our Sharepoint installation. Still, if you don't have schedules for some of the smaller things, but do have Sharepoint, that could be something to consider for your ad hoc requests.
avatar
Josh Nankivel Engineering Project Manager| Apple Sioux Falls, Sd, United States
I used a Sharepoint system when I worked in an environment like the one you described. All projects were in the Sharepoint tool, and we'd attach other artifacts like a schedule, etc as needed depending on the size of the project.

Some projects were just a few days and so the minimum required fields in the Sharepoint form were enough info, documentation usually consisted of just that an perhaps an email or two.

Please login or join to reply

Content ID:
ADVERTISEMENTS

If man could be crossed with the cat, it would improve man but deteriorate the cat.

- Mark Twain

ADVERTISEMENT

Sponsors