Why I think Technical Specifications should be made simpler

The other day I had to make an enhancement to the MIGO transaction in SAP.

MIGO is used for Goods Receipt – Goods Inward Posting etc.

The client wanted to default some values into the standard SAP MIGO Screen.

After some searching around I implemented a BADI to get this into the system. On testing, the solution worked out quite well. So we were ready to move it to QA for testing. All this while no one ever bothered to know how it was actually done. Finally the code passes QA testing and is ready to move to Production.

This is where things get nasty.

Where is the tech spec for this” says my PM.

Off course over the years I have learnt ( sometimes the hard way ) the significance of documenting ones work. So I always make it a point to update a Technical Spec even if the company practice does not require it. ( yes some cost cutters would simply skip it ).

So I hand over the updated Tech Spec to my PM.

AND …….. my PM is not happy. 🙁

Well here is what I had in it in the Technical/ Development Section.


  • BADI MB_MIGO_BADI is used to edit the Line Items of the MIGO.
  • I have created a custom implementation of this BADI and named it ZIMP_PM033_MIGO_BATCH
  • In enhancement Z_ENHC_PM033_MIGO_BATCH The method LINE_MODIFY of the BADI is then implemented in class ZCL_IM_IMP_PM033_MIGO_BATCH
  • The following code is added here.

CONSTANTS lc_matnr TYPE matnr VALUE ‘FUEL PURCHASE’.
FIELD-SYMBOLS <fs_goitem> TYPE goitem.

ASSIGN cs_goitem TO <fs_goitem>.
IF <fs_goitem>-matnr EQ lc_matnr
OR <fs_goitem>-matnr EQ ‘000000000000000282’.
<fs_goitem>-charg = <fs_goitem>-ebeln.
ENDIF.


Yes these were the exact words in the spec and I think this is enough for any developer to be able to refer to this guidance and be able to add to it incase the client comes up with a newer requirement in the future.

But for my PM.. well NOT HAPPY.

“How can we give this spec to the client” he says.

Yes and I think in my mind —- True you cannot give this spec to the client.  But sadly you realize this so late in the development cycle.


What is a Tech Spec

A Technical specification should ideally be the first thing one should write up before even touching the system to start development. Technical specification actually tells in as plain (technical terms) the implementation strategy the program is going to follow. What tables are going to be read, what Function modules are going to be touched and how the data will be displayed.

Once that is done, you usually walk this thru with the Functional consultant or the business user based on the design, get an approval, address any concerns and then set out for development.

In doing do you actually design the whole program in your brain and download that on paper.

In the earlier days of full fledged implementations Technical Specification documents were separate documents compared to Functional Specifications.

However in the recent years Functional and Technical Specifications are merged to make a Design / Development or whatever named document. I have no objections to doing this. But what I have objections is – is to that fact that there is hardly any time allocation done to this activity.

Current Project Management Scenarios work as Business User Gives Functional Consultant some requirement. Functional Consultant just puts it on paper ( in an old template which the company had some where ) and passes it on to the Technical guy expecting the Technical guy to know what the functionality is supposed to work like.

Technical specifications are now an after thought… which are supposed to be written after the work is done. And I for one forgot my old practices and followed the newer way and wrote up what I did.. rather than what was supposed to be done.


So coming back to my original predicament, after having received feedback from my all knowing PM I started a 9 yard tech spec writing competition which for me is like a biography of an enhancement program, which I swear in its entire lifetime will hardly be read by a single soul. After all When was the last time you ever read a technical spec in the fullest ?

So here is what I think about this whole Tech Spec thing.

  1. In this Facebook and Twitter age — People don’t have time to read big and lengthy essays.( You reading this blog is a surprise to me .. 🙂 )
  2. Tech Specs should be long enough to contain the major gist of what is being done but at the same time short enough that they don’t become a pain for your team to review and understand.
  3. The main ingredients like the custom program name, BADI name , Class Name etc and specific areas of the code should be more than enough.
  4. If your developer cannot understand a basic Tech spec like the one I wrote above, then I seriously doubt the abilities of such a developer.
  5. In fact the next time if you are interviewing someone for a Technical position in SAP, I would recommend asking them to read the above spec and asking them to explain exactly what the developer has done in there. If the candidate cannot explain it out loud to you….. Don’t hire them. They are no good.
  6. SAP Development has come a long way from the early days when very few people knew ABAP or understood it. So really there is no place for such excuses any more.
  7. Most People ( particularly Project Managers ) get confused between a Functional and Technical Spec. A Functional Spec explains the need for the development and what functionality is required in the development. The Tech Spec on the other hand spells out exactly what technical strategy has been implemented to achieve that functionality.

Does this mean I think a full blown Tech Specs is a useless thing.

Off-course not. I do not intend to undermine the requirement of a true Tech Spec. They are required, yes I seriously think they are. Imagine yourself trying to put together an IKEA Chair without the instructions. Ha ha.. not possible. Yes Tech Specs are important.

But just like every thing has a time and a place full blown Technical Specifications are necessary when you are developing an entirely new concept, Program or some complex enhancement, which has a potential of being touched by several developers/teams during its course of development span.

For Example, I worked on an Data Conversion Module, where data was being fed by a Third part software and was being picked up by an ABAP program and would be passed out to the PS module and finally feed into filenet. This is a complex requirement and may spawn multiple objects.

Such a requirement justifies spending more hours in documenting the solution in various phases. During Initiation, Adding the Basic Algorithm, figuring and spelling out the various data objects , the program may touch etc.

But such programs really fall in the rest 20% while most of the 80% development/enhancements really don’t justify the elaborate tech spec ritual and a simple, to the point, what needs to be done and how it will be accomplished is what is necessary.

I rest my point here. If you think otherwise.. I would like to hear your view point.

Feel free to comment on this topic.

 

2 Comments

  1. Nitin Tiwari

    Great Blog Linkin. Thanks for sharing!!

    I do agree with your suggestion.Tech Spec is a very important document mainly for Technical team.It should be clear enough with all required technical changes which would be helpful for developer to do the modification later.

Leave a Reply to Nitin Tiwari Cancel reply

Your email address will not be published. Required fields are marked *