Skip to Content

E-form project pitfalls: 5 reasons why projects over-run

Customers choose Forms Lifecycle Manager(FLM) in addition to SAP Interactive Forms by Adobe for its run-time functionality for serving forms and managing forms processes, and also because of the decreased development time required for forms processes.  However, in some circumstances we see e-forms projects over-running, leading to a greater-than-anticipated implementation effort.

In this blog update I discuss what makes forms projects take longer than planned, describing 5 reasons that we’ve encountered at customers, and tips on how to address these issues.

1)   1) Infrastructure


Before embarking on an e-forms project, we ensure that the underlying SAP Netweaver system is at the appropriate software version and service pack level, but there are several other pieces of the jigsaw to put in place to deliver production-ready processes.

In some cases, smaller customers who manage their own infrastructure are better placed to overcome issues than larger customers who tend to outsource part of their IT systems: It can be beneficial if core desktop products such as Adobe Acrobat Reader and Microsoft Internet Explorer are centrally managed and delivered, as this ensures that all users are on the same software version.  However, if a change does need to be made to those products to support an interactive forms process, then such changes need to be delivered in a timeframe that supports the project plan.  We have seen customers who can deliver an e-forms project in, say, 6-8 weeks, but who can only upgrade desktop infrastructure like Adobe Acrobat Reader in a 6-month timeframe.

On the server-side, the service packs of the SAP Netweaver ABAP stack, SAP Netweaver Java stack and the Adobe Document Service (ADS) component all need to be kept in line.  We have seen examples where a form process works correctly in a development system, but stops working when migrated to a ‘QA’ system.  This can cause great problems if the migration is planned to occur at the start of User Acceptance Testing, and if ultimately the problem is related to a mismatch in SAP service packs.  So it is important to have a stable service pack inventory across the SAP system landscape throughout the duration of the e-forms project.  We have seen an example where the SAP Basis support is outsourced to a third party, with responsibility to provide timely upgrades, but that group is divorced from the e-forms project rather than intimately involved.

Another example involved a project in which a solution was delivered and tested in a small number of weeks, but then it took many extra months to perform some simple portal configuration in the production system, because that system was protected and could only be managed by a third party who worked with a prioritised backlog of changed requests.

Other parts of the form solution that have been impacted by similar problems include:

  • E-mail gateways/firewalls.  For example, if they are configured to prevent documents containing script this will stop the off-line forms scenario.
  • Standard SAP Single Sign-On functionality.  This requires knowledge of BASIS and SAP Enterprise Portal configuration.  Sometimes customers struggle to bring together this expertise for the initial set-up.
  • Web-service configuration.  This can also involve BASIS team if those web-services require authentication (in which case a Single Sign On ticket should be used).
  • Managing system authentication when there are multiple SAP back-ends should involve central user management, so any users who are to participate in forms processes need to be managed.
  • Managing the system authorisations of the new or existing SAP users may involve access to forms through SAP Portal plus back-end access for Administration staff.

These types of infrastructure issues are all surmountable, but can lead to delays if disparate teams or third parties are involved, because it can take many meetings to explain the requirement / issue and agree on the solution.    In the worst cases this has taken six months, or has led to a re-design of the forms process in order to consider the current technical constraints.

  • If part of your IT support is outsourced then involve the outsourcer in the project.
  • Review planned BASIS projects when planning the project to understand any dependencies.
  • Thoroughly review internal technical constraints before and during the solution design.

2) JavaScript


We use JavaScript to control the presentation logic or simple calculations or data manipulation – for example, following a web-service call, within the form template.  In many cases this is very simple but we have found customers getting stuck when they try to build in such presentation logic.

The need for JavaScript code has taken some customers by surprise, particularly because this comes as part of the form template design, which is largely non-technical. 

The issue appears to be that ABAP developers are not the best people to design the look and feel of the form template, and so the Adobe LiveCycle Designer part of the project can fall to other consultants who are not developers.  This means that they have to learn JavaScript on the job, which inevitably means that the form template design takes longer.

Further, ABAP developers may not be the best people to develop in JavaScript, since it is a very different language to ABAP.  And so there can be a knowledge gap in customers which means that their technical team needs to learn JavaScript skills during the form project.  And this takes weeks, not days.  Often this training cost and time is not included in the project plan.

  • Plan for JavaScript training if required
  • Plan for JavaScript development
  • Ensure the requirements for presentation logic and client-side calculations is captured and is well-defined.

3) Unstable Business Requirements

Clearly if business requirements change then this has an impact on any IT project.  When this happens to an e-forms project there appears to be 2 causes:

  • During the project, the customer realises what is possible and asks more of the form or form process.
  • The e-forms project is part of a larger project, and the design of the larger project is not set in stone when embarking on the e-forms part of the project.

During times of large-scale business change, customers sometimes look to e-forms solutions to help deliver some of that business change.  However, we have encountered situations where the business requirement is changing more rapidly that the forms solution can be designed and delivered, which has led to unmanageable project costs.

In cases where the underlying SAP application configuration is changing, the best approach is to delay the form design until the requirement is stable.  Of course this can be difficult to manage politically if there’s a ‘hard’ delivery date.

  • Begin form process design after any related configuration changes are set in stone 
  • Delay the form development process until the overall design is signed off.

4) Missing Project Management


Given the fast development time of an e-forms process using FLM, there can be an underestimation of the amount of project management required to deliver the finished solution.

Implementing a new interactive form means introducing a new electronic business process into the company.  This can involve real change management, finding a best fit solution to conflicting business demands, managing development and Basis teams, etc.

A form process that takes 8 days to develop may reasonably take 4 months to implement. 

However, we have seen customers who appear to underestimate the degree of process design or business change, or who perhaps view a forms project to be a softer IT project and a good learning environment.  They have provided project managers with inexperience, or without internal political gravitas, or managers who are already fully occupied with other projects.  All these scenarios represent danger signs for an e-forms project.

When project management is missing, the initial project plan looks smaller and therefore cheaper.  However, when the management is missing then the project can get out of control, decisions left unmade and timelines severely compromised.

  • Plan for the same amount of project management you would need when implementing a business process change or new business process

5) Technical constraints


E-forms can be ‘served’ to users in many different ways, and your particular set of requirements and constraints may lead you down unexpected paths.

For example:

  • For businesses with a highly distributed workforce, working ‘outside the firewall’, an ‘off-line’ approach may be necessary.
  • If form processes are to be initiated by non-SAP users then a pre-rendered form solution may be appropriate.
  • When FLM is being used for SAP outputs like reports, documents (such as employee contracts) or outputs like invoices or purchase orders, then a triggering program is required, and the form may need to be generated from SAPGUI and viewed within SAPGUI.
  • You may already have an intranet or a portal or 3rd party solution such as an organizational mapping solution from which you need to launch form processes.
  • You may have form processes that require a degree of interfacing to SAP during form entry. This might typically involve multiple web service calls for search functionality.

This variety of approach means that businesses are using e-forms in different ways, even for the same business processes: At a technical level, a timesheet process for one company may be very different from a timesheet process at another company, despite the business process appearing to be very similar.

If the technical approach is not understood and finalised very early in the project this can lead to project delays since those different technical approaches require different degrees of design and development effort.

  • Take time at the start of the project to review technical options for the deployment of forms processes 
  • Ensure you understand any infrastructure and development requirements

E-forms Everywhere

SAP e-forms, involving the strategic combination of Forms Lifecycle Manager and SAP Interactive Forms by Adobe, provides an end-to-end solution to develop, deploy and manage e-forms.  Those forms simplify the end-user interaction with SAP business processes in on-line, off-line and mobile scenarios. 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.