May the hatred in the hearts of the terrorists always be dwarfed by the love of good men and women. May freedom always be stronger than fear. May we always rise from the ashes and darkness of adversity to enjoy the warmth of a new sunrise.
Tonight I remember many people, both living and dead, for whom battles with fear and hatred are very real. To them I say: Because you keep choosing life, love and freedom, Thank You.
Friday, September 11, 2009
Wednesday, September 2, 2009
Telecommuting
The subject of telecommuting is nothing new to the Department of Defense; but with increases in technological capabilities, the threat of swine or bird flu looming somewhere over the horizon, the new anti-terrorism federal building requirements, and a tech savvy workforce; the pressure to talk about telecommuting is growing. So let's talk about telecommuting for a few minutes.
I've personally experienced the telework issue from many perspectives during my career and have had about 12 good years to read and think about it. I'll describe for you some of the issues I encountered as a non-eligible worker-bee, a supervisor, a mid-level manager, a senior level manager, and from where I am today.
As a reader of my blog, you already know that I wore a Navy uniform during my first few years with the Department of Defense. Active duty soldiers, sailors and airmen are taught from the very beginning the importance of being at your post - at the appointed time, awake, alert and without complaint. Falling asleep while your on watch or leaving your post is a very serious offense. During wartime, not being at your post has resulted in more than one courts marshal.
People's lives are literally depending on the watch being where he or she is supposed to be. In my case, I provided hands on medical support to sick and injured people. From a telework perspective, I was not a good candidate during those years.
It is very clear to me that telework under certain circumstances is not a good idea. I know many people - ex-military - who come to the telework discussion from having stood the watch themselves - many people with that kind of background approach the issue with a wary eye. I was one of them.
Others I might put in the "should-not-telework" category would be people who are hired specifically to greet people (secretaries, concierge, appointment clerks (unless by phone), etc). If those people weren't physically where they are supposed to be, the job wouldn't get done. Jobs that require handling classified materials on a regular basis might not be well suited for telework. I would also not want to see any of the contact professions work from home - doctors, medical support staff, airplane mechanics, Navy SEALS, surgeons, etc. Although in some cases I would love to see doctors make house calls again.
When I left the Navy in 1997, I went to work for a federal contractor. During those years, I spent a lot of time on the client site, worked long hours, and rose up the middle management ranks quickly. When I managed small groups of direct reports and had products or services to deliver, telework wasn't much of an issue. In those years, telework was used as a way to conserve leave and keep employees productive during the occasional sickness or acute injury. It was frankly a pretty hands-off affair since employees weren't gone too long or too often. It required some minor documentation and a return-to-work meeting with employees who were hopefully carrying some deliverable in the form of a report, a proposal, or something similar.
I continued to climb the ladder, and in a few short years, I found myself with 11 managerial direct reports - each of them had staffs and departments of their own and products and or services to produce. They were geographically spread out from Kansas to Puerto Rico. My focus shifted from producing anything or supervising production to pure management of people, moral, issues and outcomes. I no longer had the luxury of knowing all of my employees by name and face (except for my 11 task and project managers).
Insight was provided to me in the form of reports: budgets, burn rates, G&A, ODC's vs labor, etc. From that perspective, the economics of teleworking look pretty good. Since I didn't have office space to support for telework employees, overhead was lower. That meant that the company could introduce a lower multiple for labor hours, move excess money into reserves, use excess money for quality improvements, or apply excess to the bottom line. It also gave us flexibility with hiring. We had one employee who did nothing but proposals for us. I never saw him. He did all his work from home. The bottom line was that embracing telework made my company more competitive.
My next job was as the CIO for Navy Medical Logistics. I was dual hatted as the Information Systems Security Manager (ISSM). In these roles, I got to know the technical, security and policy side of telework. At first, it was scary. I had Information Assurance Vulnerability Alerts (IAVA) to contend with. This was a 100% visibility and a no-fail exercise. There were people assigned to make sure that my command was compliant and it was my butt on the line if a roaming laptop came back, plugged in and infected my network.
There were questions about who pays for the home computers and home phone lines, how do we protect government information in an environment where we don't have direct control, and more. Even something as simple as fixing a locked out or forgotten user password was stimulus for a major discussion. At that time, there was little precedent, virtually no policy, and no guru's out there who had set up the systems to guide us.
I had VPN capacity issues and property (mostly computers) tracking issues. I had, in my mind, a major control problem. The computers that people took home with them were no longer surrounded by the safety and protection of my envelope. At the command, I had firewalls, virus protection, remote monitoring, intrusion detection systems, and more. At home, these computers were left at the mercy of whatever user borrowed it. Judging from the volume and quality of my help desk tickets, that was a scary prospect.
Yet, somehow, we survived. We wrote new policy, created new ways to keep our networks safe, and adjusted our personal paradigms. We had to remind ourselves that productivity was the real objective - not security for security sake. Automation is a workforce enabler, and from the big picture perspective, telework gave us a more productive workforce. Specifically, we had a large number of contracting officers (KO's) and their support staffs who, when contract season rolled through (or as they might say: rolled over us), they could work from home and on weekends. This small enhancement in flexibility made a big difference to them and to our customers.
When I accepted the job as Chief for Defense Business Transformation for the Military Health System (MHS), I had a significant outcome to deliver. My staff and the extended support I needed from other departments were spread out as they were in an earlier time in my career. My small contracted team worked from a second building on the same campus, from a third building in another city, and from their homes. The Army Medical Transformation capability was in Texas, the Navy Medical Transformation capability was in DC and Bethesda, and the Air Force medical Transformation support were... well, I never really figured out where they were. They showed up for the meetings and called me on the phone.
The bottom line focus was on outcomes. I didn't much care where everyone was physically located. I was very concerned with our objectives, our obstacles, the strengths and weaknesses of my combined resources, communication abilities, and reach. I was hired to establish a new program - Defense Business Transformation for the Military Health System. I would often only see my staff members once per week - if at all. But I always knew where we (the MHS) were in terms of outcomes, team strengths, and obstacles.
With the help of telework and a remote working arrangement, a program was born where no program existed previously. It had well documented process, a strong virtual presence - and people literally around the world, in three different Services (Army Medicine, Navy Medicine, and Air Force Medical Services) had come together around the notion of good due diligence and better investment decisions.
Due in part to our need to reach out to and empower people around the world that we knew we would never physically meet, we did a lot of work in the virtual space. We embraced asynchronous communication and became comfortable with the notion that we don't need to see one another in order to communicate. Policy, process diagrams, Web sites, podcasts, CD's, brochures - all acted like breadcrumbs that we scattered in strategic places - deliberately leading those who stumbled across them to the same place and the same behavior patterns.
Our footprint was so large, that when it came time to divide up what I had built into smaller parts and distribute those parts into the organization (to "institutionalize" them), there were some lively arguments. Some departments who were inheriting pieces of my program wanted resources too. When they found out how few resources I actually had, they were in disbelief. They thought I had an army of people. The fact that my little platoon made themselves largely virtual and spread out had affected people's perception. We gave the illusion that we were many of us because of outcome was so profound.
Today, I telework myself. Do do this effectively, I had to involve my family. They understand that when I'm in my home office, I'm not available. I work hard to separate the hours I work from the hours I spend with my family or doing other things. Do I leave occasionally and run to the post office or the dry cleaners, you bet I do. But I also keep track of the time I put in and ensure that my employer gets full value from the time they pay for.
My office has two computers, a fax machine, a separate phone line (though I use a government issues phone for most calls), large monitors, Web cams and a USB microphone (for DCO teleconferences), two printers, a big leather chair, and a book shelf of reference materials. It has become my "head space" where I can think about issues and create with minimal interruption, and write in support of many initiatives going on back in the group office space.
Telework is not for everyone. Some people don't like the idea of telework and /or don't have a suitable work site setup to do telework if they wanted to. Thank goodness for them! Most organizations do need some physical presence, and the strengths of working together in the same physical space should never be diminished.
For those who do consider telework, here are some additional issues that deserve some thought:
- Safety: I suspect we will discover that working from an alternative work site does not diminish an employer's responsibility for doing everything they can to provide a safe environment for its employees. The agency I work for has a safety checklist that must be signed by both the employee and the employer. On it are things to look for like wires, lighting, and environmental controls. I think this is an excellent idea & it should be accompanied by some training - perhaps a DVD that employees can take home and watch in the comfort of their home environment.
- Penalties: As more and more people and organizations embrace telework, we need to keep an eye on penalties.
- On the one hand, there are penalties applied against teleworkers by those who don't believe in the program. Either supervisors or fellow employees make it difficult to apply, set up physical meetings on known telework days, or otherwise make life difficult for the teleworker.
- On the other hand, someone WILL abuse the system. Human nature is what it is. If one can surf pornography on computers, someone will surf pornography on computers in the workspace. If someone can be a slacker at home, then someone will be a slacker at home.
The questions we need to ask is what are we going to do about penalties? Answer this question before engaging in a telework program - or risk a blow up later. The most likely scenario would be an uprising from the telework nay-sayers who hold the slacker up as an example of why telework can't work. They irritate the senior decision maker enough where the senior decision maker calls for a halt to the program.
- Education:
- Employees have to understand how to manage their time, set boundaries, keep good records, care for their home office environment, and communicate in new ways.
- Supervisors have to learn how to expand their virtual reach. The basics of empowering and motivating employees, rewarding, delegating, holding accountable, coordinating, etc don't change in a telework situation. The methods we use to make those things happen change.
- The Business Case:
From the employer perspective, productive hours generally go up as employees spend more time working and less time commuting. Overhead will go down, but only if adjustments are made to accommodate the telework model. For example, double book offices and cubes - getting twice the amount of people in the same square footage.
From a pure time perspective, my commute is 47 miles and averages 90 minutes each way in DC traffic (it's taken me as much as four hours one way, and I've done it in as little as 1 hour with no traffic). By contrast, it takes me 30 seconds to get from my bedroom to my office downstairs, 2 minutes 58 seconds to boot up my HP Windows computer, insert my CAC card, log in, and click through all the automated routines that my IT department set up for me, and 42 seconds to connect the VPN - for a grand total of 4 minutes and 10 seconds. I will subtract the 4 minutes and 10 seconds (my telework commuting time) from my on-site commute time to be fair.
If I were precise about my minutes, which I'm not, I would say that my employer gets an extra 175 minutes and 40 seconds out of my day, every day that I telework. I will instead round up to 180 minutes or 3 hours. So the total additional working time my employer gets for every day I telework looks like this:
Telework 1 day per week = +150 hrs / yr (3hrs x 50 weeks (assuming 2 week vacation))
Telework 2 days per week = +300 hrs / yr
Telework 3 days per week = +450 hrs / yr
Telework 4 days per week = +600 hrs / yr
Telework 5 days per week = +750 hrs / yr
The quality of my work reflects this. Whereas when I do go to the office (which I do every week), I spend most of my time making human connections and nurturing relationships - the sort of thing we do best in person.
Note: There is also an insidious effect in that employees who live and work in the same space tend to blur the two over time. When I first started teleworking, I would find myself working well into the night and early hours of the morning. I would think "I'll just do this one more thing..." and the time would slip away. I admit that I still do this from time to time, but not as often as I used to.
From the employee perspective, consider the following two scenarios (these are my real numbers taken at the time I typed this):
1. Assuming two week vacation, a car that averages 25 mpg, $2.55 / gallon of gas, a 47 mile commute, an $18 parking ticket, and a $10 lunch as the high end costs.
2. Assume the same vacation, car and gas price with a 7.7 mile commute to the Metro. A $4.50 train ticket (each way), a bag lunch from home, a $4 cup of coffee, and a $4.75 parking ticket on the lower end.
In the first scenario, daily cost =
$4.75 trip cost (47 miles / 25mpg x $2.55 gal)
+$18.00 parking
+$10.00 lunch
-------------------
$32.79 per day
In the second scenario, daily cost =
$0.79 trip cost (7.7 miles / 25mpg x $2.55 gal)
+$4.75 parking
+$13.00 ($9 train + $4 coffee)
-------------------
$18.54 per day
This means an annual, after tax cost savings between $963.84 - $1,705.29 for each one day per week that the employee teleworks. Using the assumptions above, an employee could realize annual after tax savings in according to the table below:
Telework 1 day per week = $963.84 - $1705.29 annual after tax savings
Telework 2 days per week = $1,927.68 - $3,410.58 annual after tax cost savings
Telework 3 days per week = $2,891.52 - $5,115.86 annual after tax cost savings
Telework 4 days per week = $3,855.56 - $6,821.15 annual after tax cost savings
Telework 5 days per week = $4,819.20 - $8,526.44 annual after tax cost savings
In summary, I would offer the following:
- Telework is not for everyone, but where it makes sense to apply telework, it can benefit both the employer and the employee
- Telework can lead to reduction of corporate cost, especially if the work structure is adapted to accomodate it.
- Telework can increase flexibility in schedules through asynchronous communication
- Telework can result in after tax savings for employees
- Telework can make companies more competitive and make jobs with those companies more attractive
- Telework will be abused, so be prepared for that
- Telework requires additional support beyond the obvious: technology, policy, risk mitigation, training and education, and commitment
Keep these things in mind and hopefully you too will have a positive telework experience!
I've personally experienced the telework issue from many perspectives during my career and have had about 12 good years to read and think about it. I'll describe for you some of the issues I encountered as a non-eligible worker-bee, a supervisor, a mid-level manager, a senior level manager, and from where I am today.
As a reader of my blog, you already know that I wore a Navy uniform during my first few years with the Department of Defense. Active duty soldiers, sailors and airmen are taught from the very beginning the importance of being at your post - at the appointed time, awake, alert and without complaint. Falling asleep while your on watch or leaving your post is a very serious offense. During wartime, not being at your post has resulted in more than one courts marshal.
People's lives are literally depending on the watch being where he or she is supposed to be. In my case, I provided hands on medical support to sick and injured people. From a telework perspective, I was not a good candidate during those years.
It is very clear to me that telework under certain circumstances is not a good idea. I know many people - ex-military - who come to the telework discussion from having stood the watch themselves - many people with that kind of background approach the issue with a wary eye. I was one of them.
Others I might put in the "should-not-telework" category would be people who are hired specifically to greet people (secretaries, concierge, appointment clerks (unless by phone), etc). If those people weren't physically where they are supposed to be, the job wouldn't get done. Jobs that require handling classified materials on a regular basis might not be well suited for telework. I would also not want to see any of the contact professions work from home - doctors, medical support staff, airplane mechanics, Navy SEALS, surgeons, etc. Although in some cases I would love to see doctors make house calls again.
When I left the Navy in 1997, I went to work for a federal contractor. During those years, I spent a lot of time on the client site, worked long hours, and rose up the middle management ranks quickly. When I managed small groups of direct reports and had products or services to deliver, telework wasn't much of an issue. In those years, telework was used as a way to conserve leave and keep employees productive during the occasional sickness or acute injury. It was frankly a pretty hands-off affair since employees weren't gone too long or too often. It required some minor documentation and a return-to-work meeting with employees who were hopefully carrying some deliverable in the form of a report, a proposal, or something similar.
I continued to climb the ladder, and in a few short years, I found myself with 11 managerial direct reports - each of them had staffs and departments of their own and products and or services to produce. They were geographically spread out from Kansas to Puerto Rico. My focus shifted from producing anything or supervising production to pure management of people, moral, issues and outcomes. I no longer had the luxury of knowing all of my employees by name and face (except for my 11 task and project managers).
Insight was provided to me in the form of reports: budgets, burn rates, G&A, ODC's vs labor, etc. From that perspective, the economics of teleworking look pretty good. Since I didn't have office space to support for telework employees, overhead was lower. That meant that the company could introduce a lower multiple for labor hours, move excess money into reserves, use excess money for quality improvements, or apply excess to the bottom line. It also gave us flexibility with hiring. We had one employee who did nothing but proposals for us. I never saw him. He did all his work from home. The bottom line was that embracing telework made my company more competitive.
My next job was as the CIO for Navy Medical Logistics. I was dual hatted as the Information Systems Security Manager (ISSM). In these roles, I got to know the technical, security and policy side of telework. At first, it was scary. I had Information Assurance Vulnerability Alerts (IAVA) to contend with. This was a 100% visibility and a no-fail exercise. There were people assigned to make sure that my command was compliant and it was my butt on the line if a roaming laptop came back, plugged in and infected my network.
There were questions about who pays for the home computers and home phone lines, how do we protect government information in an environment where we don't have direct control, and more. Even something as simple as fixing a locked out or forgotten user password was stimulus for a major discussion. At that time, there was little precedent, virtually no policy, and no guru's out there who had set up the systems to guide us.
I had VPN capacity issues and property (mostly computers) tracking issues. I had, in my mind, a major control problem. The computers that people took home with them were no longer surrounded by the safety and protection of my envelope. At the command, I had firewalls, virus protection, remote monitoring, intrusion detection systems, and more. At home, these computers were left at the mercy of whatever user borrowed it. Judging from the volume and quality of my help desk tickets, that was a scary prospect.
Yet, somehow, we survived. We wrote new policy, created new ways to keep our networks safe, and adjusted our personal paradigms. We had to remind ourselves that productivity was the real objective - not security for security sake. Automation is a workforce enabler, and from the big picture perspective, telework gave us a more productive workforce. Specifically, we had a large number of contracting officers (KO's) and their support staffs who, when contract season rolled through (or as they might say: rolled over us), they could work from home and on weekends. This small enhancement in flexibility made a big difference to them and to our customers.
When I accepted the job as Chief for Defense Business Transformation for the Military Health System (MHS), I had a significant outcome to deliver. My staff and the extended support I needed from other departments were spread out as they were in an earlier time in my career. My small contracted team worked from a second building on the same campus, from a third building in another city, and from their homes. The Army Medical Transformation capability was in Texas, the Navy Medical Transformation capability was in DC and Bethesda, and the Air Force medical Transformation support were... well, I never really figured out where they were. They showed up for the meetings and called me on the phone.
The bottom line focus was on outcomes. I didn't much care where everyone was physically located. I was very concerned with our objectives, our obstacles, the strengths and weaknesses of my combined resources, communication abilities, and reach. I was hired to establish a new program - Defense Business Transformation for the Military Health System. I would often only see my staff members once per week - if at all. But I always knew where we (the MHS) were in terms of outcomes, team strengths, and obstacles.
With the help of telework and a remote working arrangement, a program was born where no program existed previously. It had well documented process, a strong virtual presence - and people literally around the world, in three different Services (Army Medicine, Navy Medicine, and Air Force Medical Services) had come together around the notion of good due diligence and better investment decisions.
Due in part to our need to reach out to and empower people around the world that we knew we would never physically meet, we did a lot of work in the virtual space. We embraced asynchronous communication and became comfortable with the notion that we don't need to see one another in order to communicate. Policy, process diagrams, Web sites, podcasts, CD's, brochures - all acted like breadcrumbs that we scattered in strategic places - deliberately leading those who stumbled across them to the same place and the same behavior patterns.
Our footprint was so large, that when it came time to divide up what I had built into smaller parts and distribute those parts into the organization (to "institutionalize" them), there were some lively arguments. Some departments who were inheriting pieces of my program wanted resources too. When they found out how few resources I actually had, they were in disbelief. They thought I had an army of people. The fact that my little platoon made themselves largely virtual and spread out had affected people's perception. We gave the illusion that we were many of us because of outcome was so profound.
Today, I telework myself. Do do this effectively, I had to involve my family. They understand that when I'm in my home office, I'm not available. I work hard to separate the hours I work from the hours I spend with my family or doing other things. Do I leave occasionally and run to the post office or the dry cleaners, you bet I do. But I also keep track of the time I put in and ensure that my employer gets full value from the time they pay for.
My office has two computers, a fax machine, a separate phone line (though I use a government issues phone for most calls), large monitors, Web cams and a USB microphone (for DCO teleconferences), two printers, a big leather chair, and a book shelf of reference materials. It has become my "head space" where I can think about issues and create with minimal interruption, and write in support of many initiatives going on back in the group office space.
Telework is not for everyone. Some people don't like the idea of telework and /or don't have a suitable work site setup to do telework if they wanted to. Thank goodness for them! Most organizations do need some physical presence, and the strengths of working together in the same physical space should never be diminished.
For those who do consider telework, here are some additional issues that deserve some thought:
- Safety: I suspect we will discover that working from an alternative work site does not diminish an employer's responsibility for doing everything they can to provide a safe environment for its employees. The agency I work for has a safety checklist that must be signed by both the employee and the employer. On it are things to look for like wires, lighting, and environmental controls. I think this is an excellent idea & it should be accompanied by some training - perhaps a DVD that employees can take home and watch in the comfort of their home environment.
- Penalties: As more and more people and organizations embrace telework, we need to keep an eye on penalties.
- On the one hand, there are penalties applied against teleworkers by those who don't believe in the program. Either supervisors or fellow employees make it difficult to apply, set up physical meetings on known telework days, or otherwise make life difficult for the teleworker.
- On the other hand, someone WILL abuse the system. Human nature is what it is. If one can surf pornography on computers, someone will surf pornography on computers in the workspace. If someone can be a slacker at home, then someone will be a slacker at home.
The questions we need to ask is what are we going to do about penalties? Answer this question before engaging in a telework program - or risk a blow up later. The most likely scenario would be an uprising from the telework nay-sayers who hold the slacker up as an example of why telework can't work. They irritate the senior decision maker enough where the senior decision maker calls for a halt to the program.
- Education:
- Employees have to understand how to manage their time, set boundaries, keep good records, care for their home office environment, and communicate in new ways.
- Supervisors have to learn how to expand their virtual reach. The basics of empowering and motivating employees, rewarding, delegating, holding accountable, coordinating, etc don't change in a telework situation. The methods we use to make those things happen change.
- The Business Case:
From the employer perspective, productive hours generally go up as employees spend more time working and less time commuting. Overhead will go down, but only if adjustments are made to accommodate the telework model. For example, double book offices and cubes - getting twice the amount of people in the same square footage.
From a pure time perspective, my commute is 47 miles and averages 90 minutes each way in DC traffic (it's taken me as much as four hours one way, and I've done it in as little as 1 hour with no traffic). By contrast, it takes me 30 seconds to get from my bedroom to my office downstairs, 2 minutes 58 seconds to boot up my HP Windows computer, insert my CAC card, log in, and click through all the automated routines that my IT department set up for me, and 42 seconds to connect the VPN - for a grand total of 4 minutes and 10 seconds. I will subtract the 4 minutes and 10 seconds (my telework commuting time) from my on-site commute time to be fair.
If I were precise about my minutes, which I'm not, I would say that my employer gets an extra 175 minutes and 40 seconds out of my day, every day that I telework. I will instead round up to 180 minutes or 3 hours. So the total additional working time my employer gets for every day I telework looks like this:
Telework 1 day per week = +150 hrs / yr (3hrs x 50 weeks (assuming 2 week vacation))
Telework 2 days per week = +300 hrs / yr
Telework 3 days per week = +450 hrs / yr
Telework 4 days per week = +600 hrs / yr
Telework 5 days per week = +750 hrs / yr
The quality of my work reflects this. Whereas when I do go to the office (which I do every week), I spend most of my time making human connections and nurturing relationships - the sort of thing we do best in person.
Note: There is also an insidious effect in that employees who live and work in the same space tend to blur the two over time. When I first started teleworking, I would find myself working well into the night and early hours of the morning. I would think "I'll just do this one more thing..." and the time would slip away. I admit that I still do this from time to time, but not as often as I used to.
From the employee perspective, consider the following two scenarios (these are my real numbers taken at the time I typed this):
1. Assuming two week vacation, a car that averages 25 mpg, $2.55 / gallon of gas, a 47 mile commute, an $18 parking ticket, and a $10 lunch as the high end costs.
2. Assume the same vacation, car and gas price with a 7.7 mile commute to the Metro. A $4.50 train ticket (each way), a bag lunch from home, a $4 cup of coffee, and a $4.75 parking ticket on the lower end.
In the first scenario, daily cost =
$4.75 trip cost (47 miles / 25mpg x $2.55 gal)
+$18.00 parking
+$10.00 lunch
-------------------
$32.79 per day
In the second scenario, daily cost =
$0.79 trip cost (7.7 miles / 25mpg x $2.55 gal)
+$4.75 parking
+$13.00 ($9 train + $4 coffee)
-------------------
$18.54 per day
This means an annual, after tax cost savings between $963.84 - $1,705.29 for each one day per week that the employee teleworks. Using the assumptions above, an employee could realize annual after tax savings in according to the table below:
Telework 1 day per week = $963.84 - $1705.29 annual after tax savings
Telework 2 days per week = $1,927.68 - $3,410.58 annual after tax cost savings
Telework 3 days per week = $2,891.52 - $5,115.86 annual after tax cost savings
Telework 4 days per week = $3,855.56 - $6,821.15 annual after tax cost savings
Telework 5 days per week = $4,819.20 - $8,526.44 annual after tax cost savings
In summary, I would offer the following:
- Telework is not for everyone, but where it makes sense to apply telework, it can benefit both the employer and the employee
- Telework can lead to reduction of corporate cost, especially if the work structure is adapted to accomodate it.
- Telework can increase flexibility in schedules through asynchronous communication
- Telework can result in after tax savings for employees
- Telework can make companies more competitive and make jobs with those companies more attractive
- Telework will be abused, so be prepared for that
- Telework requires additional support beyond the obvious: technology, policy, risk mitigation, training and education, and commitment
Keep these things in mind and hopefully you too will have a positive telework experience!
Tuesday, August 11, 2009
Changing of the Guard
Technology is changing the world. It's bringing us closer together: phone, satellite, transportation and internet. Technology enables communication on a scale and in formats that people only a decade or two ago would have thought impossible. It's a force multiplier. The number of ways to mix and match technology to produce results is limited only by human imagination - which, as we know has few limits. If we can dream it, chances are good, that we can do it - or soon will be able to do it. Evolution is increasing it's speed exponentially. Moore's law can barely keep up.
All of this change and added capability is exposing the human condition and busting paradigms at light speeds. Anyone who thinks that technology is not actually changing the people who use it need only look a little harder.
David Weinberger addressed a government crowd a couple of weeks ago with an interesting story about the relationship between our old paper based system and authority. I had the good fortune of listening to him amuse the crowd (he is a very funny guy). He held up the idea of a paper based world as a world of absolute authority, where a seeker of knowledge stops dead once he or she reaches the final authority on a subject - perhaps a piece of paper with a signature on the bottom of it. After all, he told the crowd, that paper with the signature is the authority!
In today's world of internet and hyperlinks, one could wander about looking for "the" answer to a question forever and never find it. There are an endless supply of answers to just about every question - most of them only a series of clicks away. And it's not the bad information that we have to worry about. We know what to do with bad information. It's the good information - the overwhelming supply of good information that have a hard time dealing with. People no longer have the luxury of coming to a single piece of paper and stopping - they "Google" - an endeavor that could keep someone up all night long flowing from interesting bit of information to interesting bit of information. Today, it's left up to the individual to say when enough is enough - when they ultimately decide that they have enough knowledge to make a good informed decision.
My friend added some new thoughts to my consciousness: We are witnessing the death of power hording and absolute authority. In today's world, there is a growing shift from concentrated power to distributed power. Large media outlets are being out maneuvered by individuals with personal camcorders. Blogging and podcasting are taking over the news. Social media is flattening hierarchical structures everywhere. Data warehouses and system access requests are becoming a thing of the past. Individual systems don't matter when we can get to any data anywhere through the use of Web logic, mash-ups and an internet service bus.
Technology systems used to be reflections of human systems. Today, human systems are beginning to reflect advancements in technology systems. It won't be too long, predicts my very smart friend, that we will see all of these old systems approaches (and the governance bodies who support and defend them) completely buried by a new generation of Web logic and mash-up gurus. Elaborate multi-billion dollar systems will be replaced by a few thousand dollars worth of techie Joe's time.
I invite you to browse a few hyperlinks and judge for yourself where you think we're going. Just don't stay up all night searching!
http://www.whitehouse.gov/open/innovations/
http://www.qlikview.com/
http://www.jackbe.com/
All of this change and added capability is exposing the human condition and busting paradigms at light speeds. Anyone who thinks that technology is not actually changing the people who use it need only look a little harder.
David Weinberger addressed a government crowd a couple of weeks ago with an interesting story about the relationship between our old paper based system and authority. I had the good fortune of listening to him amuse the crowd (he is a very funny guy). He held up the idea of a paper based world as a world of absolute authority, where a seeker of knowledge stops dead once he or she reaches the final authority on a subject - perhaps a piece of paper with a signature on the bottom of it. After all, he told the crowd, that paper with the signature is the authority!
In today's world of internet and hyperlinks, one could wander about looking for "the" answer to a question forever and never find it. There are an endless supply of answers to just about every question - most of them only a series of clicks away. And it's not the bad information that we have to worry about. We know what to do with bad information. It's the good information - the overwhelming supply of good information that have a hard time dealing with. People no longer have the luxury of coming to a single piece of paper and stopping - they "Google" - an endeavor that could keep someone up all night long flowing from interesting bit of information to interesting bit of information. Today, it's left up to the individual to say when enough is enough - when they ultimately decide that they have enough knowledge to make a good informed decision.
My friend added some new thoughts to my consciousness: We are witnessing the death of power hording and absolute authority. In today's world, there is a growing shift from concentrated power to distributed power. Large media outlets are being out maneuvered by individuals with personal camcorders. Blogging and podcasting are taking over the news. Social media is flattening hierarchical structures everywhere. Data warehouses and system access requests are becoming a thing of the past. Individual systems don't matter when we can get to any data anywhere through the use of Web logic, mash-ups and an internet service bus.
Technology systems used to be reflections of human systems. Today, human systems are beginning to reflect advancements in technology systems. It won't be too long, predicts my very smart friend, that we will see all of these old systems approaches (and the governance bodies who support and defend them) completely buried by a new generation of Web logic and mash-up gurus. Elaborate multi-billion dollar systems will be replaced by a few thousand dollars worth of techie Joe's time.
I invite you to browse a few hyperlinks and judge for yourself where you think we're going. Just don't stay up all night searching!
http://www.whitehouse.gov/open/innovations/
http://www.qlikview.com/
http://www.jackbe.com/
Friday, July 24, 2009
Presentations and Podcasts on Transformation
I've delivered a great many presentations on the subject of Defense Business Transformation during the four years I was the Chief for Defense Business Transformation for the Military Health System. I delivered these presentations in a medical community context, but the Defense Business Transformation content easily translates to any DoD environment.
Follow this link to take your pick of 45 months of weekly presentations: http://www.health.mil/dbt/dbtcommunity.aspx
These were delivered to a core community of just under 300 people from 7 different organizations each week. They were never all in the same room at the same time, but they rotated in and out and always got the briefing by mail.
I also prepared a number of ten minute podcasts on the subject of Defense Business Transformation. Each is delivered with music and stories to make the subject more interesting.
Follow this link to my podcasts: http://www.health.mil/dbt/podcast.aspx
My favorite ones are the last three. It took me a while to get used to the format, the studio, etc.
It's all free for the taking, so if you have an interest in the subject of Transformation in the Department of Defense, help yourself!
Follow this link to take your pick of 45 months of weekly presentations: http://www.health.mil/dbt/dbtcommunity.aspx
These were delivered to a core community of just under 300 people from 7 different organizations each week. They were never all in the same room at the same time, but they rotated in and out and always got the briefing by mail.
I also prepared a number of ten minute podcasts on the subject of Defense Business Transformation. Each is delivered with music and stories to make the subject more interesting.
Follow this link to my podcasts: http://www.health.mil/dbt/podcast.aspx
My favorite ones are the last three. It took me a while to get used to the format, the studio, etc.
It's all free for the taking, so if you have an interest in the subject of Transformation in the Department of Defense, help yourself!
Wednesday, July 22, 2009
Measuring Relationships from Social Media
I had an opportunity to meet Katie D Paine this afternoon at an Open Government and Innovation conference in DC. Katie specializes in public relations and measuring their effectiveness. Her commanding presence underscored her depth of knowledge, and her open and friendly demeanor in a one-on-one situation proved to me that she practices what she preaches with respect to building relationships of her own.
I bought Katie's book on the spot. Six hours later I have already found a good many nuggets of information that I believe will be useful for Transformation Agents in the DoD.
Gaining trust, building relationships, and communication with a purpose are things that many people instinctively understand are an important part of a change management program. But until now, I didn't know anyone who had a well documented methodology for measuring success (or failure) in these areas.
For anyone engaging social media as a means to an end: Katie's talk today was about how to measure the quality of relationships created through social media vs measuring the number of hits a social media site gets. The crowd laughed as she described her personal definition of "Hits" as
If you haven't already heard the question, I expect it will be a common for people holding the purse strings in the DoD to ask: what is the effectiveness of this media? We will need to be able to step up to that question with evidence.
Her book is titled Measuring Public Relationships: The Data-Driven Communicator's Guide to Success, and can be found on Amazon.com.
Katie also has a PR Measurement blog at http://kdpaine.blogs.com/
I recommend this book for anyone wanting to inject some science into an area traditionally thought of as "mushy" or unmeasurable: relationships.
I bought Katie's book on the spot. Six hours later I have already found a good many nuggets of information that I believe will be useful for Transformation Agents in the DoD.
Gaining trust, building relationships, and communication with a purpose are things that many people instinctively understand are an important part of a change management program. But until now, I didn't know anyone who had a well documented methodology for measuring success (or failure) in these areas.
For anyone engaging social media as a means to an end: Katie's talk today was about how to measure the quality of relationships created through social media vs measuring the number of hits a social media site gets. The crowd laughed as she described her personal definition of "Hits" as
"How Idiots Track Success."She made a good case for why measuring the number of hits a Web site gets is insufficient. Relationships matter more.
If you haven't already heard the question, I expect it will be a common for people holding the purse strings in the DoD to ask: what is the effectiveness of this media? We will need to be able to step up to that question with evidence.
Her book is titled Measuring Public Relationships: The Data-Driven Communicator's Guide to Success, and can be found on Amazon.com.
Katie also has a PR Measurement blog at http://kdpaine.blogs.com/
I recommend this book for anyone wanting to inject some science into an area traditionally thought of as "mushy" or unmeasurable: relationships.
Monday, July 20, 2009
Veterans Business Transformation?
It appears as though the Veteran's Administration (VA) is following in the Department of Defense Transformation footsteps. Though I haven't seen a Title 5 statute modification to force the Transformation VA-wide, it does appear that there is support at the highest levels of the VA for the kinds of behavior modification that the Defense Business Transformation program was established to encourage.
See the following press release from 17JUL09: http://www1.va.gov/opa/pressrel/pressrelease.cfm?id=1734
See the following press release from 17JUL09: http://www1.va.gov/opa/pressrel/pressrelease.cfm?id=1734
Sunday, July 19, 2009
Solving Real World Problems With Enterprise Architecture
The concept of Enterprise Architecture isn't really difficult to understand. Creating an Enterprise Architecture (EA) is simply a matter of using a standard notation to describe the people, tools and rules of an enterprise. Describing an enterprise is theoretically useful to decision makers because it allows them to see the relationships between things.
Using a standard notation is also theoretically useful to decision makers and personnel from different organizations because it creates a "common currency" for exchanging ideas and communicating with one another. The thought being - if you understand the notation, you can find your way around anyone's model in a short amount of time. Why do we need to do that?
It is not uncommon for decision makers to wonder, "If I make X decision..:"
- Who might be affected?
- What systems might be affected?
- What resources might be affected?
- Would we break something?
- What would give me the biggest bang for my buck?
- What information is available in the Enterprise to help me measure progress against a particular goal or objective?
In theory, the enterprise architecture model was designed to help answer these questions. It can be a useful tool when used in a large enterprise like the Department of Defense, or in one of the sub-components of the Department of Defense like the Army, Navy, Air Force, Marine Corps, etc.
Title 10 of the United States Code § 2222 requires that all Department of Defense business IT investments (modernizations, enhancements or development efforts) assert "compliance" with the Enterprise Architecture (EA). Without "compliance," there will be no authority given to spend money on an investment. If there is no "obligation authority" granted by the Defense Business Systems Management Committee (as defined by 10USC§186), then someone is eventually going to jail, paying a fine, or getting relived of duty.
The actual language states:
This notion of "compliance" with the architecture has been the subject of many debates since the law went into effect. People wonder what they have to be compliant with: the model? the content? the need to draw diagrams?
We get a clue from language later in the same statute. It tells us what content needs to be in the Enterprise Architecture:
Based on my personal experience, having conducted due diligence on more than $1 Billion of these investments, this is 1. apparently not clear enough and 2. not translating into direct benefits to the Department.
Most of the letters that I've seen assert "compliance" with the architecture are representing little more than the fact that that there is a diagram of the investment being reviewed (often referred to as solutions architecture) drawn, and that this diagram somehow has the same or similar words on it as can be found in the diagram of the Enterprise Architecture. The fact that an investment is or is not documented as compliant with the architecture has had little or no effect on business as usual. It mostly means that the file folder of paperwork on that investment just got a little heavier (due to the weight of the added diagrams and a piece of paper that says the diagrams are there). That's it.
It's not useful to anyone to spend the number of hours (and dollars) one must spend on creating a diagram as detailed as a solutions architecture - only to have it visually and semantically mapped to another diagram and make a file folder heavier. I've witnessed intelligent people spending days just changing the color scheme of boxes so that one model looks like the other. Then, when the colors are matched and the right box is in the middle of the paper, step forward and proudly proclaim "We're compliant with the architecture!"
What they really mean is they are compliant with the methodology described in the Department of Defense Architecture Framework and have found a way to make the words between the two models look the same.
What we need is a healthy dose of reality. If we can find a way to inject reality into these models, they can be extremely useful.
By way of example, let's assume that something bad happens somewhere in a theater of operations. As a former combat medic, I'll use a medical situation to illustrate my point.
A soldier is severely wounded by a road side bomb. He receives shrapnel wounds to his neck and, because there is a short window of time to treat this soldier, he is air lifted to a local NATO alliance facility. The doctors there examine him, rush him up to the operating room, repair his wound and 10 minutes later, the soldier is dead.
The medical teams are initially confused because although the wounds were serious, they were immediately controlled and the soldier appeared otherwise strong. By all accounts, this soldier should have survived. An investigation is started.
After the investigation is complete, it is determined that the soldier died from an allergic reaction to the anesthesia administered in the operating room. The NATO team did not have access to the soldier's medical records, his past medical history, or a record of what he was allergic to. The severe blood loss made this soldier much less capable of handling the allergic reaction. He died.
The report gets filed in a lesson's learned database, and is recovered by a team of proactive architects a year or two later. They read through the case with great interest. It seems to them that they have found a data sharing problem that can be solved.
They contact some military doctors, share what they've found and get their feedback. The doctors tell them that in order to prevent this kind of tragedy in the future, all NATO and field hospital medical teams need to have 9 data fields: patient demographics, past medical history and allergy information. If they can get that info in a timely manner, many lives could be saved.
The architects are excited. They take what they have learned and translate it into specific data and system requirements. Then they take their new package of requirements to leadership, explain the situation, gain approval, and express that information in the DoD Enterprise Architecture. From that point forward, the 9 data field requirement sits in the model in a place where the affected data exchange between DoD electronic medical records and NATO and field hospital units is represented.
Staff can come and go. Everybody in the investment review process may know nothing about what happened to our unfortunate fallen soldier. It doesn't matter! From this point forward, every relevant business IT investment that comes through the investment review process will be subjected to a requirement to carry those 9 data fields. Every affected business IT system will, from that point forward, be forever altered to make sure that those 9 data fields are available for the medical teams who need them. The problem that caused a soldier to die is eliminated!
Back to our legal language: by doing this, we just satisfied section (d) (2) by inserting "Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense."
If we treat compliance in this way, Enterprise Architecture compliance becomes compliance with Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense. We will deliberately eliminate real world problems - one investment at a time.
Isn't this a better compliance standard to live up to than compliance with a model?
To listen to a 10 minute audio podcast I made on this subject a couple of years ago, click the following link: http://www.health.mil/dbt/downloads/The%20Power%20of%20EA.mp3
Using a standard notation is also theoretically useful to decision makers and personnel from different organizations because it creates a "common currency" for exchanging ideas and communicating with one another. The thought being - if you understand the notation, you can find your way around anyone's model in a short amount of time. Why do we need to do that?
It is not uncommon for decision makers to wonder, "If I make X decision..:"
- Who might be affected?
- What systems might be affected?
- What resources might be affected?
- Would we break something?
- What would give me the biggest bang for my buck?
- What information is available in the Enterprise to help me measure progress against a particular goal or objective?
In theory, the enterprise architecture model was designed to help answer these questions. It can be a useful tool when used in a large enterprise like the Department of Defense, or in one of the sub-components of the Department of Defense like the Army, Navy, Air Force, Marine Corps, etc.
Title 10 of the United States Code § 2222 requires that all Department of Defense business IT investments (modernizations, enhancements or development efforts) assert "compliance" with the Enterprise Architecture (EA). Without "compliance," there will be no authority given to spend money on an investment. If there is no "obligation authority" granted by the Defense Business Systems Management Committee (as defined by 10USC§186), then someone is eventually going to jail, paying a fine, or getting relived of duty.
The actual language states:
"(a) CONDITIONS FOR OBLIGATION OF FUNDS FOR DEFENSE BUSINESS SYSTEM MODERNIZATION. — Effective October 1, 2005, funds appropriated to the Department of Defense may not be obligated for a defense business system modernization that will have a total cost in excess of $1,000,000 unless—
"(1) the approval authority designated for the defense business system certifies to the Defense Business Systems Management Committee established by section 186 of this title that the defense business system modernization—
"(A) is in compliance with the enterprise architecture developed under subsection (c);
This notion of "compliance" with the architecture has been the subject of many debates since the law went into effect. People wonder what they have to be compliant with: the model? the content? the need to draw diagrams?
We get a clue from language later in the same statute. It tells us what content needs to be in the Enterprise Architecture:
"(d) COMPOSITION OF ENTERPRISE ARCHITECTURE. — The defense business enterprise architecture developed under subsection (c)(1) shall include the following:
"(1) An information infrastructure that, at a minimum, would enable the Department of Defense to—
"(A) comply with all Federal accounting, financial management, and reporting requirements;
"(B) routinely produce timely, accurate, and reliable financial information for management purposes;
"(C) integrate budget, accounting, and program information and systems; and
"(D) provide for the systematic measurement of performance, including the ability to produce timely, relevant, and reliable cost information.
"(2) Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense."
Based on my personal experience, having conducted due diligence on more than $1 Billion of these investments, this is 1. apparently not clear enough and 2. not translating into direct benefits to the Department.
Most of the letters that I've seen assert "compliance" with the architecture are representing little more than the fact that that there is a diagram of the investment being reviewed (often referred to as solutions architecture) drawn, and that this diagram somehow has the same or similar words on it as can be found in the diagram of the Enterprise Architecture. The fact that an investment is or is not documented as compliant with the architecture has had little or no effect on business as usual. It mostly means that the file folder of paperwork on that investment just got a little heavier (due to the weight of the added diagrams and a piece of paper that says the diagrams are there). That's it.
It's not useful to anyone to spend the number of hours (and dollars) one must spend on creating a diagram as detailed as a solutions architecture - only to have it visually and semantically mapped to another diagram and make a file folder heavier. I've witnessed intelligent people spending days just changing the color scheme of boxes so that one model looks like the other. Then, when the colors are matched and the right box is in the middle of the paper, step forward and proudly proclaim "We're compliant with the architecture!"
What they really mean is they are compliant with the methodology described in the Department of Defense Architecture Framework and have found a way to make the words between the two models look the same.
What we need is a healthy dose of reality. If we can find a way to inject reality into these models, they can be extremely useful.
By way of example, let's assume that something bad happens somewhere in a theater of operations. As a former combat medic, I'll use a medical situation to illustrate my point.
A soldier is severely wounded by a road side bomb. He receives shrapnel wounds to his neck and, because there is a short window of time to treat this soldier, he is air lifted to a local NATO alliance facility. The doctors there examine him, rush him up to the operating room, repair his wound and 10 minutes later, the soldier is dead.
The medical teams are initially confused because although the wounds were serious, they were immediately controlled and the soldier appeared otherwise strong. By all accounts, this soldier should have survived. An investigation is started.
After the investigation is complete, it is determined that the soldier died from an allergic reaction to the anesthesia administered in the operating room. The NATO team did not have access to the soldier's medical records, his past medical history, or a record of what he was allergic to. The severe blood loss made this soldier much less capable of handling the allergic reaction. He died.
The report gets filed in a lesson's learned database, and is recovered by a team of proactive architects a year or two later. They read through the case with great interest. It seems to them that they have found a data sharing problem that can be solved.
They contact some military doctors, share what they've found and get their feedback. The doctors tell them that in order to prevent this kind of tragedy in the future, all NATO and field hospital medical teams need to have 9 data fields: patient demographics, past medical history and allergy information. If they can get that info in a timely manner, many lives could be saved.
The architects are excited. They take what they have learned and translate it into specific data and system requirements. Then they take their new package of requirements to leadership, explain the situation, gain approval, and express that information in the DoD Enterprise Architecture. From that point forward, the 9 data field requirement sits in the model in a place where the affected data exchange between DoD electronic medical records and NATO and field hospital units is represented.
Staff can come and go. Everybody in the investment review process may know nothing about what happened to our unfortunate fallen soldier. It doesn't matter! From this point forward, every relevant business IT investment that comes through the investment review process will be subjected to a requirement to carry those 9 data fields. Every affected business IT system will, from that point forward, be forever altered to make sure that those 9 data fields are available for the medical teams who need them. The problem that caused a soldier to die is eliminated!
Back to our legal language: by doing this, we just satisfied section (d) (2) by inserting "Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense."
If we treat compliance in this way, Enterprise Architecture compliance becomes compliance with Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense. We will deliberately eliminate real world problems - one investment at a time.
Isn't this a better compliance standard to live up to than compliance with a model?
To listen to a 10 minute audio podcast I made on this subject a couple of years ago, click the following link: http://www.health.mil/dbt/downloads/The%20Power%20of%20EA.mp3
Subscribe to:
Posts (Atom)