In cycling, one of the core concepts when you are trying to maintain good “form” is the maintenance of cadence. Basically, a cyclist is most efficient when the legs are spinning at around 90 to 110 cycles per minute. The idea is that for each pedal stroke, a certain number of watts must be generated to propel the cyclist forward at any given speed. If you pedal too slowly, your legs must generate more watts and thus will tire more quickly. Pedal too fast, and now you’re burning valuable energy but not generating enough watts. Somewhere around 100 cadence/RPM is about the point of equilibrium. You could spin faster, but you’re probably burning more energy spinning that fast. Any slower, you are pushing too many watts and fatiguing your muscles more quickly.
The same goes for so many HR projects. You either spend too much time getting the strategy done (low cadence, but you run out of steam) or you spend too little time on it (high cadence, but wasted effort). If you start with strategy, I’ve seen many projects spend 6 months planning, and then either run out of budgets, have organizations reprioritize, or have projects lose focus. There is a finite amount of strategic planning you can do before you have to get down to business. This is not to say that the strategy and preparation stops, this might indeed keep going, but real life practicality and the effort of the actual implementation has to start at some point. You can only plan for so much, and after a while the project dictates and determines the realities of your actions. Instead, what I often see happening is that some organizations plan so much, that they realize they are totally unprepared or incapable of implementing the desired course of action. Instead of planning “just enough” and taking bite sized chunks, they go in realizing that there are connections to their project all over the organization, and can’t tackle all the workstreams at once – in the end abandoning many critical paths. Many vendors call this “analysis paralysis.” Yes, there is a name for it because it actually happens more often than you probably think.
On the other hand, some projects spend almost no time planning. This is probably true of the great majority of HR technology projects. There is a brief determination of need, and then you go implement functionality. With this approach, there is much wasted effort as you allow the project to determine what your governance structure is, approach, how the organization connects dots between technology, process and service delivery. Rather than having a broad view in the beginning of the project, many organizations go deep too soon, and don’t realize that there are things sitting around the sides of the project that also need attention. Unfortunately, this is true of many vendor implementations. At the end of the day, a software vendor simply wants to get you to go live, and often there are issues that go on a log for later resolution, but once you’re live, many issues get put away never to be seen again.
I’d guess that the right amount of preparation for a normal sized software implementation is in the 2-3 months range. You do indeed need to figure out what your software approach is and how the project fits into the overall technology footprint. You need to figure out how service delivery in all aspects is impacted. And you need to figure out governance. Lastly, you need to have a pretty good plan of what you are attacking, when, how and with whom. If you have a larger ERP implementation, the planning process could be a bit longer. (Vendor selections not included in these guesstimates). At the end of the day, I think the story is simply that there is Goldilocks amount of preparation that is “just right” instead of not too much or not too little.