THE IMPORTANCE OF SCOPE IN A QUICKBOOKS ENTERPRISE PROJECT

Our QuickBooks Enterprise projects are typically a different animal than, say, a Pro or Premier set up. Due to the larger database size, users to onboard, and functionality of the program, scope becomes a very important piece of the conversation.

Scope is a term that has circled the project management industry for years, and even though a lot of importance is put upon it in the ERP world, as you move into the small business environment it is easy for scope to become misunderstood and miscommunicated. This leads into scope creep issues, missed change orders, unhappy clients, and missed project opportunities.

What is scope? Scope, in general terms, is the description of what a project is needed for, and what is going to be delivered. Typically, there is a fine line between an overly granular scope outline, and a too wide one. According to CIO.com, “the definition of scope is the first step towards establishing a project timeline.”

I’m a prospective client. Why is scope important to me?

Clients should enter a QuickBooks Enterprise discussion with a clear understanding of what their project scope, from their point of view, should be, and should be prepared to discuss this with their KHB project manager or Enterprise Consultant. Knowing a 360 degree idea of what you believe your needs are invites an open conversation, and sets your project off on the right foot.

Some things that might affect the scope of your project include:

  1. Am I looking to purchase a software program with or without support help and implementation?
  2. Do I need historical entry, or beginning balances entered only?
  3. If I need historical entry completed, will I do that, or do I want KHBOffice to? How many transactions need to be brought in?
  4. When will my initial start date be in my new system?
  5. Do I need any other applications included as a part of this program?
  6. Do I need training help, on site support, or long term support help?
  7. Do I have a list of my critical needs, and my less-critical but still important pain points?

Knowing these things going in helps your consultant determine what your core system and project cost will be, what the timeline looks like going in, and where the risk is for project overages.

What do the answers to these questions mean to your Enterprise Consultant?

As QuickBooks Enterprise Consultants, we hear what you say, and it takes on new meaning within the project concept. Project implementations can cost anywhere from $800.00-$30,000.00, depending on the scope and needs of your project. Add in enough complexity, and you could even exceed the top range. While the average implementation comes in around $5000.00 with limited historical entry, we can adjust the scope of the project to fit your budget and needs. We can only do this with open communication, collaboration, and a clear definition on both sides of what the milestones and end goals are.

What are we asking from a project management point of view? Let’s look at these questions with fresh eyes.

  1. Am I looking to purchase a software program with or without support help and implementation? (Is this a purchase, or do I need include my services team on this? If we need services help, we need to give our services team notice as soon as possible of an upcoming engagement.)
  2. Do I need historical entry, or beginning balances entered only? (How many hours do we need to plan for and schedule on our internal workboard reports in order to make sure we are completely dedicated to, and stay on track with this project?)
  3. If I need historical entry completed, will I do that, or do I want KHBOffice to? How many transactions need to be brought in? (Depending on budget, can the client help with some of the formatting or data entry, or are they looking for a full-service implementation – what’s more important, budget or time?)
  4. When will my initial start date be in my new system? (When is Go Live? While this is mainly applicable to services projects, we want to make sure we have our finished project well in advance, with time for tweaking. We also want to make sure we are there for you if you have any Go Live surprise. Lastly, we want to make sure we have a month or so lead time before we hit the main stage.)
  5. Do I need any other applications included as a part of this program? (Do we need to pull in our Method specialist, our POS specialist, Enterprise specialist, or another one? Is this another program we need to implement? What is the scope on that additional piece, and does it affect the client’s overall project?)
  6. Do I need remote training help, on site support, or long term support help?
  7. Do I have a list of my critical needs, and my less-critical but still important pain points? (Has the client already made a list of what they need completed? Is there some additional need that they may not have addressed yet? Do they know what type of functionality and programs are available?)

While many times we can gather this information over the course of our initial conversations, your project will run smoother if you have a strong idea of your needs going in, while leaving room for open dialogue and discussion.

What happens if our scope changes during the project?

Change orders are typically the result of a vague initial scope, or one that did not have complete information of the final project; they can also be a natural evolution of the initial idea. Change orders, while a normal part of the process, can sometimes be avoided by outlining a strong scope to start with, and by making sure all information has been collected. Change orders can cause project delays, but they can also ensure that the end project meets your needs more than the original project would.

Another alternative is to create a phase dynamic. By implementing phases, your initial project becomes a phase one, and the change order could be moved to phase two, if it doesn’t impact functionality, and is not a critical change. More on phases in a later post. For now, just know that when we work with you, our objective is always to get to the crux of the project. That might mean a little more time upfront occasionally, but I promise it’s worth it in the end.