The first project manager I ever worked for as an IT consultant had the routine to randomly walk through the various open plan offices to observe which colleagues were sitting behind their computer and work in isolation. He made a mental note of those people who always work as a recluse. Those team members are likely not sharing information, and that would worry him. On the other side of the spectrum, those always in discussion with others would be praised as team players.
It is very common that people work in silo’s and only get encouraged when using the traditional waterfall approach for deploying new functionality. The key user writes the business requirements and hands it over to the consultant, normally with a quick hand over session. Then the consultant writes the functional specification and hands that over to the developer, who will write the technical specification. The consultant only gets the change to test against his functional specification when the developer finished the unit testing. Often the expectations will not reflect the deliverable, starting a lot of ping-pong interactions making it less likely to deploy the solution on time and within budget. Delay in deployment becomes even more likely when the key user finally gets the change to do the acceptance testing. You can expect new ping-pong debates between the key user and the consultant, triggering renewed chats between the consultant and developer.
You will realise that the missing collaboration between the key user, consultant and developer will cost the business a lot of money due to lost efficiency and productivity. Still, this waterfall approach is considered the best practice. No wonder why so many IT projects fail.
Business Rule Framework can introduce an agile rapid application development approach that can be used within a waterfall driven project. You just need to enforce dialog between the key user and the consultant. At the same time the consultant will use BRF+ to configure complex decision making instead of having that cumbersome logic coded by a developer.
When you have a powerful change manager in your organisation and the willingness to adopt best practice to good practice, then BRF+ allows you to get more done by the same group of people against higher standards. So greater quantity and quality.
Probably the biggest change in attitude is to use the powerful Business Rule Framework simulation capabilities to prototype the business requirements and make this part of the sign off for the documented business requirements. As complex decision making is the core deliverable for any business requirement, the key user and consultant can check whether the prototype returns the expected results in every known business case. If so, then it becomes very likely that the deliverable will pass acceptance testing without needing any further changes. This way the desired first time right objective is a realistic expectation.
As the decision making becomes configuration when using BRF+, the developer does not need to write a technical specification for that complex part of the overall deliverable. Instead, the consultant will inform the developer what input is required for BRF+ functions and what action is needed after returning the result. Collecting data for decision making and handling the result are relatively easy tasks for a developer to code, reducing the chance of mistakes. Also, the consultant and developer can work in parallel to configure and code the solution. Then they can sit together and unit test together before handing it over to the key user for acceptance testing.
Using BRF+ to become agile within a waterfall project can reduce the lead time for deployment with at least 40%, while the chance of fixing problems after deployment will be reduced dramatically.
Conclusion is that Business Rule Framework is not just a tool, it can be a game changer in delivering SAP projects in time, on budget and fit for purpose.
That makes BRF+ a vital ingredient of the Fast Implementation Track, as explained in my book “Make F.I.T. Your Purpose”.