A few weeks ago we blogged about S.T.A.R. - a way to assist in preparing for a 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 quick sand of software implementations - once you are in it, the more you wiggle, the worse it gets. Eventually you risk of 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 benefit 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 benefit 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 prioritize when needed and stay 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 prioritization 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 build 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 timeline. Many customers ask 'how long will it take and how much will it cost'. The typical and also honest answer '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 InstantTM for our friends from NIBCO in the U.S. http://www.novigo.com/en/client-success. On the other side of the equation are implementations that take over a year to 18 months until 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 require 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'.Back