What's the plan, Stan?

[britta]

This is the second in my series about project management.

So, you've signed the contract and now the question is, “What's next?” Of course, you need a project plan, but you’ve never implemented ServiceNow before. What's the proper sequence of tasks, and how do you plan for dependencies? How do you make sure you’re not missing steps?  What resources do you need and for how long? How do I—

Whoa! Take a deep breath. Before you get to all that, some key considerations come first.

ServiceNow usually recommends a WAgile approach (aka Scrumfall) for project planning, where you create waterfall tasks with just enough detail to manage the work and major milestones. Then, within the time allotted for development, you plan for agile development using sprints. A WAgile approach allows you to have an overarching plan, but also the needed flexibility during development to zig or zag when necessary. Your ServiceNow journey doesn’t necessarily have to follow one prescribed direction; if you hit a roadblock in one area, your developers can oftentimes work on something else instead of halting all progress. The sprint structure of WAgile allows you that flexibility.

Next, how do you create the project plan? In my experience of performing 150 deployments with customers, I can count on one hand how many created a plan based on planned durations, level of effort, resource management—basically everything we’re taught with project management methodologies. 

Oftentimes, companies do not give project managers the luxury of planning the project and setting an end date based on data informed projections of how long the project should take. More likely the go-live date is driven by statements like, “We have to be off our existing system by December 31st when we drop off maintenance." In that scenario, the project manager needs to create a workback schedule to align with the preset go-live date.

For instance, how long do you need for a cutover and go-live? That kind of information should be in the leading up to the go-live date. Then factor in training and Organizational Change Management, User Acceptance Testing, etc.… until you get to the project kickoff date. As you go through this exercise, you will see if you need to condense and/or overlap some tasks to make the deadline.

However, over-condensing will not always leave enough time or resources to do things correctly. For example, I’ve seen organizations not allow enough time to collect, review, and get agreement on requirements. This rushing leads to subpar processes being created in ServiceNow or a "lift and shift" approach that leads to dissatisfaction with the product. The real problem is not enough time was taken to get the processes and requirements right. Some organizations then end up doing a "reset," thus adding more time and costs before they’re successful than if they had just allowed for enough time in the first place. (I'll have another blog on this later.)

Another way organizations often cut corners is by not involving key stakeholders during the design and testing phases. Companies think key stakeholders will slow down the process, and they probably will. But it’s better than rolling out training and realizing you missed key functionality or have misaligned to the actual process versus what you thought it was. Suddenly you’re in a crisis because you must fix it and have little time to do so. Also, you’ve lost the trust of your users because you’ve designed something that isn't meeting their needs, is making more work for them, and is causing other hiccups. Rectifying this mistake and regaining trust is costly and time-consuming. Or as sometimes happens, the issue doesn't get fixed and then the benefits ServiceNow can bring are never realized. It becomes a change just for the sake of change, which is not a win for anyone. 

Some team members will be in a post-purchase high, which can lead to overly optimistic goals for your first release. It's important to be realistic about your timeline and scope. As you get into defining requirements, you may find that you have more work to do in some areas than you realized. This is not usually a surprise, so try to anticipate these areas ahead of time and plan accordingly. Remember, creating a minimum viable product is not a crime. In fact, it's much better than rushing to get features in because it gives you the ability to iterate over time to create an awesome product.

The last common error I've seen in project planning is thinking, "Oh, if we get behind, we’ll just add more people." I'll write more about resourcing later, but Brooks’ law, coined in the 1975 classic The Mythical Man Mouth, still holds true: "Adding manpower to a software project that is behind schedule delays it even longer.”

In conclusion, it’s more important to avoid the above pitfalls than it is to have the perfect project plan. Rarely do projects complete without changes to the plan. The key is to have the appropriate governance to ensure that the changes are proactive not reactive. For more insights on creating a project plan, check out my project manager to-do list here.

[RussK]

you have just about nailed the head on what our experience has been like. An overstated Go Live and any things left untouched. I would have thought that as large as this platform is that there would be UAT documentation out of the box.  Oh your implementing this...here is your UAT to ensure success...here is your expected experience when completing this task. Not left up to the customer to design their own. Sure, they could design parts that are a result of customizations but off the shelf Id have thought there to be something contractors can supply customers for a better experience.