The speed with which technology is reaching into every aspect of Human Resources is astounding. Once the province of enterprise-level organizations, HR tools are becoming more accessible to companies of all sizes and, just as interestingly, growing narrower in what issues they’re meant to address.
Startups are creating products to support real-time performance management, sourcing, productivity, rewards and even sub-sectors of those categories. New York-based Pymetrics, for example, uses neuroscience-based games to assess candidates’ cognitive and emotional strengths while using proprietary algorithms match them to ideal jobs. Glint, in Redwood City, Calif., gathers workforce data in real time to help employers more effectively manage their workforce in terms of both engagement and productivity. Meanwhile, more established vendors such as SAP SuccessFactors offer access to specialized tools through “app stores” integrated into their products.
Speed, Capabilities and Approvals
This growing variety of solutions presents managers both inside and outside HR with a challenge they may not be used to: Having to prove that a particular tool will achieve meaningful results at levels ranging from individual teams to the organization as a whole. Convincing your boss to spend money is never easy. Brand-name companies set up vetting and approval processes while the senior managers of medium-sized and small companies tend to have a direct bond with their money that goes beyond the fiscal year’s budget goals. That fact that there are so many tools appearing that use new technical approaches to workforce issues means making the case to invest in one more difficult. For one thing, new offerings can’t offer a bundle of case studies to prove their value.
This is why in today’s HCM technology environment, Discovery-Driven Planning is a good thing for those involved in the product-selection process to know about. Nicely summarized by Amy Gallo in the Harvard Business Review, DDP is a process intended to stress test and plan for projects “whose prospects are uncertain from the start,” in the words of the Columbia Business School’s Rita McGrath. She and the University of Pennsylvania’s Ian MacMillan first published the approach in 1995 and have added a few touches to keep up with the times.
McGrath and MacMillan wanted to develop a “disciplined process to systematically uncover, test, and (if necessary) revise the assumptions behind a venture’s plan,” Gallo writes. Even though DDP is primarily intended to help corporations avoid multi-million-dollar product disasters, it seems readily adaptable to the consideration of new HCM technology strategies and their implementation.
Five Steps
In their original article, McGrath and MacMillan argued that “conventional planning operates on the premise that managers can extrapolate future results from a well-understood and predictable platform of past experience.” But, as we’ve noted, new products and new technology applications don’t have track records to back up their claims. So, teams face the very real possibility that the assumptions they made at the start of a project may not survive exposure to new information, and plans may have to be significantly recalibrated even as the work proceeds. To address that, Discovery-Driven Planning follows five steps:
Step One
Define Success. This means describing in specific terms what a successful outcome will look like. Because the process was designed to be used in the product development world, this includes creating a “reverse income statement,” where you start by estimating the effort’s required profit-margin and then determine how much revenue is needed to deliver it. A parallel in the HCM world might be determining how much savings in time and money will be realized if a new onboarding process if put in place. For many executives, determining the return-on-investment of most any HR or learning effort is akin to the Holy Grail. DDP recognizes that you can’t always measure success in financial terms, Gallo notes. In those cases, however, you should still think in numbers. As examples, McGrath discussed “things like the number of users, size of the network, uptake of a new solution, and so on.” Adds Gallo: “Ask yourself, ‘what would need to be true to achieve the outcomes you are seeking?”
Step 2
Benchmark. This means give your definition of success a reality check. Do the metrics you hope to meet hold up when measured against other methods that already achieve the results you’re aiming for? The point is to see if you’re being realistic. The product-based example Gallo cites is of a chemical company that decided to diversify into high-end apparel because it had trademarked material that was already used in clothing. Benchmarking revealed that in order to achieve its goals, the company would have produce one out of every six pieces of clothing sold in the U.S. The company proceeded anyway, launched its products, and three months of losses later admitted defeat and dropped out of the market.
Step 3
Define Operational Requirements: Identify all of the activities necessary to implement the technology, roll it out, train end users–both in HR and the workforce at large–and support the tool. This means venturing outside of HR and working with IT to determine the resources it will require (additional networking hardware? A half-time DevOps specialist?), consulting with Training and Development on the cost of its efforts (will the training be classroom-based, online or through video?) and calculating the cost of lost productivity training will incur. Then, of course, you must total up those costs and measure them against your goals.
Step 4
Document Your Assumptions: If you’re not clear on what your assumptions are, you can’t be sure you’re making a solid decision. This is a team effort, so everyone involved should list all of the assumptions they’re making regarding what it will take for the project to succeed. For instance, IT may assume the tool needs to work only on iPhone and Android devices. In this age of Bring Your Own Device to work, however, enough employees using Windows Phone could become an issue that needs to be addressed. In other words, everyone’s assumptions must go beyond the obvious, such as required resources and expenses, and get into the details of user expectations, work habits and their use of technology. Test all of these assumptions and adjust your plans as you determine whether or not they prove true.
Step 5
Map Out Key Checkpoints: Typically, whoever’s managing a project wants to document the entire development process, from kickoff meeting to rollout. But Discovery-Driven Planning is an ongoing process that relies on documentation that encompasses only what you’re sure about.
So, decide upfront where you’ll put checkpoints to test your original assumptions against newly learned details and possibly identify new assumptions to consider. “These should be points in time right before your company decides to invest more time and money so that you can either stop the project or redirect it based on what you’ve learned so far,” Gallo says. Also, she notes, be sure to update your reverse income statement and operational requirements whenever you adjust an assumption.
McGrath told Gallo that DDP is best applied to projects that have much uncertainty to them and require a number of assumptions to be made, tested and adjusted for. But perhaps most important is to understand this is an ongoing process. You don’t simply go through DDP’s five steps and declare the process complete. “It’s a living plan that has to be revisited regularly,” Gallo says.
The world of Human Capital Management is in a period of extreme flux today, and not just in terms of technology. New approaches to performance management, learning, engagement, social recruiting and the use of data often means developing a program or implementing the right new technology is akin to hitting a moving target. Discovery-Driven Planning, it seems to us, is a tool that will enforce discipline on efforts that might otherwise turn chaotic.
Image Copyright: kentoh / 123RF Stock Photo
