Implementation: Critical Success Factors - People
As we continue the discussion about the pillars that are critical to implementation success, this post will take a deeper look at the people involved in your project, their roles and some common challenges to avoid.
I think many of us have heard how important we are and the value we bring to a given project. However, having too little (or too many!) of the right skills when deploying a platform solution such as ServiceNow can lead to chaos, confusion and even in extreme circumstances a failed deployment.
While it has been my experience that you will never find the perfect project roster, I have noticed that if the one leading the project takes the time to fully understand the roles needed and works to fill these needs early, success is more common than not.
Understanding which roles are required to create a well-rounded and capable team is an important first step. From there you can begin the process of matching up individual skill sets with the roles for the most effective fit. The extra time up front in defining the "right" team will pay dividends in the long run, make success far more attainable and result in smaller, less drastic changes while a project is in-flight.
Project Attributes
Over the past few decades of my career I have come to face that fact that not all projects are created equal and for this blog I have chosen to focus on the more common mid-size project that contains approximately 5-20 customer and vendor resource combined. This type of project may span multiple departments and assumes that global processes are established before the kickoff of the implementation. In this post I will be focusing in on the resources provided from the customer side and in the next post I will focus on how ServiceNow can compliment that team.
Customer Roles
The list is somewhat elastic in that not all members are equally involved throughout the entire deployment but, they all share equally in the project objective; SUCCESS.
- Executive — Project Sponsor
- Program / Project Manager / Scrum Master
- Product Owner
- Subject Matter Experts / Process Managers
- System Administrators and Developers
- Trainers
- End Users
For example, while an End User may not play a role in the beginning stages of a deployment, they are a key stakeholder since success will likely be based on the users job being made easier not more difficult. Therefore, it is important to remember that the project measure solution effectiveness from many different perspectives; from the senior executive all the way to the front line service desk analyst.
Executive / Project Sponsor
The active engagement of the executive / project sponsor is extremely important to a project when considering resource allocation, funding and proper alignment of your initiative with corporate strategy and goals.
I have experienced projects where the executive was disconnected and the project suffered due to a perceived lack of support. Conversely, projects have had great success when the executive sets a positive tone from the start, displays their commitment to the project and clearly stating the seriousness and importance of the deployment. Having the executive attend bi-weekly or monthly steering committee meetings is a great way to quickly address any impediments that may be building and exposing them to the inner workings of the project.
Customer Program/Project Manager
In addition to the traditional project management activities, in an agile environment, it is important that this person expand their role to include the activities of scrum master. Maintaining the continuity of the project by running daily stand-up, review and retrospective meetings and keeping consistency and continuity throughout the team and project will drive to a successful implementation. The project manager should be committed to the project and work with the team on a daily basis.
Customer Product Owner
This is by far one of the most critical roles and often the most misunderstood. A true product owner (PO) is one that keeps the momentum of the project through daily involvement, setting priorities, backlog grooming, and making decisions that would otherwise result in a delay to the project.
On prior engagements, there are two issues I have observed relating to Product Owners. The first is when someone is named a "Product Owner" but lacks the ability to make a decision, is not actively involved or is reliant on someone else or a committee. This is NOT a product owner and results in the obvious delay or risk to the project.
The second issue I have seen related to Product Owners is the assignment of multiple individuals to the role and the potential for a development conflict. Sometimes multiple Product Owners are necessary on a multi-tired project, but there needs to be close collaboration between them and the Project Manager to avoid any contention within the project. I would suggest product owners be kept to their own individual work streams so tighter focus can be afforded to the active release. This in turn will also allow the team to focus on one subject area with one decision maker.
Customer Subject Matter Experts / Process Managers
Subject Matter Experts (SME) can come with a wide variety of knowledge about a particular subject. Some will be more technical and others more process savvy. No matter what variety you have on your team, the key to working with SME's is to ensure they represent the end users and have a good understanding of current technical/process short comings and are focused on overall improvement. A good SME will also look for ways to improve a process by questioning the status quo knowing that this may be the best chance they have to fix things.
Customer System Administrators and Developers
At the outset, there should be a clear understanding of how much your individual business requirements will drive customization to the ServiceNow platform. This knowledge will be invaluable for accurately assessing the scope of work to be done and confirmation that the developers assigned to the initiative have the skill sets necessary for proper completion.
In addition, training of ServiceNow System Administrators for post go-live support is an important issue to be resolved early in the project. This is especially true if the scope of the project includes large custom applications or the use of a high degree of automation. In many cases, automation is something that requires a solid understanding of JavaScript programming. Ensure that those charged with long-term support of the platform are trained, capable and well prepared.
Customer Trainers
It has been my experience that with most mid-to-large scale projects, internal training resources have been introduced to the project near the middle/end, when in fact they can play an integral role early on.
Deployments that have included trainers from the start have an advantage in that testing starts to happen sooner and could even be considered a form of pre-user acceptance testing as scripts are built to support the training curriculum. It would be highly advantageous to include the trainers in the kickoff and scrum review meetings so that familiarity and preparedness is a natural progression of the project.
Customer End Users
As with the training team, end users are historically the last to be involved with the project. And, in many cases, this has caused projects to miss their launch date as end users identify critical functionality that is missing or not operating correctly.
Early inclusion of end-user representatives in the project can provide tremendous insight and be an excellent compliment to the SME's that are already assigned.
This list of key players should be considered the bare minimum for a typical ServiceNow deployment. As organizations differ, these roles could easily be augmented with the addition of an enterprise architect or organizational change manager as the situation dictates. , but that is outside of the primary group that this blog is addressing in the typical deployment.
In my next post I will continue to build out the project roster expanding detail about the ServiceNow team.
8 Comments
