Skip to Content

Don’t hold your SAP Custom Development to ransom


Are your Custom Developments being held to Ransom like above?

Alternative titles for this blog:

SAP Custom Development is not a WRICEF

Lessons Learned from successful and less so Custom Developments

I hope you’re reading this in the not too distant future and wondering…”What’s a WRICEF?”…Because that’s how useful I think WRICEF’s are to anyone except to those creating contracts or managing projects and I believe (read as hope) their days in their current format are numbered.

So just for history sake, the name WRICEF comes from the definition of:







It is used on SAP implementations to work out how much work/effort is required from a development (& Conversion) perspective. It takes the idea that you can look at required functionality, and with the missing bits, just split the missing bits into individual specifications (which include functional and technical information), which you can define an approximate effort for, update the functional sections only, to throw over the fence to the differently skilled developers to magically produce an end to end business process (dramatised situation).

My favourite part is when you have functionality that depends on multiple types of specifications that either gets split up and becomes disjointed, or gets squashed into an incorrect specification type so it doesn’t get split up.

But this blog is not about the practice of using WRICEF’s on implementations, but why you should not take this approach with custom development. Another blog. Another day.

What is SAP “Custom Development”

In the context of this blog, custom development refers to the building of a non-trivial application within SAP. Typically custom development takes place when the standard SAP solution either doesn’t provide the required (integrated) solution or the standard solution is overkill to meet the business requirements. A very narrow definition for sure, but fit for purpose for this blog. 

It’s obvious right?

So you have a custom development requirement with possibly several screens (forms), lots of business rules (enhancements), maybe some data migration (conversion) and of course, what would a new module be without any decent workflow or reporting…

Yes – The most obvious thing is that splitting what could be quite a simple specification into several specifications with maybe a blueprint semi-holding it together is far from ideal so why would you do this.

But wait – There’s more!

Another unique situation with custom development is that either:

a) The business wants new functionality, but doesn’t really understand what is possible, so they focus on delivering the old system a new; and/or

b) The business knows exactly what they want but there’s no way they can tell you are delivering the right thing till they see/touch it, because that Blueprint/WRICEF specification is way too confusing with mostly techno-babble for them.

In other words, locking down requirements correctly for custom development before developing any part of the solution is usually* impossible.

* I’m sure there are many examples where this is not the case.

The key is not documentation but the Developer & the End-Users

I’ve been very lucky to be involved in several large custom developments (plus numerous small and medium ones too) in my career, and to a large extent, all have been pretty successful IMO. Because of this, I’m quite happy to recommend building custom solutions for SAP gaps within ERP (for example) rather than doing this outside of SAP for many gaps. That said, I’ve also seen my fair share of developments get scraped, avoided by users, not get delivered after lengthy delays, etc.; so I put a caveat based on this section.

So what were the differences between the successful and the less so you may ask?

  1. In the successful projects, the developers were involved from the beginning in the requirements elicitation; and had a direct relationship with the end-user/stakeholders. This lead to questioning (not just accepting) of the requirements up front to avoid complex to deliver requirements with tweaking of the requirements that still give the business what they want. It led to empathy the developer has for the end-user. It meant an open-channel for a developer without the developer needing to read documentation to ratify every requirement. Early prototyping where required. Continual validation based on a build priority to validate risky functionality. Trust from the stakeholders they are getting what they want, and understand if they can’t have something early. It goes on but what I don’t mention is a focus on signing off a WRICEF. There’s design thinking, and agility methodology factors all being leveraged without ever knowing there was a name for this approach, but to me, it’s more common sense when requirements are not 100% obvious.
  2. Custom Development is a skill-set not typically leveraged by implementation projects. I’m not saying a developer from several implementations isn’t capable of doing custom development but if a developer is not prepared to get in the face of the business and understand yet challenge their requirements (nicely) in order to build the optimal, simplest, but fit for purpose solution; or they can’t create low-res/high-res screen mock-ups, create sequence/class models, create ER models, know core SAP modules, know at least a few of the technologies at a low level, don’t know capabilities of SAP technology,etc.; then they are going to struggle a bit here. This leads to the next point…
  3. The less fragmented the development (and functional for that matter) ownership of the solution, the less chance that requirements are missed.  In one example, I’ve seen a very complex development farmed to large numbers of developers and treated like a typical implementation, but in reality, I believe a very small specialised team could have tackled the project faster, cheaper with far less impact to the business and built a much better solution. On small developments, hopefully a single developer is the functional designer, technical designer, developer and partially the SME after the project!

So what’s that last point got to do with WRICEF’s? Am I saying not to document?!

Well if the right people are not involved in SAP Custom Development or a unique approach is not taken, then you’ll be needing to create a set of WRICEF’s or a single butchered WRICEF, because that’s just the way it is done at many System Integrators. Good luck with that.

But if you look outside of SAP and look at how others implement custom development – Agile approaches, Design Thinking (albeit we’re not developing a unique product here so might be a rapid version of this), UML, BPMN (debatable), etc. – I don’t think the word WRICEF would appear anywhere.

Short form of documentation in this scenario could be (while still remaining a little SAP centric):

  • Documented business processes and business rules via your blueprint/BPMN (if you want to keep to that approach for consistency with the rest of an implementation but noting you’ll be continually updating it during design and build).
  • Ensuring you use software design modelling like BPMN/UML (my personal favourite are sequence models for use cases/scenarios when designing the object model and how things hang together).
  • And remember a picture is worth a thousand words so think about screen rendering software like iRise or cheaper equivalents (Visio,  pencil and paper, whiteboard, etc; to produce low and high res screen shots.

Future of WRICEF’s on Implementations (Prediction)

So with that, there’s a few reasons to do things differently with SAP Custom Development and not fall into the WRICEF trap. But let’s now have a quick look into the future of WRICEF’s beyond SAP Custom Development and into the implementation space:

Recently, a veteran and trusted ABAP’er (amongst many other SAP skills) Andre Oliveira referred me to some steps taken by John Moy at one place to make a dynamic specification that was more process/solution based. In other discussions with John directly, he has taken this further since then with Sascha Wenninger (and others) to use a Wiki based approach focussed on the need for specifications rather than capture all low level design detail (which I’m sure he’ll write about sometime in the future).  Whether this becomes the approach in the future, I’m not sure, but the key with both of these approaches are we’re talking end-to-end specifications and not bits and pieces of functionality. And that, is the future.

You must be Logged on to comment or reply to a post.
  • Hi Matt,

    Firstly, thanks for the mention πŸ™‚

    Secondly, I should add that the term WRICEF (also known in other forms, such as RICEFW etc.) is a throwback to methodologies and approaches from decades ago.  It is sadly perpetuated by (often) the larger implementers.  To me, modern day artefacts don’t fit well into the strict categorisation of those 6 letters.  I particularly don’t like that a brand new complex application with its own user interface doesn’t fit well against any of those letters (some may say that is an enhancement, but I don’t agree).  And in particular, the strict categorisation doesn’t necessarily promote concepts of reusable components, or layered development – instead it promotes developments being constructed in a siloed manner. That doesn’t mean you can’t redress that with good architectural governance – its just that the use of WRICEF doesn’t get you off to a good start, and works against good software architecture, not for it.

    With the Wiki-based approach you mention above, the relationships between software components is more strongly defined and promoted.  For instance, if you have a program that needs to leverage a re-useable component for application logging – you simply provide a link to the Wiki spec for the logging service in your Wiki spec for the program.  It promotes a sense that developments don’t exist in isolation.  They aren’t simply placed into one of six ‘buckets’.



  • You make some great points Matt, and those are also echoed by John in his comment. WRICEF/RICEFW is, as you both say, an artifact of what is increasingly becoming a sign of process-and-governance over focus-on-delivery.

    I think that many people who have worked with me know my feelings on outsourcing, and the total impedance mismatch between what is needed (quality and delivery) and the hallmarks of large outsourcing (or SI) organisations: WRICEFs, SOWs and even ITIL processes. For me, WRICEF is a ‘warning smell’ in any project organisation.

    It often seems as though “custom development” is still seen as something to be avoided, and that as well being used to (badly) derive component parts, the retro-categorisation of WRICEF is used as a way to (poorly) pigeonhole and account for elements of that development so that the “pain” can be quantified and accounted for. This is of course nuts.

    I am a fan of Wikis and really like the idea of Wikis being used to facilitate the process.


  • Thanks John and DJ.

    Firstly John – I don’t like the RICEFW version as why would you create an acronym that could easily be said in two syllables with simple rearrangement…So I try to ignore that variant but agree that is out there and just as heavily used.

    I also have fun dealing with enhancements that are forms and forms that are enhancements and reports that are forms, batch reports called interfaces, etc…Funny how the definition isn’t clear (and can’t be) to begin with to confuse the matter more.

    I like your point about the re-usability and linking within the Wiki, which usually comes down to good design and/or refactoring at the right time but having that capability is cool.  In my world, I just ask people to write common “specs” for design/testing that goes across multiple WRICEF’s (cheating the system a little bit).

    Now to DJ – I’m also pretty vocal but with a slightly different angle saying “it’s the people not the company that matters” (slightly more political correct answer now days from me since there are good people in all organisations if you can get a hold of them that challenge the status quo and do things differently) but there are definitely trends in some outsourcing/SI companies to stick to processes that focus on easy to track contractual obligation so it’s a battle for these people.

    And custom development being avoided – it’s a good principle, but with all principles, there are exemptions and in some cases it’s plain ridiculous. eg. Avoiding a common few-lines of code everyone does to stop pay slips being available to end users too early because it’s an enhancement is a classic example.

    To both of you, firstly, wiki’s are good but I worry about how to get people comfortable with this significant change (including the SI) as this seems to be always the problems with Wiki’s beyond certain types of people. Streamworks was an example of a great tool that I only could really get buy-in from other architect types as it was just too different for most users.

    And more importantly, I guess the underlying question is (since we all get it), apart from when you’re directly involved in establishing the project methodology, how do we influence these “contract based” outsourcing partners to change? I think there is a John Mayer song about that but I’m impatient.

    Thanks for your input guys!


    • Hi Matt

      I agree with your sentiment about individuals in larger organisations; in fact, my last experience with an outsourcing company was pretty abysmal, but what saved it for me were the few individuals who shone through. And even those that didn’t, it was (I suspect) because they were put in the wrong positions, at the wrong time. The problem lies very much in the process, engagement and contract management. That, and the underlying resistance (inability? unwillingness?) to keep a measure on quality as well as delivery*


      * I had a (home-made) poster on my desk that showed a picture of a rotting peach, with the slogan “Stop the Software Rot”. But that’s a story for another time.

    • Hi Matt,

      To be honest, I have been (positively!) surprised by the relative ease with which we have introduced a wiki for documentation at my (and John’s) client. 99% luck and really only 1% skill – we were very lucky:

      • First and foremost, culture! An ambitious, growth-oriented company staffed with IT management who were experienced enough to know the usual pain points about thousands of pages of outdated documents nobody reads, and cared enough to try to do something about. I shudder thinking about trying this sort of thing at certain companies!
      • A brand-new, highly visible SharePoint implementation of the intranet. This provided strategic endorsement ‘by default’ of the technology stack.
      • The timing to get a pilot up and running in the first few weeks after project kick-off, before anybody started writing documentation in earnest. So it was the wiki from day 1, and not something introduced later once the project had gathered momentum.
      • The fact that a SharePoint wiki, when looking through only one squinted eye from a distance, looks quite a bit like MS Word.
      • The awesomely awesome power of iterations: We were able to get version 1 of the ‘spec’ templates up and running in about a week, and tweak them as we started using the system in anger. Of course, we discovered new requirements, things we’d never thought of, things we thought would be useful but weren’t, etc…

      Still, it’s only early days. Even after ~6 months, many people still treat the wiki like Word documents. Linking content, dynamic includes, the use of tags, etc. still requires a bit of a nudge and a push.

      Can you tell I’m mildly excited about it? πŸ˜‰

      • Hi Sascha,

        What I like about what you’re doing is it’s challenging the status quo of how you do documentation on projects. We need more of this style of thinking where we show there are better ways.

        Definitely a session at Mastering or even ASUG is in order for how you go with this in 6 months time!

        In the end, it comes down to governing quality (nicely) I assume while everyone gets used to things.  With new approaches, you need to let every get to the point where they say – “I get it” and then it becomes standard practice rather than learned practice.



  • Oh, I just have to chime in on this.

    A while back, I wrote a piece on “How to write documentation“. My biggest nuissance with most technical (WRICEF) documentation is the fact that it focusses on one object. It doesn’t show the entire story. good to know that method ABC of class XYZ does this and that, but how does it fit in with the rest?

    In that sense I love the idea of using a WIKI for your project documentation.

    • you can have all your projects in the same WIKI (makes it easy to retrieve documentation of different projects)
    • You can cross reference. (you know, reuse objects of a previous implementation)
    • you can have a structure in your documentation: High level story -> break down into process -> process step -> objects in that step -> technical details of the object (9. Organize your document repository)
    • Documentation can be updated by anyone
    • You can create some completeness-reporting on it (or define some indicators)
    • because you can use a single wiki page for a single object, you can create a reference in the object help itself to the WIKI (put the documentation where it matters) (or vice-versa)

    I also want to bring the Business Process Documentation of the solution manager into play. It allows you to document your process in SolMan, linking it directly to the implementation itself.

    Looks like there’s no single ultimate trick to great documentation, but given the different options you have to achieve a decent level of documentation, there’s no excuse to come up with crappy doco. (except for budget reasons,… which is the worst excuse ever)

    • Thanks for the reference with some very good points, plus thanks for your wiki thoughts Tom. I do have to say, use of Solution Manager is another discussion yet again as I think the sentiment is you have to ram this down an SI/Outsourcer’s throat to get it leveraged and it’s a hard sell when SI’s say it cost more to do things better because they have no experience with doing documentation (well) in Solution Manager. FYI – I’m sold on many parts (not all) of Solution manager and it hurts me not having simple set-up in place to manage the solution documentation ongoing (beyond just words I’m talking about).



  • On our implementation it was called FRICE-W.  I was responsible for the C part, and even within that it was difficult, given the silo’s between functional teams. 

  • Hi Matt,

    You certainly put a valid concern about WRICEF. If you talk about only WRICEF objects for a project, it misguides you. The idea is each object is individual object but business processes, functionality namely big picture is not considered! 

    John importantly pointed out that reusable objects are not part of WRICEF. But a software/solution architect should design the solution based on re usability.

    Once I get a requirement or talk about WRICEF objects for the project, I ask people to explain the big picture, the goal. So finally – of course with follow up Agile methodology: design-develop-touch-feel circle – a new product is produced not an object!

  • On our implementation, we have had heated debates on which letter to use for an interface that can be used as a conversion that triggers a workflow that utilizes enhancements to produce a report.  Each letter had it’s own template for the specification.  We ended up with E; as the E template had the most flexibility.

    • Hi Mark,

      Finally all developments are E…! πŸ™‚

      Example: Let’s review WRICEF list. There is one WRICEF object: XYZ Interface. No sub items? But finally all analyzing shows that: It’s interface, conversion, configuration, workflow, ABAP development, etc… Namely multiple objects! So this is not a WRICEF object! It’s a small project in the big project! Or we can call it Product!

      So what about P?

  • Good blog Matt and I echo your frustrations – too often all those lego blocks just don’t quite fit back together and it’s more like the jigsaw puzzles my nephew used to do where he forced any half-likely looking piece to fit in whether it should or not – hilarious if it wasn’t so tragic.  

    But still it’s nice to see the W in it’s proper place out front ;-). 

    Here’s hoping that Design Thinking and Agile principles brings a little sanity back into how developments are grouped … but I may be being overly optimistic there.  So in the meantime I shall continue to create overarching this-is-how-it-all-fits-together docs on my projects. 


    • Good feedback Jocelyn, and good point about the overarching document as that is one of the ways I recommend to group these specifications and remove repeated sections like testing to bring back some sanity.  Funnily, people usually just see this as more documentation and not smarter documentation (again, hilarious if it wasn’t so tragic and true).



  • Hi Matt

    Thank You for your insightful post. Apart from not having a full overview of the project and where each custom development fits together I hate the thought of maintaining a spreadsheet for each WRICEF component.

    I however cant wrap my mind around how the documentation would be done in a Wiki. On the current project all processes are being documented in ARIS and from this a WRICEF spreadsheet is being generated. Also then how are the different WRICEF components tracked through the different stages and also estimated?

    • Hi Faaiez,

      Unfortunately, not really qualified to say how John and co are doing the Wiki work – though I’m sure it comes down to moving away from very rigid WRICEF numbers in the first place.

      ie. In my mind, people should be estimating against a solution or set of functionality as until you’ve got a configured system, and understand the latest features of the latest EHP from SAP; writing a WRICEF is more guess work and open to change so flexibility has to be key in terms of solution, though intent should be fixed so that scope does not change.