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:
Workflow
Report
Interfaces
Conversions
Enhancements
Forms
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?
- 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.
- 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...
- 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.moy2 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.wenninger2 (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.
- SAP Managed Tags:
22 Comments
