Adding, Editing, and Deleting Milestones - Behaviors and Best Practices

General Policies

It's important to understand a few basic tenets about the approach that SolarNexus uses to manage current in-process job milestones in the context of changes to your process definitions: 

1. A process definition MUST contain a continuous "chain" of milestones from "created" to "completed". This means that there must be a common set of milestones that EVERY job in that process uses - regardless of its scope of work. This set of milestones is considered the process's "common path." This requirement ensures that EVERY job always has a path to the end of the process. Rule-based milestones cannot be a part of this common path. SolarNexus will reject any change to an individual milestone's definition that causes the process definition to fail this requirement.
2. Changes to milestone definitions ONLY APPLY to incomplete milestone instances of the changed milestone in ACTIVE JOBS. Changes to milestones ONLY affect current jobs and the change only applies to a portion of the process that is either current for the job, or yet to occur. All milestones that have already been completed on any job will remain complete historical records. The only change to a milestone's definition that will affect a completed instance of that milestone is its name. Inactive jobs records are never affected by changes to milestone definitions. An inactive job is any job that is Completed, Archived, or Cancelled. Unsold jobs (aka leads/opportunities) that are Deferred, or sold jobs that are On-Hold are considered to be currently active with respect to milestone changes.
3. Do not change any current milestone instances on jobs UNLESS a change is required to continue management of that job in the revised process. When your process definition is changed, SolarNexus tries to minimize disruptions to jobs that are currently being processed by your staff by leaving as much of the currently in-process milestones in-place. On completion of the existing tasks, the job may see new milestones that follow.
4. ALWAYS attempt to ensure that a job has the milestone(s) necessary to continuously process the job. There are a couple of different cases where a job can left without the necessary current milestone instances to enable a user to continue working on the job unimpeded:

• • Edits to milestone definitions result in SolarNexus removing a current milestone instance from a job AND SolarNexus finds that there is no current instance of a common path milestone on that job
  • Edits to milestone definitions result in a job's current milestone(s) having no successor(s), leaving the job stuck.
  • A user completes a milestone that has no successor(s), AND the job has no other current milestones.

When any of the above scenarios occur, SolarNexus will automatically attempt to *fix* the milestones on the job so that processing can continue unimpeded.

To make a continuity fix, SolarNexus will pro-actively create the next "common path" milestone for that job. To find the next "common path" milestone, SolarNexus looks at the last completed milestone(s) on the job and then traces their predecessors back to find its "common path" ancestor and then instantiates the next "common path" milestone from there.

If the next "common-path" milestone in the process requires a secondary predecessor that is incomplete, SolarNexus checks to see there is a current instance of that secondary predecessor milestone, or an instance of a direct predecessor to that secondary predecessor milestone. If neither, SolarNexus will assume that a process change has necessitated an exception, and will ignore the secondary predecessor requirement for this job and create the common-path milestone despite not having the secondary predecessor.

OTHER EXCEPTION CASES: Its possible to create other cases complex enough that SolarNexus cannot reliably know how the intended changes should be applied to affected jobs. It is therefore possible that some jobs could be left without any current milestone(s). In these rare cases, an administrator can manually instantiate the successors of an already completed milestone on the job in order to instantiate the desired successor milestones for the job. See section below for how to fix this scenario.

 

 

 

Categories of Milestone Definition Changes

There are 3 different categories of changes that may be made to your milestone definitions. The categories are defined by how they affect the current milestone instances on your active in-process jobs (the milestones that are currently incomplete and represented by cards in the Status section of each job), and whether the changes require SolarNexus to propagate changes to the milestones in the affected jobs.

 

Category A: Category A covers edits that have a major effect on current instances of the edited milestone, and potentially of associated predecessors and successors. Because all milestones in a given process are interconnected, if any Category A change is made to any milestone, then ALL milestone completions within that process will be temporarily blocked until SolarNexus finishes propagating necessary updates to all affected milestone instances. After SolarNexus examines and updates a given job, milestone completion is re-enabled on that job so that your team does not have to wait for all jobs to be processed before taking action on milestones. Elements having major effect include:

• Changing a Primary Predecessor
• Changing a Milestone into / out of being a Scheduled Event
• Changing Process Inclusion Rules (All jobs, or only jobs that rule(s) evaluate to True)
• Deleting a Milestone

Category B: Category B changes have minor effects on current milestone instances. SolarNexus will propagate Category B changes to each current incomplete milestone instance on jobs, but SolarNexus will allow users to complete/uncomplete instances of the edited milestone while SolarNexus propagates the changes. These properties are:

• Name AFTER Completion
• Milestone Group
• Status values
• Deadline related fields
• Has Subtasks and related fields.

Category C: The following category of changes do not affect data for current milestone instances in your jobs:

• Creation of any new milestone (no new instances are automatically added to any jobs)
• Edits to any of the following properties of an existing milestone:
  • Names BEFORE Completion
  • "Description and Completion Criteria"
  • Add/remove/modify "Secondary Predecessor(s)" - NOTE, this means that jobs that are already past the point at which the secondary predecessor would be instantiated will not be affected. SolarNexus ignores enforcement of secondary predecessors for such jobs. SolarNexus will start enforcing the secondary predecessor requirement only for new jobs entering this part of the process. 
  • "Assign To"
  • "Assign Project Roles Upon Completion"
  • "Auto Update Close Probability Upon Completion"
  • Calendar Color
  • "Notify 3rd Parties When Complete".

 

When editing one or more properties of an existing milestone definition - the action belonging to the highest category will be performed. For example:

• If only changing one or more "C" properties, then will do the action corresponding to C (that is, no propagation of changes to individual milestones instances, completion of milestones is allowed).
• If changing one or more "B" properties, then action "B" will be performed (SolarNexus will propagate changes to individual milestone instances without disabling completion or uncompletion of those milestones).
• If changing a "B" and a "C" category property at the same time, action "B" will be performed (propagation of changes without disabling milestone completion).
• If changing one category "A", one "B", and one "C" property, then action "A" will be performed (SolarNexus will temporarily disable completion of all milestone instances while propagating required updates to those milestone instances on current jobs).

 

Deploying Updates - Timing

SolarNexus manages the timing of how various categories of milestone definition changes are deployed to your active jobs.

• Category A or B changes are held for deployment for one hour after changes are initially saved. SolarNexus lists pending updates at top of the Job Process screen.
• Category C changes are immediately available.

When editing milestone definitions, Changes made to SolarNexus does not immediately deploy changes from Category A or B because these updates can have strong interdependencies with other milestone definitions. Holding off on deploying changes provides the administrator with some time to make additional edits to other milestone definitions, thereby allowing SolarNexus to apply all changes at once - which can limit the time that users may be prevented from updating tasks on affected jobs. The administrator may skip the one hour hold for deploying changes by clicking the "Start Updates Now" button.

 

Best Practices

After years of experience with modeling process changes in SolarNexus, we've learned some best practices that we always take when modifying processes.

Model All Process Changes BEFORE Implementing

Process modeling is a relatively complex endeavor. SolarNexus STRONGLY encourages you to model out all planned changes in a spreadsheet prior to trying to implement in SolarNexus. SolarNexus does not provide a separate sandbox for testing process changes - the complexity is too great for simulating changes to jobs in process. Modeling outside of SolarNexus allows you to consider all the potential issues. You should strive to create a clear set of ordered steps for making changes.

 

Assess Impacts of Changes and Prepare Staff

Use Sales/Installs screens or Project Reports to assess jobs that will be affected by a given change. Warn relevant users about changes BEFORE they are implemented. For example, before deleting a milestone, you should find how many instances are current on your jobs and warn assigned users that those instances will be removed so that they do not become confused/worried that things are broken. You can also use the Home screen's Announcements section to tell users about changes to expect.

 

Run a Project Detail Report Before and After Implementing Changes

Create a project detail report. Select Active/Deferred Jobs. Optionally use the Complete / Incomplete Milestone filters to limit job selection to only jobs that will be affected by your changes. Be careful to not restrict the results too much. Be sure to include output fields that are relevant to your changes. For example, if you are applying rules to milestones based on sold solution scope of work, then be sure to include that as an output. ALWAYS include current milestones and details as an output. Last completed milestone can also be helpful. Download the report results to CSV and safely store.

Depending on the scope of changes and number of milestones updated, you may need to wait a significant amount of time before SolarNexus completes all updates. Run same report and also export to CSV.

For each CSV sheet, add a column. For the report contents before the updates, input "PRE" into the new columns cell for every row. Do the same for the post implementation results, but input "POST" into the cells. Copy-paste the pre and post result rows into a new sheet and sort by 1) job number, and secondly by the new pre/post column. You should now have same job's pre and post implementation data grouped together.

You can scan for changes

 

Implement Changes to Milestone Definitions During Low Usage Times

Since updating milestone definitions can result in SolarNexus temporarily disabling completion of milestones, as well as changes to individual users task lists, we strongly recommend planning to make any milestone edits outside of prime work hours. Updates should typically be planned during nights or weekends, whenever the least number of users will be affected.

 

Closely Monitor Process as Jobs Transition to New Process

After completing a significant update to your process definition, things to look for include:

• If you've started using job roles to automate milestone assignments, look for milestones that are not being assigned because the role for that job was not assigned (milestone that assigns the role may have already been completed.) Use Tasks screen to view current instances of the task in question. Manually make assignments where necessary.
• Look for jobs that are missing milestones that are expected given its scope of work. Perhaps you have re-ordered milestones in such a way that an already completed milestone is needed to populate new milestones. (See "Fixing Jobs Missing Key Milestones Following Process Updates" below).

 

Example Edit Scenarios and Expected Results

Here is a collection of scenarios with descriptions on how to do the edits and what to expect to happen with your current in-process jobs.

 

Minor Changes to Milestone Properties

Given

• Current milestone definition process A > B > C.
• Current Jobs and their current milestones:
  • Job 1 has milestone A
  • Job 2 has milestone B

Process Revision

Editing Steps:

1. Edit milestone A, change before and after names (category B)
2. Edit milestone B, change default assigned user (category C)

Resulting Process:  A > B > C

Expected Results

• Job 1 - SolarNexus will update milestone name, however user may see previous name until the change is made. User may complete milestone A, and SolarNexus will populate milestone B, assigning its new default owner.
• Job 2 - SolarNexus makes no changes. Despite milestone B's default assigned owner being changed, this instance already existed and had an owner.

 

Adding a New Milestone Between Two Existing Milestones

Given

• Current Process: A > B > C (common path milestones)
• Current Jobs and their current milestones:
  • Job 1 has milestone A
  • Job 2 has milestone B
  • Job 3 has milestone C

Process Revision

Editing Steps:

1. First create the new milestone A' and set its primary predecessor to A.
2. Then edit milestone B and change its primary predecessor to A'.

Resulting Process:  A > A' > B > C

Expected Results

• Job 1 has no visible changes. User completes A, SolarNexus populated milestone A'.
• Job 2 - SolarNexus removes milestone B and adds milestone A'. When A' is completed, milestone B will be populated.
• Job 3 has no changes. Complete milestone C and job continues. Job is already past point in the process where A' is relevant. It will not get an instance of A'.

 

Limit Inclusion of a Milestone to Jobs with a Specific Type of Service in its Scope of Work

Given

• Current process: A > B > C > D (common milestones)
• Current Jobs and their current milestones:
  • Job 1 has milestone A and includes Grid-Tie PV in its sold scope of work.
  • Job 2 has milestone A and does not include Grid-Tie PV in its sold scope of work.
  • Job 3 has milestone B and includes Grid-Tie PV.
  • Job 4 has milestone B and does not include Grid-Tie PV.
  • Job 5 has milestone C and includes Grid-Tie PV

Process Revision

Editing Steps:

1. To maintain the common path, you must first edit milestone C, changing its primary predecessor to A.
2. Then edit milestone B, and change its relevance rule from "All" to rule-based, with rule: Sold Solution Scope includes Grid-Tie PV.

Resulting Process:

A > C > D
    > B (included only if job includes Grid-Tie PV)

Expected Results

• SolarNexus puts a temporary block on any milestones from being completed on any jobs while it processes required updates to relevant jobs.
• Job 1 - SolarNexus makes no changes. User completes A, SolarNexus populates milestones B and C. When C is completed, D is added. When B is completed, nothing else is added.
• Job 2 - SolarNexus makes no changes. User completes A, SolarNexus populates milestone C, but not B. When C is completed, D is added.
• Job 3 - SolarNexus checks job to see if B is still relevant. It is so it leaves it. SolarNexus then checks for a common path milestone and there is no current common path instance. Since C does not have a secondary predecessor delaying its addition, SolarNexus adds milestone C to the job. Job has milestones B and C. User completes B and nothing is added. User completes C and D is added..
• Job 4 - SolarNexus removes the milestone B instance because it is not considered relevant to the job. SolarNexus adds milestone C to the job. User completes milestone C and SolarNexus populates D.
• Job 5 - No changes are made to the job. It already has a complete instance of B. For this job, the presence of Grid-Tie PV is irrelevant.

 

Add a New Milestone as a Secondary Predecessor to an Existing Milestone

Given

• Current process: A > B > C (common path milestones)
• Current Jobs and their current milestones:
  • Job 1 has milestone A and includes Grid-Tie PV in its sold scope of work.
  • Job 2 with milestone B and has Grid-Tie PV in its sold scope of work.
  • Job 3 has with milestone C and includes Grid-Tie PV.

Process Revision

Editing Steps:

1. First create the new milestone B', with its primary predecessor to A, and relevance rule: sold solution scope includes Grid-Tie PV.
2. Then edit milestone C, and add secondary predecessor: when job includes Grid-Tie PV, require B' as predecessor.

Resulting Process:

A > B > C
    > B' (included only if job includes Grid-Tie PV)

C is to only appear for jobs with Grid-Tie PV when B' is also complete.

 

Expected Results

• Job 1 - SolarNexus makes no changes. User completes A, SolarNexus populates B and B'. User completes B, job is left with B'. User completes B' and SolarNexus populates milestone C. Milestone C is only added once BOTH milestones B and B' are completed (in either order).
• Job 2 - SolarNexus makes no changes. When user completes milestone B, SolarNexus adds milestone C. SolarNexus ignores the secondary predecessor of B' because this job was already past the point at which B' would have been added to the job.
• Job 3 - SolarNexus makes no changes. User completes milestone C and job continues. Job is already past point in the process where B' is relevant. It will not get an instance of B'.

 

Reactivating an Archived Lead

When reactivating any previously archived leads any new milestones that occur after the last completed milestone will be populated in the project.

 

 

Fixing Jobs Missing Key Milestones Following Process Updates

When a set of complex changes are made to a process, it is possible to create a situation where a current job should be populated with needed milestones, but edits to the process definition have left it impossible to get the needed milestones because the needed milestones now have a predecessor that this job has already passed in the process. For example:

Given

• Current process: A > B > C > D > E > F (common path milestones)
• Current Jobs and their current milestones:
  • Job 1 has milestone A
  • Job 2 has milestone B
  • Job 3 has milestone C
  • Job 4 has milestone D

Process Revision

Editing Steps:

1. Edit milestone D, changing its predecessor to A.
2. Edit milestone F, changing its predecessor to C.

Resulting Process:

A > B > C > F
    > D > E        

 

Expected Results

• Job 1 - SolarNexus makes no changes. User completes milestone A, SolarNexus populates milestones B and D.
• Job 2 - SolarNexus makes no changes. When user completes B, SolarNexus populates milestone C. User completes C and SolarNexus populates milestone F. The milestones D and E will not appear for this job.
• Job 3 - SolarNexus makes no changes. When user completes C job will get F. The milestones D and E will not appear for this job.
• Job 4 - SolarNexus makes no changes. When user completes D, job will get E. When user completes E, job will have no milestones, triggering SolarNexus to automatically populate next common path milestone C.

Note that Jobs 2 and 3 will no longer have a way to get milestones D and E. Although this is a rare scenario, it can happen. And when it does, the only way to "fix" a given job to continue with the altered process is to manually instantiate the milestones that would come after completion of milestone A. There are two ways to fix this scenario:

1. For users with administrative permissions, SolarNexus provides special control to instantiate desired successor milestones that otherwise would not get added to a job. From the Tasks section of the job's Management Panel, click View All milestones. At the bottom of this screen you will find a control to initiate manual instantiation of new milestone successors for a selected milestone (see screenshot below). In this case, admin user would instantiate successor(s) to milestone A, which would add milestone D.

   

2. For users without administrative permissions, getting milestone D added is more difficult, but can be done. User would need to uncomplete milestone A and then recomplete it. This time on completion, the job would get milestones B and D populated.