Project Definitions

Projects are assigned a project leader who is responsible for execution and monitoring of the project. Notifications about each project will be sent to the leader. As with external contacts, the leader can be easily emailed about the project as well. Projects can be a “child” of another project, such as in the case of a change order- the original scoped project remains as is, and the change order becomes a new project (and budget) with the original project as its associated parent.

Projects require the assignment of key properties that drive how the metrics
are calculated, how it is proposed, and more:
o A rate card is assigned (see section on Rate Cards). This defines the billing rates by title.
o A contract type is assigned, which defines if it is a fixed price project billed by milestones, or a T+M job billed by hours and expenses, some form of Not-to- exceed, etc. Users can add and edit the contract types in the Settings menus

There are many features that can be adjusted for each. The system comes shipped with these types pre-defined:
▪ T+M
▪ T+M NTE with Fixed Limit
▪ T+M NTE with Notification
▪ Fixed Price
▪ Internal Project
▪ Software Sale
▪ Value Added Resale
o A payment term is assigned. These are also configurable by the user, and have defined number of days before the payment is due. Predefined entries include NET30, NET15, NET90, etc. These are used by the Accounts Receivable report and others to show late invoices.
o Projects can have varying markups applied by each expense typelabor, expense, or material. They can have a single overall
contingency percentage applied too.
o If you accept payment by credit card, you can enable credit card payment client by client. Projects have a field for the percentage extra
you will invoice for payments by credit card (if any). So for some projects and clients, you may accept cards, and for some you may
charge extra. If you charge extra for the credit card payment, this is listed as an alternative cost on the invoices the system generates, so
the client knows what they must pay if they pay by card.

Once defined, projects have many child records that are used to complete the work such as

  • Scope and Clauses Clarification
  • Milestones
  • RFI’s
  • Related Files
  • Deliverable, or Type of Work, or Phase Order
  • Tasks, Expenses, and Materials
     

Project Workflow

The workflow can be adjusted if necessary by customization. The predefined workflow is shown in the section dedicated to that subject below. Generally, it is defined as follows: o Users identify a real or potential opportunity for a client and enter it as a new project (opportunity).
o As the project becomes more real, it is moved from opportunity to scoping to estimating. During these steps, authorized users configure
the project as defined above, and add sub-projects, tasks, expenses, and materials in order to arrive at an estimate. They also add scope,
clarification, and milestones as needed.
o Once the definer(s) of the sub-projects are happy with their estimate, they freeze (lock) their sub-project. The project cannot be submitted
for approval unless all sub-projects are frozen, and once frozen, sub-projects and their contents cannot be edited. This is to prevent
modifications to the project during approval review.
o The project lead submits the project for review by finance or a similar entity. If they approve, the project appears on management/CEO
approval screens. Each approver gets email notifications that a project is waiting for them at the time of the transition, and those
projects appear on their Dashboard screen also.
o If the CEO approves, the project lead is notified and they can send the proposal to the client and mark the workflow as such.
o At any time prior to this, the lead can indicate that the project/opportunity is lost for one of a number of reasons, which can be reported on.
o Similarly, after the proposal is sent to the client, it can be marked as lost for a number of different reasons.
o If the project is won, the lead moves the project approval by a finance approver, who reviews and accepts the PO or other contractual agreements, and then the lead can move the project into execution.
o At the completion of a project, finance and CEO have the opportunity to review project performance before final closure.
o Projects or Opportunities can be shelved temporarily. When shelved, the project does not appear on active lists. Examples of the utility of this function are when a client says that they will be willing to discuss an upcoming potential (opportunity) but only after the holidays, or if a project is only going to be approved after a client’s new budget year starts. When projects are shelved, the system will prompt for a reason, and management level users will be emailed about the shelving, including the reason. When a project comes off the shelved list, the project manager is emailed with the details, including the original reason for the shelving.


Project Execution

During execution, sub-project or project leaders can optionally assign resources to tasks. Upon assignment, resources are sent an email notifying them of the assignment, including project details, budget, and comments (instructions) entered by the assigner. Similarly, users get an email when their assignment is removed. Resources that are assigned to a task will receive a daily email reminding them of the assignment. This email will contain the task description, assignment comment and budgetary status of the task, and will allow submission of time by replying to the email. 
Multiple resources can be assigned to a task, and users can generate a related email to assigned resources directly from the task screen. Project tasks are easily reviewed by managers using review screens and task screens. When reviewers enter comments on a task, the comment is saved with a snapshot of the task status at the time of the comment. This way, comments and task status can be reviewed historically, allowing for “what happened” type reviews.
Screens are provided to allow sub-project or project managers to update the percentage complete for each labor task. The percentage complete and the current time expended is used to calculate extrapolated hours for each task, as well as extrapolated labor cost. These are summed upwards into sub-project and project statistics and so can be used to predict the final total metrics of a project.
PDF reports are emailed to project leads several times a week showing summary metrics, highlighted with color for emphasis on problem areas.
A screen and PDF report are available once a project is executing showing the original plan of the project including metrics, and comparing that vs. actual figures. This is highlighted in color for problem areas and can be used for in-progress reviews. Files such as software backups can be uploaded into project and/or client asset records as needed.