
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
So over the last four weeks, we have been validating our workflows for the following roles:
1) All stakeholders - Idea generation.
2) PMO - Idea Triage
3) Demand Manager - Review complete demands - Demand Mgr and Portfolio Mgr will be the same person.
4) Portfolio Manager - Our IT business owners - Portfolios is where the majority of the demands and projects will reside.
5) Program Manager - This will be our Sr. Project Managers have responsibility for larger initiatives. We don't think we will have many Programs. We have
6) CIO - We kept the CIO dashboard naming convention.
7) Project Review Board - This is our Sr. IT Mgr / CIO / PMO team
😎 Project Leads - Could be a project manager or anyone in our IT group. We want everyone to understand that project leadership is just another discipline in anyone's job and to build our project-based culture.
Several other workflow based decisions
1) We have built our Portfolios to match our existing IT leadership alignment. We talked about aligning our portfolios to our business/service units; however, we want to match the way we currently manage our work. We have three portfolios:
a. Information Technology - This portfolio will address all the technical infrastructure components of our organization. Networks, Servers (Hardware, Systems, and Infrastructure), cyber-security (privacy), telecommunications, medical devices, anything that is considered a component of our technical Environment.
b. Information Systems - This portfolio will support all the non-clinical solutions within our facility outside of our Enterprise Health Record solution. These are the administrative, human resources, back-office financials, and service desk functions for our organization.
c. Clinical / Revenue Cycle - This portfolio will support the EHR, clinical operations, revenue cycle, quality, case management, analytics, and clinical research operations within our organization.
2) With our crawl/walk/ run strategy, we are limiting our use of financial(cost) and resource components of PPM in our initial deployment. We are "hiding" all the tabs and fields on our portfolio, program, demand, and project forms that pertain to costs and resources.
3) In our initial implementation, we are limiting the required level of detail in a project plan to only phases and milestones. We will not try to implement task management in our initial implementation. Individual project leads are free to develop task-level planning in PPM. However, we are not "requiring" that initially. We are requiring milestone/phase based planning and will use the "Key Milestone" capability within PPM in project and program management.
4) We are implementing our Service Portal where our stakeholders will be able to create Ideas. We have security groups already defined in ServiceNow, and we plan to limit new ideas to Supervisors and above. Anyone can generate an idea; however, they need to talk to a manager to formally submit within ServiceNow.
5) We agreed that we are not always going to follow the Idea / Demand / Project workflow. We agreed that we don't always need to enter an Idea. As well, we added workflow to "fast track" a project, we do expect that we will always have a demand record.
6) Agile vs. Waterfall - A key component of SN is the Agile 2.0 capability. We intend to utilize Agile phases within PPM Portfolio projects to allow for the executive and management reporting for Agile based projects. By doing this, we can create "Release" type projects that can be part of our PMM Portfolio and leverage our status reporting capability for executive updates. The work with being Agile based through Agile groups and sprints; however, the reporting will be through PPM.
Our Idea / Demand / Project workflow. Attached is our Idea / Demand / Project workflow. I borrowed extensively from a presentation presented at Knowledge 18 by the Loma Linda University Hospital. We are still working through a couple of questions; however, I believe the document is pretty good. I would be interested in other's feedback.
Testing / Use Cases
As I mentioned before, we are migrating to SN PPM from homegrown MS SharePoint based solution. When we built our initial site, we followed a similar Idea / Demand / Project workflow. Because of the similarities, we have been able to use all our existing system data as test data and handle cases for our validation with PPM.
For testing, we used the following:
• Portfolios - We set up three portfolios as described above.
• Ideas - We have developed 14 idea record to support the accepted idea to a validate demand.
• Demands - We created 31 validated Demands spread out within each of our portfolios. As stated before, not all demand records will start from an idea record. We took our Demand records through the full Draft, Submitted, Screening, Qualified, Approved, and Completed workflow
• Projects - We created over 40 project records across our three portfolios.
• Programs - We created three separate programs with both projects and demands assigned to our programs.
I have attached two files related to our testing and stories we have used. The files are:
• 21 - ServiceNow PPM - This is our standard project files that we are currently using. You can see all the stories I created on the "Stories" tab.
• PPM Decision-Analysis - This is my analysis spreadsheet. Yep, it has a lot in it; some will make sense, others will not. My test data and use cases are on the last two tabs. The spreadsheet is how I make my sausage, sorry it is not more organized.
As I have said, we are a small shop. We are finalizing our licensing for PPM. For our implementation, we are planning on having 15 planner and 40 worker licenses from PPM. We had an SOW for our initial PPM licensing and hope to get that signed this week. On the Setup-Roles-Master data tab in my analysis spreadsheet, there is a diagram on what the worker and planner licenses covers.
We also plan to leverage the Agile 2.0 capability within SN PPM. For task management, you will need a worker license for all users that update waterfall based tasks, however for Agile task phases, as we understand it, all ITIL user licenses can be part of an Agile Group and be assigned Agile tasks. We hope to extend PPM outside of IT, and we see the Agile 2.0 Agile Groups as a way to assign tasks to anyone in the organization.
Our next steps for our project:
1) Complete a PPM walk through with our IT managers.
2) Develop a PPM PROD migration task list
3) Load PPM to our PROD environment.
- 2,364 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.