The specification book in the ERP project – implementation of customer requirements

The creation of a specification book – a requirements and functional specification – is usually one of the mandatory tasks before an ERP implementation. Admittedly, creating these two documents is not one of the most popular tasks in an ERP project. They take up a lot of time and resources that are usually needed elsewhere. Time pressure or capacity constraints are often reasons for not creating them at all, or for creating them only very briefly and superficially. The consequences of this approach often become apparent later in the project. Especially for demanding ERP projects, you should not do without a functional specification. It will help you plan the implementation in the best possible way and minimize risks in the project – to name just a few of the benefits. In this article, you will learn why it makes sense to create a specification book, what it should contain, and what else you should be aware of.

Definition – what is a specification book?

The specification book is a document created by the contractor. In the case of an ERP project, this is always the ERP vendor. It is based on the specifications formulated by the client, in this case the customer or interested party, in the requirements specification. In a specification book, the vendor describes, usually in very detailed form, how it intends to implement the customer’s requirements. It contains a concrete description of the solution as well as a detailed work concept and clearly defined target states that have been agreed upon in advance. This document also defines the technical capabilities, functions and configurations of the ERP system that will enable these target states to be realized. In short, the “how” and “with what” is a particular focus when creating a functional specification. It is the “roadmap” for a smooth implementation and provides a framework for the entire course of the project.

In addition, the content of the specification book serves as a contractual basis for the collaboration between the customer and the ERP provider and has a legally binding status. It also serves as an acceptance criterion for the implemented ERP solution at the end of the project. As you can see, the specification book has a right to exist. The terms requirements specification and specification book are often used interchangeably, which often leads to misunderstandings and confusion. In fact, from a purely legal point of view, it is very important in which of the two documents something is recorded. If one of the two parties does not adhere to the previously agreed content, the customer and the ERP provider can always rely on the written agreements in the specification book. In this context, it is important to know that all previously discussed agreements between the customer and the ERP provider lose their validity as a result of the requirements specification, unless otherwise noted in it.

You may also be interested in:

The specification book – a guide for the customer
Why is a requirements analysis important?
Cost drivers of an ERP implementation

What are the benefits of a specification book?

A spec sheet is really used whenever there is a client and a contractor. It is especially helpful for very large projects. In addition to the legal security it offers both parties, it has three other major advantages:

Planning certainty for the customer and the ERP provider

Thanks to the very precise documentation of the target statuses and the necessary work steps, both the customer and the ERP provider know exactly how the project is progressing at all times. This ensures that deadlines are met as closely as possible. In addition, both parties know when the project is expected to be completed and can plan accordingly. But that’s not all – it also helps to keep an eye on the budget. Every adjustment has an impact on the cost, and this prevents it from getting out of hand. The client knows exactly what he is getting for his money and the contractor can calculate his expenses with certainty.

Transparent processes

The detailed written formulation of the solution approaches makes the entire path to go-live transparent. Everyone involved knows where they are in the implementation and what steps are needed to complete the project.

Fewer renegotiations

First and foremost, a well-developed specification eliminates the need for nerve-wracking renegotiations and discussions. As mentioned earlier, both the customer and the ERP vendor can rely on the agreed-upon items in the document at all times – anything that is not in the specification book is not included in the scope of delivery. A follow-up request is created for all subsequent change requests. Subsequent deliveries, changes, and scope creep – the uncontrolled growth of project requirements during implementation – are easily avoided.

You might also be interested in:

3 signs it’s time for an ERP change
Implementation with waterfall or agile ERP model?
Why does an ERP project fail?

Process – from specification book to functional specification

Typically, the customer or prospective customer writes the requirements specification, and the customer and potential ERP vendor discuss which items can be implemented and how in an ERP workshop. The prospect and the vendor go through the items together and the vendor determines whether they are included in the standard system or whether they need to be customized. The ERP vendor often provides advice on the requirements listed in the specifications. If a requirement does not appear to make sense, or if an additional feature or service would be more appropriate in this context, the vendor will usually make a counter-proposal. The specification book is usually written after the selection of the EPP and at the beginning of the implementation phase. At TimeLine, the specifications are sometimes created during the workshop or shortly after. The points discussed with the interested party are documented and summarized.

Typically, the project manager needs one day for each workshop day for follow-up work. The specification book ultimately determines the cost, i.e. how expensive the ERP project will be in the end. Although it is the basis for the offer, it does not mean that the order will be placed. At this point, other vendors may still be in the game. The prospect can then decide whether the competition may have made an offer that has more features or is simply a better fit for the company. Before the prospect makes a selection, changes can still be made to the specifications. Once the prospect selects an ERP vendor, the specifications become part of the purchase contract and cannot be changed. The prospect orders based on the specifications, and you enter into what is called a letter of intent.

What if the customer wants to make changes?

Especially in large projects, unplanned changes often occur during implementation. But if the customer wants to change something after the fact, the purchase contract changes as well. Each time a change is requested, the ERP vendor decides whether or not the item is still in the budget. If it is not, a second quotation or follow-up order is created. Anything that goes beyond the specifications is a follow-on order. Although the hourly rate remains the same, the customer is in a better position to negotiate if they order more services from the beginning and do not order additional features later.

How do you measure a successful implementation?

Licenses are reviewed with the customer after installation. As far as customizations are concerned, they are not reviewed once at the end of the project, as one might assume. It is more of a process that is done and reviewed on an ongoing and continuous basis, such as weekly or monthly. This is also feedback for both sides as to whether you are still on schedule.

You might also be interested in this:

What is an ERP workshop?
Why online presentations pay off
On-site ERP training – is it worth it?

Structure and content – what should be included in a specification book?

A specification book is used in a wide variety of areas, so standardization is simply not possible. There is no regulation or legal standard that describes what a functional specification should contain, what structures should be followed, or what a functional specification should look like in general. There are, however, various approaches – the following structure has proven effective in software development:

Introduction

It is always advisable to summarize the most important key data for an ERP project. Make sure that all parties involved are explicitly named and that the project is briefly described. Communication channels should also be listed.

Who is involved in the project?

Contractor and customer
Stakeholders
Project team
Contact person for questions or issues

Are communication channels listed?

What is the project about?

What is the end result?

Description of milestones
framework conditions
Definition of deadlines (completion, acceptance, deployment)

Any special features of the project

Project goals and non-goals

It should be clear that the goal of the project should be listed. However, there are often items in an ERP implementation that are somehow “docked” to the edge of the project. Therefore, it can be helpful to define the non-goals in addition to the project goals. By explicitly defining which areas are part of the project and which are not, discussions can easily be avoided. By formulating non-goals, the boundaries of the project become clearer and the “gray area” becomes smaller. In this way, you quickly gain clarity about what is “in scope” and what is “out of scope” in a project.

What will the project address?
What will the project explicitly not address?
What problems will the project solve?

Application and product environment

The future use and environment of the product should also be specified in the specifications. This includes the target audience, application areas, business processes that will be affected, and operating conditions.

Features

Make sure that all functions and use cases are described in detail.

How and under what conditions does the function work?
What is the impact on other business processes?

Services

The services describe the requirements you have for a particular function. For example, the execution time or the accuracy of a calculation. Make sure all services are listed.

Quality requirements

The quality requirements should also be summarized:

What are your quality requirements?
What does quality assurance, quality control, and quality acceptance look like?

To be more precise, it is useful to assign a quality level to certain characteristics, for example

Changeability = not relevant
Efficiency = good

User Interface

Basic requirements for the type of layout, dialog structure, or access rights should be listed here.

Other and special requirements

Dazu gehören zum Beispiel die Dokumentation, Buchführung oder Sicherheitsanforderungen wie der Passwortschutz.

Technical requirements

The technical equipment required for the implementation should be listed here. It is useful to list the software and hardware systems that need to be installed for the application. This is important, for example, to ensure the availability of the network connection.

What equipment do you need for what task?

Interfaces

All existing systems, products and interfaces should be listed here. This is important to be able to connect the product to all other applications. Are there already project-related systems and/or products that do not need to be implemented by the contractor?

Problem analysis

The most important problems and perhaps also those that are to be expected should be summarized here. A solution approach should be available for the most likely problems.

Project development

This item should describe as precisely as possible what steps are planned at what time and how the entire project is organized.

Testing and acceptance

Tests check the product for functions, features and quality before it is completed. If the product runs without errors, it can be declared complete.

What conditions must be met?

This is just an example of what a specification book can look like. Some criteria are essential, others are important but not critical. Still others are desirable but can be left out. Which features are “must haves” or “nice to haves” will vary from company to company. Just make sure they are clearly identified as such. The level of detail can vary, but the technical requirements should be described in great detail. Ultimately, it is important that the requirements from the specifications are consistent with the statements in the specification book and that there is no room for interpretation. The requirements specification should be well described and documented, leave little room for interpretation, be specific, and include a necessary cost estimate. As a rule of thumb, it should leave no questions unanswered and an outsider should understand what is meant.

What else should you be aware of?

From the customer’s point of view, you should first take some time to look at the specifications carefully and not just wave them through unread. Pay particular attention to the interpretation of your requirements and check that they have been implemented according to your wishes – simple, but it can save you a lot of trouble later on. In addition, there is always the risk that you will ignore the current situation in the company when writing the specifications. This means that you miss the opportunity to take advantage of the potential for improvement offered by the new system. Use the ERP project as an opportunity to take a critical look at your workflows and business processes – this will help you realize the potential.

From the ERP vendor’s point of view, it makes sense to invest some time in development, to coordinate in detail with the customer, and to leave nothing unresolved. If questions remain unanswered, if you are looking for an answer, and if there are bottlenecks, clarify this with the customer immediately. It is important to be as accurate and detailed as possible when writing the report. It is also a good idea to use plain language and avoid using technical terms. Many different people will read the specifications – not all of them will have a deep technical understanding. Graphical representations are also a good way to communicate complex content in an understandable way. Use diagrams, tables, or mind maps to visualize the customer’s requirements and make them as easy to understand as possible.

Conclusion

Creating a specification book is a necessary step in minimizing the risks of an ERP project. On the one hand, it serves to fulfill the requirements listed in the specifications and to plan the implementation in the best possible way so that there are no nasty surprises at the end. On the other hand, it helps to validate the implemented solution at the end of the project and to protect both parties. It is particularly important to know the difference between specifications and requirements. Legally, it makes a big difference which of the two documents defines something.

If you would like to find out more about requirements analysis, specifications and functional specifications or the full range of TimeLine ERP features, please send us a message using the contact form, write to [email protected] or contact our sales team at +49 212 230 35 200. We look forward to hearing from you and will be happy to advise you!