It should come as no great surprise that one of the key factors in executing a successful ERP implementation is managing ‘scope’. (For the uninitiated, ‘scope’ is the summary list of deliverables that the project will provide at go-live. Scope’s arch-enemy – ‘scope creep’ – takes over when items are added to the original list of in a haphazard fashion, with no effective change control procedure in place.)
When ‘scope creep’ runs rampant, project resources – human and financial – are involved in developing functionality which is not formally a part of the project. This, in turn, causes project timelines to be extended and budgets to be exceeded.
Obviously, then, we should try to avoid scope-creep at all costs. So, how do we accomplish this? If you google ‘scope-creep’, your search will dredge up an unimaginable number of articles on how to maintain scope, or, conversely, to limit scope-creep. And most of these articles list several strategies for doing so. In my opinion, however, scope-creep can be controlled very effectively by adhering to one strategy: conducting a detailed “requirements gathering” exercise.
REQUIREMENTS VS. SCOPE
Before going any further, let’s talk about the relationship between ‘requirements’ and ‘scope’.
Simply put, “requirements” are the list of ‘things’ that the project has formally agreed to deliver (by way of a “Requirements” document) to the company’s user community. ‘Scope’ is the list of steps that the project will carry out in order to deliver these requirements.
As an example, the ‘requirement’ may be to provide an ‘order status report’, which would show where exactly in the supply chain the company’s orders are. However, to deliver this report, you may need to develop connectivity with each of your vendors’ sales systems so that you can receive the necessary data, and you may also need to build a database to store and report on the incoming data. These would be components of ‘scope’.
With this in mind, we can now turn to what constitutes an effective requirements gathering exercise. In a nutshell, you should keep 3 things in mind:
- Don’t “See an Elephant, Shoot an Elephant”: It stands to reason that the more ‘requirements’ you have for your project, the more complex, expensive and time-consuming it will be. Therefore, make sure you develop a ‘requirements list’, not a ‘wish-list’. This is not to say that you shouldn’t solicit opinions from across the organization when compiling your list (in fact, I would encourage this), but not everything can make the final cut. The initial list should be reviewed by Subject Matter Experts (SMEs) and senior executives in order to ensure that all the requirements are actually ‘required’ and, furthermore, they align with the overall project strategy.
- Select Your MVP: MVP – at least in IT circles – stands for Minimum Viable Product. In the early
stages of the project, you should endeavor to deliver only the MVP. This means you should deliver a solution with just enough functionality to meet the basic business requirements, and nothing more. Any ‘bells and whistles’ should be left for another time. - Rome Wasn’t Built in a Day: Just because a requirement doesn’t make it onto the list the first-time around doesn’t mean it’ll never make the list. However, your ‘Phase 1’ list should be reserved for those items which will render the greatest benefit to the business and/or which can be delivered with little stress. The last thing you want is for your ‘Phase 1’ to be a disaster, as the project will lose all its inertia, and you may find it’s very difficult to get it back. Therefore, chose requirements that can deliver significant business value while posing minimal risk to the project.
CONVERTING REQUIREMENTS TO SCOPE
Now that you have established your requirements list, you need to design a scope document which will ensure delivery of these requirements. While simple in concept, this can be a very onerous exercise. You will have make solution trade-offs because of cost, consider the schedule impacts of any solution you choose and ensure that the solution – once delivered – can be supported as you expect.
Therefore, do not rush through this project phase. Ensure that all the scope components necessary to deliver your requirements have been captured and properly estimated. Missing one of these components could have significant project impacts – impacts which may not be able to be managed within the current timeline or budget.
CHANGE CONTROL
It would be naïve to think that just because you have done a through job of capturing your requirements and scope components, there will not be changes to either your Requirements List or Scope Document. There are many circumstances which arise during a project that can cause one – or both – of these
documents to change. The key is to manage the change, no matter how small.
Therefore, at project outset an effective change control process needs to have been agreed to by all stakeholders. Every change should have its rationale, cost and impact reviewed by a Change Control Board and only after the change is formally approved is it accepted into scope.
My final comment in this regard is to beware of ‘death by 1000 cuts’. I have seen many projects get into trouble because they promoted a culture where ‘small’ changes were implemented without being approved. (“C’mon, Tim buddy…it’s a really tiny change and won’t impact anything. Not worth the effort of taking it to the Change Control Board!”) Therefore, the importance of properly managing change needs to be constantly re-enforced with the project team, in order to keep this type of culture from manifesting itself.
SUMMARY
Over the course of my 20 year+ career of involvement with ERP projects, there are a few ‘rules for success’ that I have come to live by, and effectively managing scope is one of them. And in my (sometimes not so humble) opinion, spending significant time identifying requirements and marrying those requirements effectively to scope is an exercise that will pay huge dividends later in the project.
