Projects are set by an MSR, or by the system in the case of certain project orders. When a project arrives, it goes through three phases: Review, Assignment, and Execution.
Process Flow: Projects
Review
Context
● Is this a duplicate of an existing project?
● Is this an already completed project?
● Is this new information on an existing project?
Update related projects as necessary.
Add notes explaining reason for canceling project.
Notify the setting MSR and assigned MSP of the change of status.
Cancel the project.
Resources
● Did the member authorize enough time to reasonably complete the project?
● Do we have enough information to complete the project?
Internal
Communication:
Explain why the project had to be cancelled, and set a follow up for the MSR who created the project to explain this to the member.
Notify the setting MSR and assigned MSP Cancel the project.
Add description of missing information to member notes in project.
Send system message for Need Info to the member, describing what's needed.
Set the project on delay with a reason.
To Step 2: Assignment
We will not:
● Alter any DNS records except: adding A and CNAME records, redirecting mail A record for 3rd party email, changing MX records to Google.
● Do any work that is not technically possible, like making a website wash the floor.
● Do any work that causes a member to break any federal, state, local, or association laws or rules that we are aware of.
● Create something that bypasses a solution already available in our system.
Legitimacy
● Could the member or MSR have done this themselves, and if so were they notified of this option?
● Is the project on the list of things we won't do?
After a project passes the Review stage, it is ready to be Assigned.
Process Flow: Projects
Proper categorization and actions ensures the right options are available to the MSP and compensation is correct.
Assignment
To Step 3: Execution Modify Associated
Follow ups
● Change date of follow up so it is not before date project is expected to be completed.
● Add follow up notes if necessary for MSR info.
The project documentation should contain a list and descriptions of all common projects.
The MSR who set the project may need to be consulted.
Clarify Project
● Ensure that project notes contain everything the MSP is expected to need.
● Label and tag/group the project as required.
● Add authorized time to project.
Set Category and Action
● Set appropriate category and action for project.
● Consult project list and instructions for
clarification.
Sometimes the member's history will need to be thoroughly reviewed to properly understand the project.
MSP skill set and availability can be determined by the team chart and schedule, or at the daily scrum.
Standard turnaround times are per the chart.
These will need to be adjusted, with fairness to all project, based on current load.
Flexibility should consider everything on the follow up priority chart, plus special scheduling considerations like DNS changes.
Set MSP, Due Date, and Flexibility
● Set MSP based on skill set and availability.
● Set due date based on standard turnaround times and current load.
● Set flexibility based on member business impact/
project priority.
If a follow up date is changed significantly, a courtesy note should be sent to the MSR who set the project. If the MSR misinformed the member of the expected turnaround, an internal communication should be set with a follow up for the MSR to correct this understanding with the member.
After the Assignment stage, the project is handed off to the person actually doing the work for Execution.
Process Flow: Projects
Execution
If there is any question about whether a follow up should be marked done, make a note in the follow up and directly contact the MSR who set it for clarification.
Analysis
● The person doing the work must be sure they have what it takes to complete it in the time frame specified.
Do the Project
● Use available resources including the Projects Handbook, Reservoir, and KB.
The MSP
will ask themselves:
● Is there a documented procedure for this project?
● Do I have the
knowledge to execute it?
● Do I have the available time?
● Do I have access and other resources required?
Add description of missing information to member notes in project.
Send system message for Need Info to the member, describing what's needed.
Set the project on delay with a reason.
What's Missing?
Information or assistance from member.
Add description of what is needed to our notes in project.
Communicate with team members as required to resolve.
Information or assistance from team.
Update project notes to explain what has been done and document any exceptions or
irregularities.
Send Project Done system message with clear description of what was done.
Mark the Project as Completed.
Mark related Follow Ups as completed.
Project is Done!
While projects are in process, new information may be received from the support team or directly from the member. This information needs to be processed properly and quickly.
Process Flow: Projects
Dealing with New Project Information
New Information Arrives
New information directly from the member will show up as a flashing indicator on the project. These must be addressed within 24 hours.
Add pertinent information from member into project notes and post an acknowledgment reply in our notes to member..
If project is on delay, re- process from Step 2:
Assignment.
If project is on hold, re- process from Step 1:
Review.
Project Status
New information from the MSR may show up as a new project (handled in Step 1) or direct communication.
Add pertinent information from MSR into project notes.
Copy the request into an Internal Communication, explaining that it came through a project but needs to be handled by support. Assign to the specialization covering the request.
Return to the project and remove the notes and clear the change flag.
If the information requests support and has nothing to do with the project, volley it back to support.
Clear the change flag.
While projects are in process, they must be reviewed at least once each working day.
Process Flow: Projects
Reviewing Assigned Projects
Contact assigned to MSP to ensure they are working on project.
Project is Overdue
If the project is very flexible, adjust the due date to a reasonable date in the future, ensuring it does not
interfere with other assigned projects.
Review history to ensure that member received direct communication about this delay at least 7 days ago.
Send the Project on Hold system message to the member.
Project is Delayed for 7 days or longer.
Review history to confirm that member has not provided the necessary
information.
Contact the assigned to MSP to ensure they do not have any additional information.
Set the project on hold.
Contact the MSR to whom the follow up is assigned and the support team leader to let them know that project is at risk of being put on hold. Extend delay.
Any change to a project's schedule requires that it go through Step 2:
Assignment, again.
If the project is not flexible, assign additional resources or adjust the MSPs other priorities.
Process project from Step 2:
Assignment.
Review history once per week to confirm that member has not provided the
necessary information and that proper follow ups are in place.
Project is on Hold
If communication with the member is not happening, contact the MSR to whom the follow up is assigned and the support team leader to let them know the project needs to be brought out of hold but communication is not happening.
