Today’s post comes to us from board member Bob Clements. Bob understands what’s required to ensure that when you implement enterprise software, you’ll get the results you want.
Do you remember Mad Libs? You know: the word game where one player asks another for a list of words by type (adjective, verb, adverb, etc.) to finish a story that when read back is often hysterically funny but sometimes nonsense? I loved Mad Libs as a kid, and I am reminded of Mad Libs every time I start a new Human Capital Management (HCM) or Workforce Management (WFM) project to implement enterprise software, because software implementations are a lot like Mad Libs.
Just as Mad Libs provides the framework of a story that the players need to complete, the software license provides a framework of a solution that the project team needs to complete. The difference is that success with an implementation is measured by the ROI of meeting business requirements, which is considerably less silly (although arguably more rewarding) than the story produced by a Mad Lib.
Nobody would mistake the process of filling in a Mad Lib with writing a story from scratch, but IT departments do mistake implementing software with developing software. This is particularly evident as IT departments around the world adopt Agile as their project methodology.
If you are not familiar with Agile, it is a set of software development practices codified in methodologies such as Scrum, Kanban, eXtreme Programming and Lean Development. Hallmarks of Agile are daily stand-up meetings; short, time-boxed phases called “sprints” that end with working software; walls of Post-it notes known as “task boards” that contain requirements or “user stories”; a minimal amount of “Just Barely Good Enough” documentation; and small, cross-functional, self-organizing teams in which team members decide what they are going to work on rather than being directed by managers.
With Agile software development, products get to market faster and better meet the users’ needs with fewer defects at lower cost compared with the traditional waterfall approach. This makes Agile very attractive to corporate CIOs. The problem is that most IT departments do not develop software products; they implement them.
Because of its origins in software development, Agile, as described in most books and training courses, is not directly applicable to enterprise software implementations. And, most people feel like they are fitting a square peg into a round hole when they try to apply what they learned about Agile to their project. I have heard more than one project team describe Agile with adjectives only used in NSFW Mad Libs. There are several factors that make this problem particularly acute for HCM and WFM projects.
First, the requirements are complex and not well-suited to incremental delivery. Consider pay rules: a payroll or timekeeping system needs to support all pay rules that apply to an employee. Anything less and you will be getting a call from employment lawyers and/or the Department of Labor.
Second, WFM and HCM often depend on integrating data with other systems. Designing, building and testing integrations is time-consuming but required to go-live. Therefore, integration becomes the long pole in the project. On top of that, it is considered a best practice to re-test integrations anytime software is upgraded. In an Agile environment, this means that integration needs to be tested with every sprint. This is challenging from a timeline perspective and may be cost-prohibitive when it comes to procuring and maintaining the technology environments and staff needed to conduct the tests.
Third, because HCM and WFM systems affect most – if not all – of your workforce, it is risky to deploy new software to all employees at one time, which is often referred to as a “big bang”. Instead, the best practice for most enterprise-level projects is to pilot new HCM/WFM software to a small group of employees before deploying to the rest of the company in waves. Agile’s focus on delivering incremental improvements to software with each sprint forces project teams to either adopt a big-bang approach which is risky, or run several versions of a system which can be cost prohibitive.
There are elements of Agile that can be applied effectively to improve enterprise HCM and WFM implementations. For example, my company Axsium Group has incorporated iterative build-and-test cycles into our standard implementation methodology to improve user collaboration and reduce defects. Task boards are a great way to manage project tasks. We have also organized software roll-outs into iterations in which each iteration involves configuring, testing and deploying for a small subset of employees.
The key to applying Agile principles is to be creative about when and where they make sense. Doing this will enable you to finish the phrase in the above Mad Libs-style headline with the adjective “Best”.