Blog

QueBIT Blog: 4 Ways to Keep your Project in Scope

Posted by Robin Stevens

Apr 12, 2018 9:40:00 AM

Project ScopeIf you’ve worked with an implementation partner on a project in the past, you know that it can be challenging to get the project done on time and on budget.  Clients often feel frustrated because they don’t feel they can control whether they stay on budget or not, since generally the software is new to them, and they don’t have all the information they need to control the project.  But, you, as a client, have a lot more control than you think!  This short post gives you some tips on what you can do to help your implementation team keep a project on track.

Before starting a new project, you probably went through the steps below:

  • You had a business problem – maybe it was automating planning, one of the more frequent business problems we address here at QueBIT.
  • You evaluated the options and chose your software.
  • You found a partner to work with to develop the model.
  • You put your internal team in place, you are ready to go!
  • You agreed with the business partner on the budget and timeline.

Now, you’re ready to start the project! What can you do, as the client, to keep a project in scope and on time?  I’ve listed my “top 4” below, in order of importance.  This list is based on observing client/partner interactions on projects for many years and seeing what actually works. 

  1. Participate

The #1 thing you, as the client, can do to ensure you have a successful project (not only on time and on budget, but also relevant and highly adopted) is participate in the development.  For a Planning Analytics model, for example, here are some key ways you can increase your participation:

  • Be ready for kick-off: for example, for a typical planning solution, collect together your key reports, sample month of trial balance data, key hierarchies like Account and Department, etc.
  • Learn the software—take a class, read the book, check out YouTubes, whatever it takes to get you and your team “hands-on-keyboard.” You’ll be much more able to contribute to the development process if you understand the software.
  • Engage in design meetings
  • Take a hands-on approach whenever possible, especially when validating data and building reports
  • Engage your IT staff from the beginning to ensure connections between systems is seamless

Note that this participation is general at a “user” level, not a “developer” level. Participating at a developer level requires more training and interaction time with your business partner, so it doesn’t save time, at least not in the short run. If you’re wanting to have someone on your team be at the developer level for ongoing model changes, you’ll want to budget specifically for that.

  1. Control Scope

Everyone’s afraid of scope creep. Have an honest conversation with your business partner at the beginning of the project agreeing that everyone is responsible for not added unnecessarily to scope.  Make sure the developers know that they should point things out that they think are out of scope. It’s perfectly normal to have some small changes—small changes should be part of the budget and accommodated during the project.  Make “now/later” decisions regularly—your model can be expanded later, and it’s often better to do that than to try to get everything done in one shot.  Discuss the scope regularly – deliverables may need to be adjusted to meet the project budget and timeline.  Everyone does their best to forecast accurately, but unforeseen things do pop up, so be flexible, and if something does come up, decide if it’s worth more time/money to add, or if it can wait until a later phase to get addressed.

Focus on getting your model into production, and into users’ hands (even if it’s just a few to start) by the end of Phase 1, so that you have a working model that you can use, collect feedback on, and begin to see the value of your investment in a short time frame.  You can always modify the model later to include more detail, more complex calculations, and, of course, you’ll continue to build reports and use the model for analytics.

  1. Small Teams

Make your project team small.  Large teams add time to development – discussions are longer, and decisions take extra time to make. If you need to collect input from a larger group, handle that internally (without the business partner), and summarize for your development team.  Have a “point person” (one for business, one for IT is generally good) to funnel requests, and to be the main point of contact.  The less time your development team spends herding cats, the more time and money you will save!

  1. Regular budget reviews

Your business partner should already be doing this, but make sure you review the budget regularly (on a 3-month project, weekly is a good cadence. The budget should be tracked by something measurable, such as task, or module, so that you can easily compare budget to actuals, and spot problem areas early on.

Sometimes, things come up that you didn’t anticipate, or, a piece of the model is more complex than originally scoped. What, then?  If you do need a change request, keep it as narrowly defined as possible in order to wrap up the project and get to production.  Keep it simple, and consider again what can wait until later. Once you’ve got your model in your users’ hands, consider an annual “health update” to check in with your developer, review what’s working, and what can be improved, in order to ensure your model stays relevant and up to date.

   

Blog Search

Subscribe to Email Updates

Popular Posts

Recent Posts

Follow Me