Taking The Bullet

So I learned many valuable lessons when I worked at the U.S. Secret Service–I loved it there!

But one of the lessons that sticks out it that sometimes you have to take a bullet for the President!

This lesson stayed with me and I believe it applies to a lot of other situations in life as well.

Sometimes you take one for the 

– Team

– Cause

– Relationship  

It’s easy to say you are going to preserve you self by “dodging a bullet,” but often it’s really just the opposite that is needed. 

If you take the bullet, you are putting yourself subordinate to a larger cause and what is really important. 

Taking one to safeguard the President of the United States is definitely a larger cause. 

But also your team, the success of an important cause or project, precious relationships that have been built over time–these can all mean more than taking even a significant hit. 

This doesn’t mean to be stupid, become anyone’s punching bag or just take people’s sh*t for nothing. 

Rather what it does mean is that you can suck it up sometimes–when the ends justify the means–and jump in front of that bullet to preserve something bigger and more important than just yourself. 

(Source Photo: Andy Blumenthal)

>Enterprise Architecture: Program or Project?

>Enterprise Architecture is a program with many phases and projects.

Several times in my career, I have been brought in to develop an enterprise architecture for an organization, and just about every time, the boss has asked how long will it take, when will it be done, or some other similar version to time-bind the effort.

However, for those of us who are practitioners in the field of EA, we know resolutely the answer is that EA is never done.

Legally, EA is mandated by the Information Technology Management Reform Act (a.k.a. the Clinger-Cohen Act). As such, it is not a one-time event, but an ongoing requirement, and thus an established program in every department of the federal government.

But more than that, EA defines the current, target, and transition plans for an organization. And by definition, a current and target are just snapshots in time, which are in essence outdated a moment after you publish (just like when you drive a new car off the dealer lot and it immediately becomes “used.”) That is, an organization, its business and technology, are constantly evolving and in a state of flux, responding to internal and external factors (such as new mission challenges, business opportunities, congressional or executive mandates, changing customer expectations, new technologies, and so on). So in an ever-evolving organization, the “current” state does not stay current, and the “target” does not stay current (up to date). That is, unless you place these under “maintenance,” i.e. you refresh these on a periodic basis, and make course corrections along the way.

Further, developing and maintaining an EA for any organization is a challenging task, especially for a large and complex organization (like many in the federal government). As such, EA efforts need to be broken down into smaller projects to be successful. And these projects need to be clearly defined in terms of scope, schedule, and performance measures and managed for all project knowledge areas (reference: Project Management Book of Knowledge).

So the next time your boss asks you, “When will the EA be done?” I suggest you tell them: “The EA is a program with many phases and projects. Phase (#) is scheduled to roll out (date).”

Has this ever happened to you – that your boss asked you when the EA would be finished? What did you say/do?