It’s a truism that in almost any development process it is very difficult in later stages to make up for what’s been missed or gone wrong at the beginning. Whether it’s a young person’s education, a job interview or a software implementation: a good start is essential. It is also widely accepted that getting the business requirements right is important for your SAP HR or SuccessFactors implementation.

So, let’s talk about defining requirements for HRIS implementations.

Well – we can talk about this later. Let’s talk about something more fun first: Aerospace engineering.

Imagine this aircraft manufacturer, who want to build a new commercial airliner to be the best in the world and beat all the competition. The CEO has this vision and asks the Sales Director to lead the project, because the sales team is close to the customer. The sales team is great: they really listen to their customers, the airlines. They also ask market research who work with passengers and key users – sorry: crew and pilots. They involve the corporate design team and the legal department. Eventually, they finalise the design with all features: speed, fuel consumption, carbon emissions, number of passengers, required runway length, price, you name it… And they have a huge 1:100 model made to present to customers.

It was a huge success. They brought 300 orders worth >10 billion Euros back from their first roadshow – all signed contracts with price, delivery date and of course a penalty clause should the customer reduce the order or the manufacturer fail to deliver in time.

/wp-content/uploads/2016/04/funny_plane_920529.jpg

The logical next step?

Call in the engineers and ask them to do the technical design and get it built.

Of course nobody in their right mind would expect this sequence to work. You can’t just make things up you’d like an aircraft to do and tie yourself into a potentially lethal contractual situation without involving the engineering and manufacturing teams right from the start, can you?! It will turn out that such a design simply can’t be made to fly – for all we know it might be closer to a submarine than an aircraft. And even, if it flies, it will probably be 3 times as expensive and take twice as long to be built.

It’s a no brainer, right?

So, why is it that SAP HCM as well as SuccessFactors consultants again and again and again find themselves in the situation, that requirements have been fixed to a scary level of detail (usually in some random places, whilst completely blank in others) or that business requirements are “still to be discussed”, but a deadline and budget have been fixed? And every attempt to change sth to make it feasible – or in some cases to just make it free of logical inconsistencies – is countered by the argument: “This has been signed off by the board/ the union/ compliance/...”

Think of your next HR initiative as an aircraft: you want it to fly

I must say that the situation has been improving in the last 10 years or so, but it is still happening far to often that the IT team responsible for implementing a solution is not asked before it’s too late to avoid fatal design flaws. I appreciate that HR teams suffer as much as anybody from people, who think they know their business (after all, everybody has been a candidate, attended a training, received a payslip and are therefore self-proclaimed HR experts), but when you start your next HR initiative, which will need some kind of IT to work, think of it as an aircraft. Sure, you want to check with the engineers to make sure it can fly before you sign anything. /wp-content/uploads/2016/04/ask_the_engineer_920530.jpg

Trust me: I’m an engineer 🙂

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Christopher Solomon

    Another great one and never so true as now! Can I say “been there, done that”? haha

    In the “good ol’ days” when I was consulting, I recall being pulled in for “non-billable time” on SEVERAL occasions to look over project bids and check any of those requirements and technical details for plausibility. These requests from the “sales guys” to help out came less and less as billable time/focus became more and more and project bids went out faster and faster…with most just falling back to some magical calculation of “well, this company is size X with Y employees rolling out to Z countries, sooo because we have done ‘similar’ for other clients, this project will take N time…..sooo FIXED BID!” Yep, more and more came down to “fixed bid” with that always lovely caveat of “…but we can always use ‘change orders’ for additional work that does not fit specifically to what we said”. Uggg.

    So after I went “independent”, I would say that 50-60% of my projects became “help us fix this project that we started and over-promised and now need to get back on the rails and keep the client happy”….seriously…I feel like the “cleaner” from Pulp Fiction more often than not. hahaha

    But like you said, all this can be avoided if both sides are open up front…and more than that….this NICELY ties into your other blog….if the requirements focus on the absolute process outcome and any key touch-points needed along the way while NOT getting down into the Nth detail of “how we get there”.

    By the way, I am not building planes any time soon. 😛

    (0) 
  2. Matt Fraser

    Echoing Chris’ comment here, Sven. You’ve totally nailed not just how implementation projects all too often seem to go, but how ongoing maintenance continues to go. We see this all the time: union leaders and HR labor relations management sit down to negotiate a contract, the contract is agreed to and the union and the board sign off on it, then requirements are sent to HRIS and IT staff without regard to best practices or technical capabilities, and often with the proviso of “this must be reflected in the next payroll run…”

    (0) 
    1. Sven Ringling Post author

      yeah – the frustration triggering this post was a case where the actual form for an appraisal system was part of the contract signed with the Union and then nobody would even dare to use round rather than square tickboxes 🙁

      (0) 
  3. Jelena Perfiljeva

    Great blog, Sven! Really glad I followed the activity stream here 🙂

    This might as well be applied to any SAP project, not only HR solutions. Just recently we barely dodged the bullet when Sales team (sic!) negotiated such an extremely odd arrangement that 3 departments had to spend days in the meetings trying to figure out how we could possibly process this in SAP. It was actually a relief when the deal didn’t go through. So lesson number one, children: don’t let the sales team lead anything! They are a bunch of professional liars. 🙂

    (0) 
      1. Sven Ringling Post author

        STop moaning. It’s not THAT difficult. It’s been done before with much less computing power than you have at your fingertips 😎

        (0) 
        1. Christopher Solomon

          …but the fine print of the contract says that no rockets of any sort can be used and there is no room in the budget for any sort of known fuel……but we can come up with some kind of fuel not discovered yet to then do the actual project, right? Easy. Think “very long ladder”…..get it done!

          (0) 
  4. Jarret Pazahanick

    Excellent and spot on.  Love your blogs Sven as many touch areas that are fairly well known but never discussed publicly and often the bad cycle never changes + make no mistake the customers are the one that ultimately suffer.

    Good consultants who are being hired to provide “consulting” make their customers (business and IT) aware and try to influence vs just “following and doing”

    (0) 
  5. Vasily Baranovsky

    It’s really the pain point for all of us. Thanks for sharing, Sven!

    I wish the next blog will be dedicated to your best experience how to organize estimations, requirements and sales for SuccessFactors 🙂

    And is there any space for the fix price outside the RDS approach?

    (0) 

Leave a Reply