I've read several suggestions on this boards here about how to structure one's eProject space. We're a small implementations management group that essentially has three-four flavors of repeatable projects.

Project Type(s) - simplify, simplify, simplify - use ONE if possible. Key delineators are Hierarchy, Project-level time tracking and Time Range Definition.

Project Templates - setup some initial projects from your Project Type(s) them save off as templates. To include things like applications, documents, resources, already "baked in". This is hierarchical level where project delineation really should take place.

Custom Fields - Use aggressively and often - the real power of eProject. Associated with Project Types not with Project templates so could be a limitation on reduction of Project Types.

I'd love to read what others are doing in their eProject instances and what they believe to be a "best practice" approach with respect to the above..

Thanks,
Matthew

Matthew,

You have a great start with the above.  Other things to consider is to map your SIMPLE processes through the eProject solution and when you train your people, train them on your process on top of eProject.  You will emphasize and clarify your process and you will show them what to use in eProject as they advance through their project lifecycle. 

The next thing you need to learn to utillize is dynamic applications.  They are also the power of eProject.  Dynamic applications can provide a collaborative solution for any area you were carrying spreadsheets or forms. 

I can throw in some comments about Project Types - I don't find it entirely necessary to simplify to just one.  The key impacts from eProject's functionality are essentially Time Tracking style, Custom Fields, Phasing and Auto Health.  Most Customers I have worked with however are usually only impacted by Custom Fields and Phasing.

Scenario 1: 

You have 2 departments using eProject - Finance and Engineering.  All they track in eProject are tasks and issues, standard phases apply and the only custom field they have is "Department" with finance/engineering as options.  They can share a single project type.

 Scenario 2:

 Same 2 departments as above but Finance has special phases specific to the finance world.  They also want project information to include Revenue, Approved Budget, SOX compliance status and Project Rank Number which are all custom fields.  

Engineering wants their phases to be related to a development cycle - they also want project information to include Phase Gate Number, Develpment Cycle and  Customer Name as custom fields. 

In Scenario 2 you would want two project types (one for each department) because they have substantially different tracking needs.

Lets see what others are doing!

Excellent list here, certainly the primary things I try to keep in focus during an implementation.  There is one overarching philosophy I try to bring to all implementations, and in particular new implementations:  Keep it simple and specific.

There are a LOT of features that are secondary or even unimportant for many organizations, but there tends to be a inclincation towards "just leave it on and we'll figure out how to use it."  This can only produce clutter in the user interface and detracts from the primary purposes for implementing the tool.  As a general rule, if you don't have any specific plans for using a feature, just turn it off.  You can always turn it back on at a later time.  The first things to go in many cases are Polls, News and Discussions.  Another one may be Documents, particularly if there is an existing document management system in place that you do not intend to replace or augment with Daptiv's solution.

"Turning a feature off" includes removing the tab from your enterprise roles and deactivating/locking the application for your Project Types.  One of the nice things about this is that it allows you to really fine-tune the functions that are enabled in your "real" project Project Types, but you can opt to leave them on for the Collaborative Workspace, or other general-pupose Project Type.

I may be replying to the wrong thread but can't see one that really talks to the question I need answered.  I have multiple organizations that do not share resources, finances or projects.  they are however both supported by my PMO but the executives are different and don't want their information shared.  What is the best approach to configure Daptiv to allow this functionality.  is it project Type restrictions?  I have searched for info on multiple enterprises but haven't found anything.

 Kim,

 Project Type can be a good delimiter. The major issue with creating different project types is that once you choose a project type for a project, you cannot switch to another Project Type. If you can deal with that true seperation, then creating seperate project types might be a good choice in helping segment your Daptiv usage.

-gWired