A friend wished me a "Happy Veteran's Day" at 1201 this morning. He was the first to send such a wish in my direction this year. A fellow veteran, I replied "Happy Veteran's Day" back, but somehow the word "Happy" just doesn't feel like it belongs.
Maybe it's the rain and clouds this morning. Maybe it's the recent bloody attack at Fort Hood, or my memory of the young man with the artificial leg that I walked past the other day on base, or the gradual change in personality I see in our troops - strong and sobering evidence of the burden our men and women in uniform must bear on behalf of this nation. For whatever reason, this Veteran's Day has more of a memorial feel to it for me. It is what it is.
We celebrate the brave men and women who have served this country in a special way. We celebrate the side of human nature that is willing to sacrifice everything - not just for a cause, but for the man or woman beside them or the memory of someone's love. We celebrate the courage that thousands of men and women have found in dark hours that has empowered the human race to stand against the most savage stuff this world can serve up - ourselves.
Every veteran has stood the watch. Read some good material on standing the watch: [Sailor, Soldier]
For me at least, the day is more personal than a casual "Happy Veteran's Day." It's a day to remember faces and moments. It's a day to remember routines; personal victories; hospital corners; the correct way to put toilet paper on a roll; dark nights thinking about sacrifice and wondering if I would have the courage and presence of mind to do what needed to be done when it was my turn; the neon buzz of lights coming on a 4AM; smells of Hoppe's #9, boot polish, and bleach; left foot first; and "DRESS RIGHT! HUH!"
I personally celebrate Veteran's Day every time I look in the mirror and check my gig line, when I'm shining my shoes, when I jingle the dog tags in my pocket, and even when I find it hard to fall asleep when I am super tired. I am both proud of the commitments I made and of the company I kept. And I regret that I didn't give more. As a veteran, I doubt I'm alone when I say it's hard to feel like I gave enough when I see so many who gave so much more.
This morning, just like last year, I raised the flag with my daughter - she ran to the front door hollering "Wait, Daddy! I want to help you!" We unfurled that flag and despite our civilian clothes, we both saluted.
A blog dedicated to Defense Business Transformation. This blog does not represent official Government opinion or policy.
Wednesday, November 11, 2009
Tuesday, November 3, 2009
Acquisition Professionals: VIP's on the Transformation Team
I podcasted on this subject about a year or so ago, but I believe it bears mentioning again: Without the Acquisition community's help, we're going to have a really difficult time with Defense Business Transformation.
I'm not just talking about the Acquisition policy makers. I'm talking about every person supporting the Acquisition process - from the one's who write the policy, to the COTR's and PM's who keep an eye on things. Everyone.
Groups of action level folks wearing titles such as KO (Contracting Officer), COR (Contracting Officer Representative), COTR (Contracting Officer Technical Representative), and TM (Task manager), all have significant contributions to make. These contributions are not limited to the absolutely necessary functions they already perform. I'm talking about saving the government a lot of money and wasted time. Minor changes to the way things are already being done will make a huge difference to Transformation efforts. We need to remember these folks and give them the training they need to be VIP members on the Transformation team.
First, these professionals need to be read in on the new application of the Anti-Deficiency Act (ADA). Every KO, COR, COTR and TM knows well what an ADA is: a section, 1341 (a), of legislation that uses words like "jail," "fines," and mean relief of duty. Everyone in the acquisition business got a primer on it during initial training. In short, an ADA violation is something to be avoided at all costs.
Few know, however, that the ADA has been recently (October 2005) applied to business IT projects for not asserting compliance against the Enterprise Architecture. Few understand that the act of doing their own thing with business IT projects - irrespective of their contracting authority - can land them into a career ending ADA violation that maybe hasn't caught up with them yet.
Of those that do know (I personally trained more than 80 COR's in a 3 month period) few realize that a few small changes to a Statement of Work (SOW) can save thousands or hundreds of thousands of dollars and many months of paperwork. By simply requiring contractors to submit their deliverables in DoDAF (DoD Architecture) format, the solutions architecture that is needed to assert compliance will not have to be created by a separate contract line item (CLIN, government employees, or a new contract.
Compliance assertion can happen throughout the lifecycle of the project on an annual basis. This assures both a finished project that is compliant with current and emerging DoD design specifications and constraints, AND a whole lot less time and aggravation that comes from having to re-create paperwork after the fact.
Talk about demonstrable cost savings? The average time for a certification project to get from my office (the first time I saw a project) to having certification in hand was 71 days. Most of those 71 days were spent chasing down accurate and complete paperwork, educating people along the way, and getting someone to submit the solution architecture for a project. If contractors had been asked to submit their design proposals in DoDAF format up front, we could have easily shaved weeks off the certification process and made the certification process a lot more about design and the business case and a lot less about getting the paperwork right.
How many KO's understand that a lack of obligation authority means that a project isn't legally going anywhere? I'm talking about at the time of initial certification and again at each an every annual review (not less than 12 months from initial or annual certification).
All KO's know that not timing the renewal of a contract correctly could be a deal killer, but not timing the initial certification or the annual re-certification could be just as bad. Dead is dead. Without both money in the checkbook and obligation authority, business IT modernization, development or enhancement is not allowed to proceed in the DoD without facing an ADA violation.
How many business IT projects are NOT about development, enhancement or modernization? Precious few are pure sustainment efforts. Oh I know people sometimes call modernization "sustainment" because they claim a project would die if it doesn't keep pace with the world. Believe me, I've heard it. that's a way of getting around the system.
But 10USC2222 was not enacted to create another byzantine paperwork drill that we should do our best to avoid. It was created to give us the leverage we need to force systems throughout the Department, on penalty of ADA, to become compliant with standards that enable interoperability, data exchange; and to empower leadership to force the sum total of the IT asset portfolio to support DoD priorities like visibility of personnel, finances and materiel, etc. instead of skunks works, cherry picked requirements building efforts, and pet projects.
We want these Transformation systems (investment review, enterprise architecture, annual review, etc.) to work in order to empower decision makers to make better informed decisions - to spend smarter - to create some continuity over time - to stop duplication and sub-optimized efforts in all Components - to gain some control over the spaghetti mess of IT spending across the Department and re-direct resources that are currently being wasted by poor or conflicting decisions to areas where resources are sorely needed - to enable the real mission of the DoD.
If you are a DoD acquisition professional or if you know one, get the documents into their hands. The documents explain the law and the implications pretty clearly.
Keeping out of trouble and moving the DoD towards interoperability, continuity, and data sharing isn't as difficult as some would have us believe. From an Acquisition professional's perspective, adding a paragraph or two to a SOW (e.g. A. Contractors shall prepare proposed solutions architecture models using DoDAF format B. solutions submitted for consideration will be compliant with X standards as expressed in the DoD Business Enterprise Architecture) and changing the wording on relevant deliverables tables from "Word" or "Excel" format to 'DoDAF" format are really a pretty simple maneuvers.
Adding the words "Certification" and "Annual Review" to a project calendar is pretty easy too. Backing up the proper amount of time from those calendar entries and setting a reminder or two in order to make sure there is sufficient time to conduct a solid "due diligence" review is good for the project and good for the DoD.
If we can get this word out to the Acquisition community and the Acquisition community makes a few simple changes, time and cost savings would be enormous. This would put the acquisition community one more time in the VIP seat on the Transformation team.
I'm not just talking about the Acquisition policy makers. I'm talking about every person supporting the Acquisition process - from the one's who write the policy, to the COTR's and PM's who keep an eye on things. Everyone.
Groups of action level folks wearing titles such as KO (Contracting Officer), COR (Contracting Officer Representative), COTR (Contracting Officer Technical Representative), and TM (Task manager), all have significant contributions to make. These contributions are not limited to the absolutely necessary functions they already perform. I'm talking about saving the government a lot of money and wasted time. Minor changes to the way things are already being done will make a huge difference to Transformation efforts. We need to remember these folks and give them the training they need to be VIP members on the Transformation team.
First, these professionals need to be read in on the new application of the Anti-Deficiency Act (ADA). Every KO, COR, COTR and TM knows well what an ADA is: a section, 1341 (a), of legislation that uses words like "jail," "fines," and mean relief of duty. Everyone in the acquisition business got a primer on it during initial training. In short, an ADA violation is something to be avoided at all costs.
Few know, however, that the ADA has been recently (October 2005) applied to business IT projects for not asserting compliance against the Enterprise Architecture. Few understand that the act of doing their own thing with business IT projects - irrespective of their contracting authority - can land them into a career ending ADA violation that maybe hasn't caught up with them yet.
Of those that do know (I personally trained more than 80 COR's in a 3 month period) few realize that a few small changes to a Statement of Work (SOW) can save thousands or hundreds of thousands of dollars and many months of paperwork. By simply requiring contractors to submit their deliverables in DoDAF (DoD Architecture) format, the solutions architecture that is needed to assert compliance will not have to be created by a separate contract line item (CLIN, government employees, or a new contract.
Compliance assertion can happen throughout the lifecycle of the project on an annual basis. This assures both a finished project that is compliant with current and emerging DoD design specifications and constraints, AND a whole lot less time and aggravation that comes from having to re-create paperwork after the fact.
Talk about demonstrable cost savings? The average time for a certification project to get from my office (the first time I saw a project) to having certification in hand was 71 days. Most of those 71 days were spent chasing down accurate and complete paperwork, educating people along the way, and getting someone to submit the solution architecture for a project. If contractors had been asked to submit their design proposals in DoDAF format up front, we could have easily shaved weeks off the certification process and made the certification process a lot more about design and the business case and a lot less about getting the paperwork right.
How many KO's understand that a lack of obligation authority means that a project isn't legally going anywhere? I'm talking about at the time of initial certification and again at each an every annual review (not less than 12 months from initial or annual certification).
All KO's know that not timing the renewal of a contract correctly could be a deal killer, but not timing the initial certification or the annual re-certification could be just as bad. Dead is dead. Without both money in the checkbook and obligation authority, business IT modernization, development or enhancement is not allowed to proceed in the DoD without facing an ADA violation.
How many business IT projects are NOT about development, enhancement or modernization? Precious few are pure sustainment efforts. Oh I know people sometimes call modernization "sustainment" because they claim a project would die if it doesn't keep pace with the world. Believe me, I've heard it. that's a way of getting around the system.
But 10USC2222 was not enacted to create another byzantine paperwork drill that we should do our best to avoid. It was created to give us the leverage we need to force systems throughout the Department, on penalty of ADA, to become compliant with standards that enable interoperability, data exchange; and to empower leadership to force the sum total of the IT asset portfolio to support DoD priorities like visibility of personnel, finances and materiel, etc. instead of skunks works, cherry picked requirements building efforts, and pet projects.
We want these Transformation systems (investment review, enterprise architecture, annual review, etc.) to work in order to empower decision makers to make better informed decisions - to spend smarter - to create some continuity over time - to stop duplication and sub-optimized efforts in all Components - to gain some control over the spaghetti mess of IT spending across the Department and re-direct resources that are currently being wasted by poor or conflicting decisions to areas where resources are sorely needed - to enable the real mission of the DoD.
If you are a DoD acquisition professional or if you know one, get the documents into their hands. The documents explain the law and the implications pretty clearly.
Keeping out of trouble and moving the DoD towards interoperability, continuity, and data sharing isn't as difficult as some would have us believe. From an Acquisition professional's perspective, adding a paragraph or two to a SOW (e.g. A. Contractors shall prepare proposed solutions architecture models using DoDAF format B. solutions submitted for consideration will be compliant with X standards as expressed in the DoD Business Enterprise Architecture) and changing the wording on relevant deliverables tables from "Word" or "Excel" format to 'DoDAF" format are really a pretty simple maneuvers.
Adding the words "Certification" and "Annual Review" to a project calendar is pretty easy too. Backing up the proper amount of time from those calendar entries and setting a reminder or two in order to make sure there is sufficient time to conduct a solid "due diligence" review is good for the project and good for the DoD.
If we can get this word out to the Acquisition community and the Acquisition community makes a few simple changes, time and cost savings would be enormous. This would put the acquisition community one more time in the VIP seat on the Transformation team.
Saturday, October 31, 2009
Happy Halloween!
Everyone deserves to be a little frightened on Halloween day. A little government humor to do the trick (or treat). Enjoy and have a great weekend!
Thursday, October 29, 2009
Your Turn to Be Heard!
I like Blogs for their ability to put information out, but they are pretty bad at getting information back in. Defense Business Transformation isn't about me or any single agency. It's about you.
Tell us about you and your ideas and suggestions for Defense Business Transformation. We really want to know. Simply click this link and post your suggestions or vote on other people's suggestions! It's easy!
Tell us about you and your ideas and suggestions for Defense Business Transformation. We really want to know. Simply click this link and post your suggestions or vote on other people's suggestions! It's easy!
Monday, October 26, 2009
Perspective
"So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!"
I have come to believe that business transformation is like the Indian Elephant Story. Over the years, I've spoken with and listened to many different "customer" groups. Each group of customers I encountered seemed to carry similar perspectives or bias about the program. Perspective, I've found, really depends on what part of the Transformation elephant a person is standing next to. I've developed a sense for text I read and speeches I hear. I can usually tell which community wrote a piece or delivered a speech based on the language and assertions.
The acquisition community, the program management community, the leadership community, the architecture community, the financial community, the GAO, the Joint staff... each has their own slant. Some are more vocal than others. All are correct from their perspective.
Trying to present the whole elephant is difficult to do when the "ear" group is hollering at the "tail" group, who is hollering at the "trunk" group, etc. As one trying to understand the whole elephant, you may find that the hollering back and forth between the "ear" people, the "trunk" people and the "tail people, etc can get pretty loud and confusing.
The subject is important enough to read about, but I advise the researcher to read from a variety of sources and look for the problem and the root cause of the problem that we are trying to solve. Consider that every published work - including my own, is a perspective.
Look at what the IBM group wrote about Business Transformation here.
See some of the other stories I've posted from GAO reports, congressional testimony, etc here.
You have this Blog to browse through. And I encourage you to take a look at another piece of the Business Transformation elephant as well - the one from the Army's perspective.
Friday, October 23, 2009
Mashups, SOA and Cloud Computing
It's almost impossible to be around technology people for very long before one of them uses the words "Mashup," "SOA" or "Cloud Computing." When this happens to me, I usually smile and spend at least some of the time wondering why the audio portion of my brain disconnected again. Maybe it's distracted by my visual cortex which almost immediately starts flashing a little neon sign that alternates between "get to the bottom line," "is this for real this time?" and "can this do something for the business?"
I work around a lot of technologists, so I get a lot of technology buzz words hurled at me. I've gotten pretty good at reading between the lines to what they are really trying to say to me, but I have to admit that as I get older, my patience declines.
Today, I'm writing this both as a way to thank those technology weenies - in truth, we'd be suffering without them, and to lead into what I believe is an indication that technology is finally about to deliver on its promise.
I've embedded two videos below. Taken together, I think they summarize the technical portions of where the weenies are today.
I'm excited by this for a number of really good reasons: 1. We spend WAY too much on big central programs today that no longer have to exist in their Byzantine state - sucking resources from other needed programs and making us all feel guilty for pouring good money after bad. 2. entrepreneurial technology savvy problem solvers can now mix and match technical "building blocks" in ways that allow them to solve real problems in real time without breaking the bank or setting off security bombs. For them, agility is finally within reach.
Video # 1 is mostly about mashups, but the folks at JackBe do a great job explaining what these are and what SOA is about. With a little imagination, I was able to see at least a dozen ways that I could put these to work in an enterprise - and I bet if I did the math, that I could see hundreds of millions (I am not exaggerating) worth of tax payer savings as a result of employing this technology in lieu of the Byzantine central systems we have deployed (or have been trying to deploy) today.
I could see, for example, being able to make financial data available in a mashup from legacy data sources to business leaders and decision makers throughout the DoD relatively easily. I could see sharing medical data (with the proper security service at work) with doctors between the VA and the DoD - with the DoD and managed care (civilian) providers. What possibilities do you see?
This second video talks more about "Cloud Computing." This version of the cloud computing discussion might be useful in thinking of new ways to budget for IT services in the future. Presuming we are capable of making the transition to mashups and a cloud computing model, how much might we save? You decide.
I'm not suggesting that we got it all wrong and need to throw away all that we've done in past years. I am suggesting that technology is evolving faster that we are. By the time we get some Byzantine system deployed, technology guru's will be looking back at us, shaking their heads and maybe feeling sorry for us. We should be stacking these lighter, more efficient design models against our battleship design models and see what happens. The ingredients to do this already exist. We can only win for trying.
I work around a lot of technologists, so I get a lot of technology buzz words hurled at me. I've gotten pretty good at reading between the lines to what they are really trying to say to me, but I have to admit that as I get older, my patience declines.
Today, I'm writing this both as a way to thank those technology weenies - in truth, we'd be suffering without them, and to lead into what I believe is an indication that technology is finally about to deliver on its promise.
I've embedded two videos below. Taken together, I think they summarize the technical portions of where the weenies are today.
I'm excited by this for a number of really good reasons: 1. We spend WAY too much on big central programs today that no longer have to exist in their Byzantine state - sucking resources from other needed programs and making us all feel guilty for pouring good money after bad. 2. entrepreneurial technology savvy problem solvers can now mix and match technical "building blocks" in ways that allow them to solve real problems in real time without breaking the bank or setting off security bombs. For them, agility is finally within reach.
Video # 1 is mostly about mashups, but the folks at JackBe do a great job explaining what these are and what SOA is about. With a little imagination, I was able to see at least a dozen ways that I could put these to work in an enterprise - and I bet if I did the math, that I could see hundreds of millions (I am not exaggerating) worth of tax payer savings as a result of employing this technology in lieu of the Byzantine central systems we have deployed (or have been trying to deploy) today.
I could see, for example, being able to make financial data available in a mashup from legacy data sources to business leaders and decision makers throughout the DoD relatively easily. I could see sharing medical data (with the proper security service at work) with doctors between the VA and the DoD - with the DoD and managed care (civilian) providers. What possibilities do you see?
This second video talks more about "Cloud Computing." This version of the cloud computing discussion might be useful in thinking of new ways to budget for IT services in the future. Presuming we are capable of making the transition to mashups and a cloud computing model, how much might we save? You decide.
I'm not suggesting that we got it all wrong and need to throw away all that we've done in past years. I am suggesting that technology is evolving faster that we are. By the time we get some Byzantine system deployed, technology guru's will be looking back at us, shaking their heads and maybe feeling sorry for us. We should be stacking these lighter, more efficient design models against our battleship design models and see what happens. The ingredients to do this already exist. We can only win for trying.
Wednesday, October 14, 2009
Leverage!

The concept of leverage is one of the most useful tools in our collective tool boxes. It's a term that is used by both commercial business enterprise and by Feds, and it's one of a few such concepts that seems to translate pretty well between the two.
People usually conjure an image of guy with a long pole moving a huge rock. The guy sticks one end of the stick under the huge rock, levers it against some kind of fulcrum near the rock, then uses the added leverage of the long pole to use his relatively tiny weight to move the big rock.
The Department of Defense is HUGE rock. If we are to move that rock, we will need to become experts on the concepts of leverage and teamwork.
Merriam Webster defines Leverage as:
1 : the action of a lever or the mechanical advantage gained by it
2 : power, effectiveness
3 : the use of credit to enhance one's speculative capacity
I like to think of leverage as a force multiplier. Leverage involves using tools and systems around us to ensure the absolute highest and best use of our time and resources.
Investopedia says Leverage is 1. The use of various financial instruments or borrowed capital, such as margin, to increase the potential return of an investment.
Try to make a program like Defense business Transformation work in the DoD and you will quickly find yourself feeling like a very small fish in a very big sea.
"Transform the DoD?! A world-wide organization so full of honorable tradition, power pockets, strong personalities and about 7 miles of bureaucratic forms to wade through?!"
To the Transformation minded, this task will at times seem like a hellish version of Mission Impossible. A key to making it work is leverage.
Investopedia explains Leverage
1. Leverage can be created through options, futures, margin and other financial instruments. For example, say you have $1,000 to invest. This amount could be invested in 10 shares of Microsoft stock, but to increase leverage, you could invest the $1,000 in five options contracts. You would then control 500 shares instead of just 10.
The right leverage is important. In the Business Transformation game, the best kinds of leverage often come from other people. Don't try to make everything happen yourself. Good government is a team sport. Going about this alone is like taking on the Green Bay Packers by yourself. You'll be dead before the end of the first quarter.
Don't reinvent the wheel. It's smart to find examples of Transformation going well elsewhere in the Department, then to pick up the phone and introduce yourself. Often you'll find lots of work that's already been done that you can leverage to make your own program successful faster. Leveraging work that's already been done is a smart way to get past the basics and get working on the things that are specific to your situation - like local leadership priorities and challenges.
Next, create assets that work for you while you sleep. If you have a choice to spend your budget (or convince someone to spend their budget) on doing more work (like conducting investment reviews) or creating a system to teach others how to do the work - chose the latter. Once you create a system and commit that system to paper, a CD, a DVD, a Web site or some other distributable media, you can work on getting that media into the hands of your target markets and empowering them to be successful. My former Web site is full of examples of these kinds of "build once, use many" assets. Let them do the work of Transformation!
This approach provides you with a secondary benefit: Everyone who "buys" or adopts your system will be starting with roughly the same foundation. This means some level of standardization will be occurring across organizations. Organizations that start in the same place will at least share a common vocabulary, even if the execution of the system in different organizations eventually becomes a variation of the original.
When I was responsible for Defense Business Transformation within the Military Health System, I had a small $2.4 million budget, three sub organizations: Army Medicine, Navy Medicine and Air Force Medicine to serve, and $1.4 billion worth of identified annual investments to review (or disqualify from review).
This was an impossible task for my small team to do alone. However, by reaching out to Transformation agents within each of the three Service Medical Departments and empowering them to "franchise" our DBT office into their organizations, the effective man hours applied to the task was multiplied four fold. We used our Web site, weekly meetings, guide books, evaluation frameworks, CD's, brochures, and other materials to get them the information they needed to be successful.
There will also be people who really don't like having transformation zealots around. So put them to work too! By leveraging the environment around us (and a little basic human nature), we hung little bits of one-ups-man-ship out there as motivation. We either goaded these kinds of people into trying to outperform us, or we let it "slip" into the grape vine that we had something cool going on (whether we did or not) - which in turn "made" them do whatever we said we were doing even better! All the while, we had a strategic plan with the desired outcomes clearly described.
Policies and signatures are also great leverage tools. If you can craft a policy, revise a policy revision and/or get a signature on a policy or a guidance document, you can appeal to a whole new class of leadership and Transformation Agents. There are some people who only respond when they see a signature. There are some people who only respond to what they consider the "right" signature.
Note: I find the signature and policy method to be my least favorite method of leverage. It's not that I don't like policy or signed guidance - I'd love it! If you follow DOTMLPF, policy (Doctrine) change is first in line and is supposed to be the least expensive solution. In a perfect world, signing out a well crafted policy is the best way to go. In reality, "winning" a signature means running a gauntlet filled with political agendas, compromise, ego induced red ink, and inevitable ring kissing. When you get the signature, you will sometimes find that the people you most want to influence don't recognize the signature you got. Bad blood between two signature authorities can send your entire project spinning back to "start" like getting a bad card in Candyland. Tip: Don't get into the signature chasing game unless you're prepared to settle in for a while. It's a full time job and you will never get all the signatures that everybody wants.
My point is this: find ways to put the environment around you to work. Find things that you can do that cost you a little, but gain you great benefits. Use the talent of people who have come before you or share similar interests in transforming their environment. Spend a little time to commit your ideas or systems to some kind of sharable media. Find a way to influence a policy that you think needs a change. By doing a few strategically intelligent things and leveraging the resources around you, you will have a tremendous impact on the environment around you!
Subscribe to:
Posts (Atom)