Administration - Job Process Milestones

The Project Milestones screen is where you define and manage your company's process orchestration using project milestones. To learn more about Job Process Milestones and best practices for using them, see Milestones and the Job Lifecycle.

SolarNexus has a pre-defined set of process milestones that all projects must complete. There is no requirement to add any custom milestones, however most companies find significant value in having SolarNexus manage their process to a greater extent. Prior to administering milestones for your company, we recommend first creating a draft of your company's process definition using our process definition worksheet referred to in the SolarNexus Setup Guide.

Milestone Groups (aka Process Phases)

Milestone groups represent the sub-processes in your overall process. For example: Sales, Design and Permitting, Utility Interconnection, Installation, etc. Groups allow your team to see sub-process definitions separately, to simplify views for users who are interested in only particular portions of the overall process. Each milestone is a member of one and only one group.

To create a milestone group, you must view the Project Milestones by Group.

Milestones

To create individual milestones, you must view your Project Milestones in display order.

The following describes the properties of milestones:

Names Before and After Completion: SolarNexus allows you to name the milestone using words that clearly indicate its current status. The name before completion is displayed in the Project's Next Steps. Use a command like phrase for this name, such as "Propose to Customer," or "Submit Permit Application." After it is completed, the name following completion is shown in the Last Completed section, for example "Proposed", or "Permit Application Submitted."

Milestone is a Scheduled Event: A scheduled event represents a calendar event. Any project milestone can be configured to be a scheduled event. Typical examples are sales appointments, site surveys, installations, and AHJ inspections. There are several properties of scheduled events:

• Set Default Start Time - (Disabled by default) Use this setting to automatically schedule the event at a given time interval after its predecessor is completed. For example, if you want to schedule this as a followup call that automatically occurs one month after completing the project, check this and input 30 days. Remember this period is relative to the completion of its immediate predecessor.
• Event has Duration - (Default is true). Appointment-type milestones will have a duration, milestones that just mark the start of some planned activity might not have a duration. If the event will block out a given time period on the calendar (for example, allow 1 hour for sales appointment), use this feature. Note that the duration of each individual project event can be edited when created.
• Send Reminder Notification - Check this if you want SolarNexus to send a reminder notification and input how far in the future you want the reminder to show up.
• Allow Completion after Project is Closed - Check this box if the event is some sort of followup after the project is completed, for example a 60 day checkup call to the customer (closely related to the Default Start Time setting above).
• Schedule This Milestone Upon Completing... (Scheduling Policy) - At a minimum, you set the scheduling policy option for this milestone's immediate predecessor. Options are Require / Allow / Don't Allow. If there is a milestone earlier in the process that you wish result in scheduling this event, you can select it and assign the policy for scheduling. That milestone will now show that it "Results in a Scheduled Event" (see above).

Some things to know about Scheduled Milestones:

• Milestones can have both a scheduled date and a deadline, though it will probably be rare to have both. Having both means "this milestone needs to be done by X but is actually scheduled for Y." Deadline can be displayed as guidance when scheduling the event.
• "Milestone is a Schedule Event" option is disabled for certain standard milestones, including Lead Created, Proposed (because of potential for multiple instances), Archived, Cancelled, and Completed.
• When adding a new scheduled milestone, if a default start time is set and there are existing completed instances of the predecessor milestone, system only sets an initial scheduled start time for a new milestone instances if the scheduled start time would be at least 2 days in the future. (Similar logic exists for setting the initial timeout on new instances when adding a new milestone with a timeout.)
• When setting an existing milestone to be a scheduled milestone, if a default start time is set and there are existing incomplete instances of the milestone, system only sets an initial scheduled start time for existing incomplete instances where the scheduled start time would be at least 2 days in the future.
• When changing the default start time for a scheduled milestone, existing milestone instances are not changed.
• When unchecking "milestone is a scheduled event" option for an exiting milestone, the scheduled times for existing incomplete instances are left in place, but they will be ignored because the milestone is no longer flagged as a scheduled milestone.
• Throughout the app, a milestone scheduled time is only displayed, used for filter criteria, and used to trigger reminders if both the milestone is enabled as a scheduled milestone in its definition and has a scheduled date populated in the instance. This is also how completion deadlines (below) work.

Group: Groups allow you to view milestones related to a specific sub-process quickly, both in administration as well as in a particular project. A milestone is not required to be in a group. To create a milestone group, click on the radio button at the top of the Milestone Definitions to show By Group. Then click Add Group button. Once created, new and existing milestones can be moved into that group one by one by editing each milestone.

Description and Completion Criteria: Provide users with instructions or criteria that helps them assess whether the milestone is actually complete or not. The description may include a summary of the normal steps needed to complete the milestone.

Primary Predecessor: This is the milestone that comes before. Completion of the predecessor is what causes this milestone to be added to a project. NOTE: Standard milestones may NOT have any predecessors that are included by rules. Standard milestones must always be included in every project. You may modify the predecessor of a standard milestone, but only if its another milestone that is used in all projects. Custom milestones do not have this requirement. This ensures that no project ends up at a dead end and cannot be completed.

Secondary Predecessors(s): Secondary predecessors provide a way to define WHEN the milestone gets instantiated, based each job's individual scope of work. The easiest way to understand it, is to take a look at an example. Secondary predecessors can potentially be applied to several points within your Job process, but in this example we will look at the "Complete Project" milestone.

See below screenshot of the milestone editor.

The "Complete Project" milestone should only be available when all of the various parts of the project are complete, and that depends on the specific scope of work for each job. In the example above, the company has a variety of services that may be included in any given customer solution. For the "Complete Project"milestone to be added to a project that includes a "Grid-Tie PV" service and an "HVAC" service, then the "Sold" milestone must be complete (primary predecessor) AND both the "HVAC Install Complete" and "PTO Received" milestones.

NOTES about secondary predecessors:

• 'Secondary' predecessors can only be defined for post-sale / post-work defined milestones. That is, the primary predecessor must be the Sold (or Work Defined) milestone or a subsequent milestone in the process, else we can't depend on service types to be defined.
• Every 'secondary' predecessor is tied to either one service type, OR any service type
• The same secondary predecessor may be specified for multiple service types
• During operation, when a revised solution scope is approved, need to check if changes to solution scope change any of the "partially instantiated" milestones. A change may result in fully instantiating the milestone by removing a condition for instantiation, or result in adding a condition to instantiating the milestone.

Assign To: You can automatically assign each milestone to one of the following:

1. A specific user (by name)
2. A user playing a particular role in a project (for example, sales owner, project manager, engineer/designer). For example, if I have a "Design System" milestone, I can automatically assign it to the user playing the Designer/Engineer role for that project. However, it can only by assigned to the user playing that role, if that role has been assigned. So Ensure Install Roles are assigned to specific people.
3. A workgroup - Depending on workgroup configuration, the milestone will be automatically assigned to an individual in the workgroup, or left assigned to the group - allowing anyone in the group to take ownership (see Managing with Workgroups).
4. Unassigned - the milestone will not be given any assignment

Statuses: Statuses provide a way to communicate the current status of the work being done to complete this milestone. "Pending" is a default status value on all milestones, simply meaning that its in process. The standard pre-populated milestones in SolarNexus have other status values relevant to the specific work expected for each milestone. Each status value also reflects a project condition. Project conditions include normal (green), issue (yellow), and blocked (red). Define statuses that reflect any possible status of the work to complete the milestone. If the status is a blocker (for example, an "AHJ Approved" milestone may have a status called "Correction Notice issued" with a blocker condition to indicate that there is a problem that needs attention.)

Assign Project Roles Upon Completion: This feature dynamically adds new users to the project when the milestone is completed. You specify which user or workgroup to be assigned to what project role. This is a very useful feature for bringing operations personnel onto a project after the sale. For example, on completion of the "Sold" milestone, you could add the "Project Managers" workgroup to play the role of Project Manager. The workgroup configuration will determine which member of the workgroup will be assigned in particular (see Managing with Workgroups).

Results in a Scheduled Event: Checking this box indicates that the result of this milestone is to schedule a date and time for a future milestone that is defined as a SCHEDULED EVENT. When a user completes an instance of a milestone that results in a scheduled event, they are prompted to schedule that event. That future milestone's scheduled date and time are then placed onto the SolarNexus calendar.

When checked, you must indicate which scheduled event will be scheduled. For example, "Schedule Installation" is a milestone that results in a scheduled date and time for the "Start Work" milestone. Note that if you haven't yet created the scheduled event milestone, then that future milestone will not be available from the list of milestones to schedule (the infamous chicken and egg scenario!). The good news is that you can create the scheduled event milestone and then from within its administration, you can select which earlier milestone will be used to schedule it (see "Schedule This Milestone Upon Completing" below).

Auto Update Close Probability Upon Completion: Close probability is a field on each solution as a means to track likelihood of closing the sale to the customer. As you get further along in the sales process, the likelihood should increase. Since updating this field manually is difficult to remember, this feature automatically updates the close probability when a particular milestone is completed in normal course of daily business operations. SolarNexus provides close probabilities with proposed solution prices as report outputs, allowing you to see projected revenues from your sales pipeline.

Set Completion Deadline: This feature allows you to define a time frame in which this milestone is expected to be completed. This feature is exclusive of the "scheduled event" feature (that is, a scheduled event milestone cannot also have a completion deadline defined). The time frame begins when the predecessor milestone is completed. The time frame can be defined in a combination of days and hours. The shortest time frame you can set is 2 hours. Deadlines are always visible in the UI - shown along with the incomplete milestone in the Next Steps section of the Status section in the Management Panel of each project. You can define whether to automatically send notifications to particular users when a milestone becomes overdue for completion.

NOTES on Completion Deadline behaviors:

• When adding a deadline to an existing milestone (or subtask on a milestone), the system will automatically find any current instances of the milestone or subtask, and add the newly defined due time to each instance from the time that the milestone was created.
• When shortening or lengthening an already defined completion deadline, SolarNexus will find any currently existing instances that have not already been manually changed, and will update their deadlines based on the changed definition. All new instances will have the newly defined completion deadline.
• When a user backdates the completion time for a milestone that is the predecessor of a milestone with a defined completion deadline, the user is given the option to start the deadline from the backdated time, or from the current time.

Calendar Event Color: Select the color to represent this milestone as an event or a deadline in the calendar view.

Notify Third Parties When Complete: Use this feature to automatically send templated emails to your customers when certain steps of the process are completed. For example, send customer an Email telling them that you successfully acquired the building permit and will be calling to schedule their installation soon. Note that you must create an Email template before setting this feature up, as you'll need to select the Email template to use when sending the Email. Also note that you can send an automated Email to a specific email address of anyone who is not a user in your SolarNexus account. For example, you may wish to Email a sub-contractor once you have scheduled the installation.

Has Subtasks: The subtasks feature allows you to create a pre-defined checklist of items that need to be done in order to complete the milestone. A subtask may be defined as a checklist item, OR as a full task that is assigned to a person as a separate task on their task list. Checklist items are great as a reminder. SolarNexus strongly recommends avoiding use of full subtasks unless there is a good reason to define them, as they put more overhead on your team to complete them (extra items on their to-do list).

Project Inclusion: A milestone is either included in all of your projects, or only in some subset of projects based on defined conditions about the project. You can define one or more rules that must evaluate to True for a milestone to be added to a project. You may have a group of milestones that are only relevant to a subset of your projects (for example, milestones for administering an incentive). For a group of milestones to be included in a project, the first milestone in the group should have the conditional rules defined. Any others that have the conditional milestone as its predecessor will never be added to the project unless the first one with the conditional rules is added first.

Generally, its a best practice to use field values on the Job screen to drive rules based milestones in a pre-sale project. However after a project is sold (or work is defined for a work order), its best to use set and static aspects, such as "sold solution scope" or "sold solution financing" instead of relying on user inputs on Job screen to drive inclusion of milestones

Adding and Editing Milestones

Newly added milestones, and changes to existing milestone behavior configurations take immediate effect in current projects. As long as a milestone’s predecessor has not been completed within a given project, the new or revised milestone will be added to the project once its predecessor is completed.

Deleting Milestones

You can delete any custom milestones from your company’s process. On deletion, if any other milestones have the deleted milestone as their predecessor, the predecessor of those milestone’s will be automatically changed to the predecessor of the deleted milestone. This works in most cases, but SolarNexus recommends that you review the predecessor behavior of other milestones whenever you delete a milestone.

SolarNexus will automatically remove any currently incomplete instances of the deleted milestone from all jobs that have one. If needed, SolarNexus will replace the deleted milestone with its appropriate successor.