Kelly's SN implementation Blog Post #15

[kellykaufmann]

So this is one last catch-up post that comprises of a few weeks. But a big few weeks!

In the past few weeks, a break was taken to attend & participate in Knowledge 15! Was really nice to meet some of the SN PPM team in person, and all the great current & upcoming PPM users. That was the most beneficial for me was identifying some people a few steps ahead of our implementation and picking their brain on how/why they did their PPM setup the way they did. Since Knowledge 15, I already got some project status code shared with me from one of the presenters and had a good brainstorming session on Waterscrum. I'm so appreciative of everyone's willingness to share! If you attended Knowledge 15 and have access to the Knowledge 15 content, here's a link to my presentation.

In digging into Project functionality so I can do samples for my How-To & training deck, we really started 'kicking the tires' and identifying a few more things to set up or change in PPM (some are pretty major). In no particular order:

'Schedules' in Project:

For the first time, I started digging into how 'Schedules' work in Project. Since I never saw the 'Schedule' field on the Project form, I guess I kept forgetting it existed. It seems behind-the-scenes is a schedule titled 'Project Management Schedule' automatically applied to all PRJ's. Basically here is where you define work days/hours, holidays, whether project tasks can take place on weekends, etc. Out-of-the-box, 'Project Management Schedule' is set to have work hours from 8-5 M-F, so you can't schedule a task for a weekend if go-live is to happen that weekend - you have to create a 'Child Schedule' entry that says that tasks can be scheduled for x weekend. Cool stuff.

Here's what we tweaked:

• For the existing Project Management Schedule, we made it so it no longer pulled in the Child Schedule 'U.S. Holidays', and instead created a '2015 Company Holiday' Child Schedule.
• Pulled in the 'Weekends' schedule as a Child Schedule of the 'Project Management Schedule'.
• Made it so PM's can pull in other schedules as Child Schedules.
• Make it so PM's can delete Child Schedules they created.
• Set up a 'Copy' button that copies the 'Schedule Entries' and 'Child Schedules' content into a new Schedule and brings up the copied version for people to immediately edit.
• Granted Schedule access to anyone with the PM role.

Here's our plan for Schedules with projects: We taught our PM's that if they need to schedule project tasks to take place on a weekend (e.g. go-live weekend) or if they want to define a holiday calendar separate from the Corporate Holiday calendar, that they will need to create a schedule. If not, they can skip the Schedule activities. If they do need to define a unique Schedule for their project, they go into Schedules, go to the Project Management Schedule and click the 'Copy' button. They provide a new (very obvious!) name & description for this schedule, then create a new entry 'Child Schedules' for any weekends the team will need to work and therefore that you will need task scheduled on (e.g. go-live weekend). This way they aren't messing up the master Project Management Schedule, and they can have as complicated a schedule as they desire for their project.

Project Workbench:

Our Internal SN Admin made it so all the Agile forms in Project appear/function the same as we had set them up to function in SDLC. So we're turning off SDLC! We'll exclusively use Project Workbench for Agile efforts.

We're figuring out how we are going to use the 'Team' functionality. You need to select your team & sprints when creating the phase, or know your limit in functionality until you do such. We're wondering if we should (A) use 'team' as designed knowing we'll possibly need to set the team a bit prematurely, so we can use certain functionality, or (B) just have one team (e.g. "Bunzl Agile Team" and have all phases auto-default to that team, and hide the field. We're small and don't have to use this team field, but are working through scenarios with both options to figure out which will work best for us.  

We think we're experiencing something funky with time zones…. after 4pm each day it won't let us create a 'phase' for the same day (wants to do the next day). We also experience some funkiness after 4pm with hours rolling up. We're looking into if this is a time zone thing in our Schedule (we have our Time Zone set to 'Floating') or something else.

'Automatic' vs 'Manual' calculation for Project Schedule:

The last time I had tried using SN's project schedule functionality was back in the Calgary/Dublin days. At my current employer, I didn't try yet in Eureka as we weren't ready to dig in, and then the Fuji upgrade opportunity came, so I really started digging into the project schedule functionality in Fuji. Coming from implementing ACA at health insurance & healthcare companies, I'm used to absolute fixed-date fixed-scope projects. I kept encountering challenges in creating such a project schedule in the Calgary/Dublin versions. SN has since fixed how rollups work, and they went an extra step and created a calculation type of 'Manual' for the project schedule (in addition to the 'Automatic' calculation type which you still have complete control over whether a task is a fixed date task or 'Start ASAP' type task). This Manual type basically says 'back off' to any auto-changes that would otherwise happen to header tasks/phases etc. After deeply deeply testing projects using 'Manual' and 'Automatic' calculations, we realize we can manage both self-calculating project schedules and fixed-date schedules effectively using the 'Automatic' calculation. So, after we had added a 'Calculation' field to the project form, and had deeply broken out the functionality of each in the training, we're getting rid of this field and leaving 'Calculation' default to 'Automatic' and just teaching how the 'Automatic' functionality works. Of course, I'll still share with you all my findings from both types.

'Defect' functionality in Project:

In experimenting with Defects in Project, we discovered that after creating a defect related to a project task, when the defect is Closed Complete, most of the project task fields are protected (the only ones we could edit were the Assignment Group and the Assigned To). So you can't enter notes on the task, can't close out the task, etc. So our Internal SN Admin made the defects to calculate manually by default which would mean it will not roll up to project tasks, and she unprotected the fields. All is good in the Defect world now.

'Milestone' functionality in Project:

Built-in SN functionality is that a task is automatically marked as a milestone if the task's planned duration = 0. The calculation is 'End Date' minus 'Start Date' (note: MS Project is 'End Date' minus 'Start Date' +1….there is no +1 in SN's calculation). When you mark a task as 'Closed Complete', SN takes the 'Actual Start Date' & 'Actual End Date' and has these dates override the values in the Planned Start Date & Planned End Date fields. Good to know!

So we have two concerns: One is that an effort that takes 8 hours all on the same day will show a duration of 0 and therefore be a milestone, since it's missing the '+1' part of the formula. The second concern is with the actuals overriding the planned. Will keep thinking about this.  

'Open' vs 'Pending' logic in Project:

For a project with the 'Automatic' schedule type, when a predecessor task State is marked as 'Closed Complete', the successor task State will automatically change from 'Pending' to 'Work in Progress'. We think WIP means someone is actively working on it, not that the task is ready to be worked on. So, we changed this logic so when the predecessor task State changes to 'Closed Complete', that the successor task State changes to 'Open'.

Last Task logic in project schedule:

We had to make a decision of whether to keep the current functionality in place of closure of the last project task automatically closing the project, or teaching this functionality and guiding teams on having a proper final task like 'Confirm project readiness for closure'. Some teams were used to having their own team project schedule with tasks that ends at Development. Needed to remind everyone that each team doesn't have their own project & project schedule for a cross-area project in ServiceNow - they use the same project and each team enters their tasks into that project's schedule.

Additional Changes in Project:

• Ability to log Defect against a Requirement.
• Ability to tie 1+ task to a Requirement, and in Requirement to see related tasks.
• Ability to add notes to a requirement, even after the requirement is approved > Actually just unlocked all the fields. Don't need these locked down, as there is a log.
• On Defect form, show the 'parent'.
• Ability to see Stories in the 'Project Tasks' tab.
• Tweaked the Decision Log fields/form.

Concern:

Project tasks can be worked on & updated before the project's 'Start project' button is clicked. Once the task 'state' is progressed beyond 'Pending', it automatically puts the project as started, and if the task is completed and has a successor then the successor task state is auto-changed to WIP. You can't add a predecessor for a task that is started. We're thinking through our options: We can lock down the project task form for projects not yet 'started'. We can trigger an error message when someone goes to update a task for projects not yet 'started'. And we can train people when creating reports of tasks assigned to them to add a filter to filter out projects not yet 'started'.

Other Phase 3 Updates:

Our 'Phase 3' is Asset Management, CMDB, Change Mgmt Lite, Release Mgmt, Resource Mgmt, and timesheet & time reporting functionality. We're having our Internal SN Admin implement all the Change Mgmt and Release Mgmt requirements & timesheet/time reporting changes. We had our internal SN Admin get Change set up last week. This week she's focusing on more Project changes. Next week she will set up Resource Mgmt and timesheet/time reporting.

Next steps:

• Do Waterfall Project training later this week for one group. More Waterfall Project training will be in 3 weeks with another group that needs timesheet & time reporting functionality in place before they can start using project. Agile training is still being developed as we're still tweaking that functionality.
• Next week set up Resource Mgmt & timesheet/time reporting changes
• Continue rest of Phase 3

Later this week / next week I'll post our Waterfall project training materials & how-to. I had to start giving this documentation out internally even before it's finished, because many teams wanted to start using Project. This was a surprise to me that they were so ready, but was a good surprise! They got to test my documentation & ask me questions that I can incorporate in the training.