I am currently working on an SAP implementation project that is just starting its realization phase. One of my first tasks, as a member of the technical implementation team, is to review completed functional specification documents for RICEF objects. These documents, written by functional subject matter experts, are supposed to detail business requirements that address gaps, and which need to be incorporated into the system being implemented. The purpose of the review is to make sure that the functional specification documents are complete, accurate, and contain the approval signatures required to move on to the technical design phase.
In my career, I have had the pleasure of working with some first-rate functional analysts who know how to draft an excellent functional specification document in a timely manner. It is this type of performance that helps to move a project along in the right direction, on schedule, and within budget. Likewise, I have had the not-so-pleasant task of working with not-so-first-rate functional analysts, who draft functional specification documents that are not clear, inaccurate, and incomplete. The risks here are ultimately manifest as project delays and cost overruns.
A really good functional specification document contains enough detailed information about the business process to enable a technical designer to use it as the foundation for drafting a complete and accurate technical design document. The functional specification document should not only highlight the presence of a gap, but should demonstrate how the business process, accompanied by automation, will close the gap. This document must also indicate the abnormal processing requirements – what should happen when that report or interface does not run, what are the recovery steps, how are key employees notified of the problem, etc. The content of a functional specification document must be tuned to the flavor of the RICEF object that it is describing. Since they perform very different tasks, a report specification document should be very much different from an interface, conversion, enhancement, or form functional specification document. Using functional specification templates helps to insure the appropriate content for each type of RICEF object.
I am sometimes astonished by the sparse content that is actually offered up for review. “We need a report” really does not tell me a whole lot about the business process that I am supposed to automate. Nor does it even hint at the report purpose, content, layout, user interface, execution mode, authorization requirements, or error handling. And likewise, “Build me an interface” does not even begin to describe the direction, payload content, mapping, frequency, error handling and recovery steps. It would be so wrong for me to attempt to build a technical design on such meager functional definitions. One of my favorite cartoons shows a development manager standing in front of rows of programmers saying “You guys start coding. I’ll go and find out what they want”.
I am further astonished by:
a) the project managers who apply pressure to accept inaccurate and incomplete functional specification documents, to give the impression that the project is actually moving forward and making meaningful progress.
b) the functional analysts who whine incessantly when their paltry functional specification document is not accepted.
A functional specification document that does not meet expectations must be upgraded until it does. But bouncing a functional specification document back and forth like a ping pong ball between the functional team and a technical reviewer is inefficient and wasteful. I find that the best way to quickly firm up a weak functional specification document is to thoroughly research all of the issues that I found in the document, formulate proposed solutions where possible, and then schedule a face to face collaborative meeting with the functional analyst and the business process owner(s). This type of collaboration can save hours, days, or even weeks of wasted ping-pong posturing, and that is always best outcome for the project.
This face-to-face quick resolution scenario typically cannot happen if you have an off-shore technical contingent in play. In this case, it is absolutely imperative that the functional specification document be most accurate and complete to mitigate the risk of excessive time loss. Why is that?
Off-shore resources are sometimes time zone shifted eight or more hours ahead of where the project is located. If a functional specification document is released for review, it will not be analyzed until we have left for the day. If the off-shore reviewer has questions or raises issues, we will not see these questions or issues until the next day when we arrive at the project site. When we respond to the questions or issues, the off-shore team will not see our response until we have left for the day. And so on.
Under these conditions, a poorly written functional specification document with issues takes days instead of hours to resolve. This leads to unnecessary project delays and cost overruns.
That 3PL interface, which was scoped and planned by the business process owners as a single RICEF object named “The 3PL Interface”; and for which only one interface functional specification document is written, is actually many RICEF objects. We need to move purchase orders, inventory receipts, advance ship notices, inventory picks, and cycle counts between the two interfacing partners. Each of these represents a different payload, different mapping, is triggered by a different point in the business process, has separate error handling and recovery procedures, and requires a separate RICEF development object.
That single enhancement functional specification document, which addresses all of SD pricing, has the potential to extend into many different user exits. I just finished coding an ABAP proxy that was functionally specified as one interface. In fact it was four. The requirement was to search the database for sales and invoice data starting with either an invoice number, sales order number, customer name, or company name. Each of these search techniques required the development of a separate method. The only pieces of code that were shared among the four search techniques were the input parameters and the output return table.
The point here is to make sure that the project planners understand the real complexity and effort required on the development side, and to make sure that the project plan and budget reflects these more realistic metrics. This really goes a long way to stop everyone from wondering, “It’s only one interface! What is taking development so long?”
So what is a reasonable set of expectations for a really good functional specification document? What is it that we are asking the business analyst to do?
First, let me describe what I do not expect. I do not expect a business analyst to write code, build tables, design efficient database retrievals, or to decide that one BAPI, function module, class, or IDOC is better than another.
Here is what I do expect:
A clear definition of a business process that is repeatable, and which actually works. As a pre-automation test for data conversions, I always require the functional analyst to manually enter one of whatever, using the standard SAP transaction for which a conversion program is to be built. Many times, they can’t because the system is not configured correctly, the supporting data is not present, or any number of other reasons which cause the transaction to fail. An interesting observation is that there is much indignant huffing and puffing during this manual entry “test” process. But when the manual test fails, I simply remind them that I cannot automate a broken or non-existent business process.
A clear definition of what should happen under abnormal or failure circumstances. This must include error handling, notification, recovery and reprocessing steps.
A business process that can efficiently be automated. Requiring a search of sales order header text for the phrase “This is a red order” is a very bad design for automation purposes. While such a design is technically possible to build, it will certainly be inefficient at run time, and may not always produce all of the red orders. This is because the key value is a free-form phrase that can and will be misspelled, and abbreviated, along with countless other mutilations of the key phrase “This is a red order”. There are much better business processes and technical implementations that will more efficiently and more accurately find all of the red orders in your system.
An explanation of the need for development. Exactly what is the gap, and how will automating the business process close the gap?
Screen shots from SAP transactions depicting data that is to be retrieved or stored. From the screen shot in the transaction, I can usually determine the exact table and field in the SAP database. Note that some business analysts are very adept at identifying the actual underlying table and field name.
Clear and concise details with respect to data mappings, formulae, data transformations, conditional processing, etc. If I come to an intersection and it is unclear whether I should continue to go straight, turn left, or turn right, then the functional specification document needs a bit more detail behind it.
Design a separate functional specification document review checklist for each flavor of RICEF object. Distribute these checklists to the functional specification writers so that they know what the expectations are. Using a checklist will help to make sure that your review process is consistent and accurate. Improve these checklists over time. My Form functional specification checklist document now includes the following check:
Is it physically possible to print the specified content on the specified form using the specified font style and size? Was an actual printed mock-up provided as proof?
– but only after I had received a functional spec for a form that required four inches of print content on a one inch label. And somehow, the business analyst who wrote this particular request erroneously thought that it was my problem to solve. After all, writing code is magic! Isn’t it? In this case, I pushed back and insisted that an actual printed mock-up be produced – one that I would then agree to automate.
A good functional specification document will help tremendously in moving a project forward in the right direction with minimal cost and risk. A poor functional specification document has serious potential to cause project delays, and schedule and cost overruns. The best goal for the project is to achieve a good functional specification document, using whatever means required.
Mike Salvo consulted with DataXstream from 2006 to 2011. He remains a valued team member and mentor. For current information regarding Mike Salvo please visit his Linkedin profile.