Saturday, August 26, 2006
Best Practices
Wagner's paper (abstract only) is available here.
Erica Wagner, working for an Ivy League college as a contractor, had the opportunity to watch "best practices" being created up close and personal. Her experience was less than positive.
She participated in a joint development with an Enterprise Resource Planning software company, creating an ERP system meant especially for college grant management.
She had an idea of what best practices meant. She thought there would be certain ideas at her college that the software vendor would note as working well, and those processes would be inculcated into the software itself, embodying one best practice after another.
The college and the software vendor planned to sell this set of best practices embodied in software to other colleges, making a tidy profit for both.
But Dr. Wagner's experiences of the discovery of best practices was much different than her expectations. Best practices were decided arbitrarily, based on concepts that had no basis in reality, and were "tested" only in a political sense.
The executives of the software vendor and the some of the upper level managers at the college decided that the budgeting method needed to be switched from the well-known Commitment Accounting (CA) to the lesser-known Time-Phased Budgeting (TPB). They saw TPB as a successful system in private industry, and decided it should be applied to the college's grant management. This, despite the fact that it had never been used at any college for this purpose (or any purpose).
This "best practice" didn't work out so well at the college. The researchers didn't see any point in changing to a new budgeting system, especially when their existing system has no actual problem. The problems that did exist were traced back to lack of integration between departments, not an incorrect budgeting system.
But guess which side won? The side searching for the actual best practices, or the side that had already decided what concept represented the "best practice?"
The college put the new budgeting system into the software, dubbed it as a "best practice" and subsequently sold it as such to other colleges, much to the chagrin of the researchers.
The college also had to create two new departments to convert the still prevalent CA budgets into TPB budgets so the ERP system could understand the figures. The TPB information was not used by anyone.
It's not hard to imagine that this is a fairly common process for creating best practices in ERP software.
And ERP is not the only perpetrator of best practices. I've been a computer consultant for more than twenty years, and I can say from experience that consultants make a lot of money taking the "best practices" from one client and applying them to another.
So what's the problem with best practices when not codified into a computer program (like ERP)?
Let's go back to the original definition of "best practice." Lynda Gratton and Sumantra Ghoshal write, in their article in the MIT Sloan Review, that best practices are "developed outside a business unit or company and then brought into adopting organizations in an attempt to get them on a level playing field with their competitive set."
There's a little bit of "Everyone's doing it, why don't we?" involved in the idea of best practices.
But the problem, as Gratton and Ghoshal point out, is that part of an organization's own competitive advantage is likely their own "signature processes," those that make them unique and that work particularly well for their own organization. It's what "makes us us."
And there's another dangerous assumption with best practices. Let's say we decide to take a project estimation process from Company A and implement it at Company B.
We've already covered that this "process copying" makes the assumption that Company B has no signature processes that are worthwhile. But the second problematic assumption is that the people inside Company A and Company B are identical. That they work the same way, have the same motivations, share the same culture.
This assumption is not correct. Just as every organization is different, so every person is different. Even trying to copy a process from one department in Company B to another department in Company B will have problems. We know this from experience. Why? Everyone is different.
Using our example, let's say that Company A is staffed with a lot of young, ambitious grads from business school. Company B is staffed with employees with more than 10 years experience in their current jobs.
We saw evidence of this at a software product company a couple of years ago. One team was incredibly successful at creating a productive software development process, building a monstrously large, complex product in a matter of months. However, they relied heavily on a hyper-productive project manager / technical architect in the middle of it all who was able to hold all the concepts of what needed to be done inside his head and was happy to explain it to anyone who needed to know. Other project teams tried to copy this successful approach, but each one failed because they didn't have a replica of that amazing guy. It just didn't work. They needed something that fit their own situation, their own staff.
Erica Wagner, working for an Ivy League college as a contractor, had the opportunity to watch "best practices" being created up close and personal. Her experience was less than positive.
She participated in a joint development with an Enterprise Resource Planning software company, creating an ERP system meant especially for college grant management.
She had an idea of what best practices meant. She thought there would be certain ideas at her college that the software vendor would note as working well, and those processes would be inculcated into the software itself, embodying one best practice after another.
The college and the software vendor planned to sell this set of best practices embodied in software to other colleges, making a tidy profit for both.
But Dr. Wagner's experiences of the discovery of best practices was much different than her expectations. Best practices were decided arbitrarily, based on concepts that had no basis in reality, and were "tested" only in a political sense.
The executives of the software vendor and the some of the upper level managers at the college decided that the budgeting method needed to be switched from the well-known Commitment Accounting (CA) to the lesser-known Time-Phased Budgeting (TPB). They saw TPB as a successful system in private industry, and decided it should be applied to the college's grant management. This, despite the fact that it had never been used at any college for this purpose (or any purpose).
This "best practice" didn't work out so well at the college. The researchers didn't see any point in changing to a new budgeting system, especially when their existing system has no actual problem. The problems that did exist were traced back to lack of integration between departments, not an incorrect budgeting system.
But guess which side won? The side searching for the actual best practices, or the side that had already decided what concept represented the "best practice?"
The college put the new budgeting system into the software, dubbed it as a "best practice" and subsequently sold it as such to other colleges, much to the chagrin of the researchers.
The college also had to create two new departments to convert the still prevalent CA budgets into TPB budgets so the ERP system could understand the figures. The TPB information was not used by anyone.
It's not hard to imagine that this is a fairly common process for creating best practices in ERP software.
And ERP is not the only perpetrator of best practices. I've been a computer consultant for more than twenty years, and I can say from experience that consultants make a lot of money taking the "best practices" from one client and applying them to another.
So what's the problem with best practices when not codified into a computer program (like ERP)?
Let's go back to the original definition of "best practice." Lynda Gratton and Sumantra Ghoshal write, in their article in the MIT Sloan Review, that best practices are "developed outside a business unit or company and then brought into adopting organizations in an attempt to get them on a level playing field with their competitive set."
There's a little bit of "Everyone's doing it, why don't we?" involved in the idea of best practices.
NOTE: The investment community has even bought into best practices and ERP, to the extent that they often give a higher stock valuation to a company that has implemented an ERP package than one that hasn't. This is how far the myth of best practices and ERP has travelled.
But the problem, as Gratton and Ghoshal point out, is that part of an organization's own competitive advantage is likely their own "signature processes," those that make them unique and that work particularly well for their own organization. It's what "makes us us."
And there's another dangerous assumption with best practices. Let's say we decide to take a project estimation process from Company A and implement it at Company B.
We've already covered that this "process copying" makes the assumption that Company B has no signature processes that are worthwhile. But the second problematic assumption is that the people inside Company A and Company B are identical. That they work the same way, have the same motivations, share the same culture.
This assumption is not correct. Just as every organization is different, so every person is different. Even trying to copy a process from one department in Company B to another department in Company B will have problems. We know this from experience. Why? Everyone is different.
Using our example, let's say that Company A is staffed with a lot of young, ambitious grads from business school. Company B is staffed with employees with more than 10 years experience in their current jobs.
We saw evidence of this at a software product company a couple of years ago. One team was incredibly successful at creating a productive software development process, building a monstrously large, complex product in a matter of months. However, they relied heavily on a hyper-productive project manager / technical architect in the middle of it all who was able to hold all the concepts of what needed to be done inside his head and was happy to explain it to anyone who needed to know. Other project teams tried to copy this successful approach, but each one failed because they didn't have a replica of that amazing guy. It just didn't work. They needed something that fit their own situation, their own staff.
