A few weeks ago we blogged about S.T.A.R. - a way to assist in preparing for an SAP Transportation Management implementation. S.T.A.R. stands for Scope, Talent, Approach, and Realism. Over the next few blogs, we will explore the individual elements of our S.T.A.R. model - today starting with Scope.
Scope creep - the nightmare of any project manager. It represents the quicksand of software implementations - once you are in it, the more you wiggle, the worse it gets. Eventually, you risk drowning in a combination of pure effort, budget overruns, timeline delays, and overworked project team members.
On the other hand, you could have the best scope definition in the world for a project, however, you lack talent and the right approach (read: methodology), the project will still fail or struggle mightily. That is the point of S.T.A.R. - the overall success of a project depends on all the 4 elements working in unison. But let's put that to the side for the moment and dig a bit deeper into the scope element.
So what is scope in the TMS world? Many articles, blogs, and even White Papers and whole books have been written on the capabilities of SAP TM, however, the intended processes and scenarios in TM form just one part of a thorough scope definition.
TMS scope can generally be categorized into the following categories with a list of examples that by no means represent an attempt to show a complete list. And don’t forget to put items out of scope – sometimes equally important if not more important to maintain a negative list of items – you will appreciate it later.
Table: SAP Transportation Management Scope Categories
While the first three categories are kind of obvious it is critical that the benefits equation is kept on the radar during the early parts of a project. Although every project - before commencement - should have a project charter, the true scope very often will be refined during the Design or Blueprint phase. The Business Case scope shall be the guiding star during this exercise - when questions arise make sure that you go back to the benefits side of the equation to find arguments for or against including items in the scope.
Scope discussions become problematic when the business case is lazy - this means the case does not go down to a level of granularity that allows the project team to clearly align functional scope to business case expectations. The better the business case or at least the project charter defines the goals of the project, the easier it is for the project team to prioritise when needed and stays on track in terms of timeline and project deliveries.
So what should you strive for when it comes to a well-defined scope:
· Request a clear outline of the business case as the underlying foundation
· Identify project sponsor and business stakeholders early on
· Be prepared on the Basis/Architecture side
- never underestimate the effort on Basis, Interfacing, Mobile architecture. It matters in a big way. Avoid surprises deep into the project
· Assemble a detailed requirements list - the more granular the better. However, keep in mind that there is a tipping point where too many requirements will cloud the overall picture. Very rarely can someone read hundreds if not thousands of requirements in an Excel spreadsheet and not lose oversight
- an early prioritisation is an important investment that allows you to boil down the overall list
- too often have I seen Software RFP documents representing wish-lists that get thrown over the fence to the project team
· Have a picture in mind that will help to define the roll-out strategy. Rome wasn't built in one day, nor will SAP TM be built in one single effort/phase either
- of course, the experience of the implementation partner comes into play. The partner should certainly coach (or rather challenge) you in order to come up with the right approach
- Business Unit by Business Unit, Country by Country, Transport Mode by Mode, Outbound versus Inbound or probably a combination thereof will eventually define the roadmap to the eventual summit
A few thoughts on the timeline. Many customers ask 'how long will it take and how much will it cost'. The typical and also honest answer is 'it depends'. That is unless customers decide to go with template-based approaches that have historically been the safest approach to software implementations in the on-premise world. We will talk about Novigo's InstantTM template in a later blog.
Novigo has implemented SAP Transportation Management in record time - 19 weeks or 4.5 months with the help of Instant TM for our friends from NIBCO in the U.S. On the other side of the equation are implementations that take over a year to 18 months until the first go-live.
Like everywhere in life the truth for most customers will reside somewhere in the middle. 7 to 10 months depending on specific requirements - or in other words 'Scope'.
SAP TM is a highly powerful solution and platform. It can be tailored to an organization to a high degree of detail, therefore, unleashing tremendous benefits. Customizing or tailoring should not be shied away from, but be carefully considered. For the more conservative or budget-constrained organizations, the template-based approach is the right one. SAP TM provides amazing tools if you are willing to compromise on individual scope. Deploying standard scenarios also typically requires more Change Management as 'Get-Fit' activities.
To conclude a word of advice. Scoping a powerful platform like SAP Transportation Management is not exactly a science but a bit more of an art form. Allow trusted advisors to guide you on the journey. The more insight you give your advisors on the roots of your TMS journey, the better they will be able to lead you to the SAP TM promised land of 'Delivered on time, in scope, and in budget'.