“Why do we use the ‘funnel’ icon to symbolize filtering?” and some practical filter-funnels you can use to reduce project spillage. #TheCTOBlog ep3

Initial “shower thought”: I want to start this article with a preamble to the main topic. As I am sure you know, the globally-accepted symbol in Office, Database, ERP and CRM applications for filtering data is the infamous ‘funnel’ icon … and this has been the case for many years. What you might have missed, though, is the fact that a funnel, by function, does not doing any filtering whatsover: it only slows down the rate of flow in order to avoid spillage but it doesn’t somehow remove things from the stream! So my question is: how come the funnel was adopted as the universal symbol for filtering?

After “further research”: The answer might lie around the fact that the icon is aspiring to portray a “filter-funnel” rather than a normal ’empty’ funnel. So there you go, today I thought you why the funnel symbol is used to symbolize filtering. However, if this preamble topic is of deeper interest to you, you have to continue researching it on your own as that was not the main scope of this blog-post.

Finally, the “main topic”: There are many books, papers and articles concerning ERP/CRM project risks and how to mitigate them. These can be found both on the world wide web and in books gathering dust in libraries to be picked up only by the random student who needs to do some research for an assignment, a paper or a dissertation.

While, of course, all major theories presented in such media are mostly correct and based on years’ of experience of implementing I.T. projects and researching statistics about project failures and successes, none of them use the metaphor of “filter-funnels” to mitigate project-risks plus I would like to use this article as an opportunity to present my “personal-experience-based” opinion on some handy, practical, down-to-earth (but by no means exhaustive) tips about how to make I.T. projects less risky. I am also (maybe wrongly) assuming that the more traditional project-risk-mitigation textbooks and articles are only consulted when preparing for a college, university or Prince2 course exam and rarely opened and consulted right before a project starts. On the other hand, this article is being published on LinkedIn, where these days, most tech people spend their professional online time so there is more chance that someone actually consults this article before embarking on a project. 😉

Filter Funnel 1 – “Is the project really needed?”

For the sake of the sustainability of implementation partners like ourselves, hopefully the answer to this question is always a big fat YES. On a more serious note: there are various objectives or sub-objectives a particular project might want to achieve such as GDPR compliance, reduction of data duplication, better valuation of a company from an investors’ perspective, automation of process through reduction of manual work, ‘going paper-less’, going to the cloud and thus reducing the risk of hosting infrastructure and struggling to keep the lights on … and a variety of other reasons.

My practical tip here would be to ensure that before embarking on an ERP/CRM project, the organization, together with the implementing partner should embark on an exercise of Business Process Re-Engineering (BPR). This means that the current business processes and business processes should first be fine-tuned and optimised before trying to implement a new system. Granted that such operational processes might be further optimised during the implementation of the system (for example get rid of manual paper-based data input) but a new system is not a magic wand or magical medicinal product that will cure all the woes or inefficiencies of an organization! As the traditional I.T. saying goes: “Garbage in : Garbage out”.

Filter Funnel 2 – “Is the project properly scoped and properly staffed?”

This tip will be more practical than the first one as I have encountered it multiple times in various projects I was involved in during my career: and it is not even about the traditional trap of scope-creep, which I will not go into here.

It is more about:

  1. Setting the right scope size – sometimes I see very eager business owners or project sponsors who want to do a lot in a short time and cram as much functionality as possible in one business release. The usual justification they use is that “our current business process relies on all of these functionalities being available to us, even if currently provided by legacy or disconnected apps so we must have everything implemented with the first go-live”. While this premise sounds good on paper, it significantly increases project risk
  2. Using the right business application to support a business function – Simply put, this means that you should implement a business application for its intended purpose and not have it behave as something else under disguise. For example once I was asked to develop, test and deploy ERP functionality (complex invoice calculations and matching payments functionality and synchronize the data to the ERP system) within a CRM system in order to have a lower count for ERP licenses which are costlier. Needless to say, it was a winding, up-hill road to get this functionality behave as it should and in a usable state. Do something like this to increase the risk factor of your project! Avoid like the plague if you want significant risk reductions.
  3. Have the correct functional skill-set – I was involved in projects were professionals with a CRM background were tasked to implement a solution or train end-users on ERP processes and vice-versa! While it is expected of most consultants to be well-versed in both ERP and CRM processes since most modern platforms have these two tightly integrated, it is simply too risky to cut corners and mix and match skill-sets. Nowadays, almost all projects require a very diversified skill-set so if your implementing partner does not have all the necessary skills in-house, they should be honest with you as a customer and both parties should agree to let in other partners who have the necessary skill-set to join the project. For example, in the Microsoft eco-system, Microsoft encourages Partner-to-Partner relationships and makes it possible for multiple partners to be recognised for their contribution to the same project or customer.

Filter Funnel 3 – “Is the project under-mined by hidden agendas”

It is easy to guess what this point is all about: politics. From my experience I have seen two types of agendas which greatly under-mined projects and increased risks substantially:

  1. Personal Agendas – A specific person (or persons) are not interested in the project being successful and adding value to their organization but are more interested in what they can gain from the fact that there is a project running. The rationales for such behaviours can be various but a few I personally experienced are “If I prove my worth on this project I will look good and get promoted”, “If I make the other project members look bad, it will reflect well on me”, “If the project takes longer I can bill more hours”, “If the first phase goes well, my contract will get extended” and many other exotic justifications
  2. Organizational Agendas – Rather than being a specific person who has a specific hidden motive, an organizational hidden agenda is one where the employees (or a well-sized sub-group of employees) of the company are resistant to change, either due to the fact that something is going to change (which can be mitigated through change management) or because they are scared that if the project is successful they might lose their job, have to relocate, report to someone new, change their daily routine, etc

Practical tip: the quicker you purge these hidden agendas and rid your project from them, the lesser the risk of spillage!

Filter Funnel 4 – “Is there good communication between the various functional teams?”

Sorry for being blunt but it really pisses me off when it is not present. So first it is decided to embark on an ERP project integrated with CRM to have a fully-integrated system with one consolidated business database, no data silos, no data duplication and seamless end-to-end processes but then the functional teams implementing the project still work in their own functional silo without keeping a continuous feedback loop with other functional teams within the same project. When this happens, it does not only increase risk but also greatly increases inefficiencies and can lead to major disasters so it is very important to have someone keeping the bird’s eye view and ensuring flowing communication between the functional teams. This should happen both at the project management and solution architecture level. After all, you do not want to be like that cop who commits a crime he/she was duty-bound to prevent in the first place!

Filter Funnel 5 – “Are you sure you want to extend or customize?”

This simple yet very risk-averse rule is most often over-looked and many project implementors or customers fall into the trap of over-customizing a tried and tested system before actually starting to use it. The more you extend, customize and develop the more risky your project becomes, the more testing is required to have it validated and usable, the more maintenace and support effort is needed and it becomes more error-prone and knowledge-specific. Before approving an extension or customization for your system make sure you use all of the following filter funnels and try to come up with a few on your own over and above them:

  1. Am I using the right product for my requirements and my organizational size? (or is the little devil trying to convince me to go for the product with the cheaper licensing and then solve all the big gaps with customizations?)
  2. Is it really a customization or can the gap be solved by configuring the system in a smarter manner?
  3. Can I re-engineer my business processes or re-train my staff to avoid a customization?
  4. Can I reduce risk by implementing a certified ISV vertical or accelerator solution which has been previously validated, tried and tested and is usually based on industry-experience
  5. If I really, really, really need to customize then I should only implement smart, lean and effective customizations, which are in line with paradigms in the standard platform (and, please, definitely not aligned with what was previously done in the old system !!!). It should also be properly managed using a modern version control system and properly documented.

I sincerely hope my filter funnels help you reduce risks on your upcoming ERP/CRM projects!