Showing posts with label requirements management. Show all posts
Showing posts with label requirements management. Show all posts

December 19, 2018

Project Management - The Best Day

So a colleague said something interesting to me about project management:
The best day of project management is usually the first day, but I want to show you that the best day is really the last day of the project.
And as I thought about this, I sort of starting laughing to myself and thinking, you know what, I think this guy has something here. 

- Day 1 of a project, everyone is usually all bright-eyed and bushy-tailed. 

We're embarking on an adventure together to build something new for the organization and our customers. 

We're going to team up and everyone will contribute.

And out of the project sausage maker--poof!--like magic comes a new system or product. 

- But as we all know, things don't always go so smoothly.

With some projects, the pretty smiley faces of day 1 may quickly turn to ugly frown faces.

There is analysis paralysis, scope creep, conflicting or changing priorities, resource issues, technical challenges, or the sausage just doesn't come our right--oh sh*t!

Thus, many  projects end up going bust in terms of cost, schedule, or performance. 

That is, they end up costing too much, being delivered behind schedule, or just not meeting the performance requirements. 

You have some projects that never even truly get off the ground, have multiple resets, or get dumbed-down or even cancelled altogether along the way. 

So by the time you reach the last day of the project, many people seem like they've been through the project ringer. 

I'm sure that I've heard more than one project manager say:
Just take me out back and shoot me!

So when this colleague said that he wants the best day of the project to be the last--in terms of satisfaction with the project (not that that pain was finally over!)--I really appreciated this as an awesome goal. 

We should all look to the last day of our projects as the best--one where we can look back and say: 
Wow, great job everyone!  We really got something great done here--and we did it right!  ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

December 11, 2018

You Can't Eat The Elephant

So there is a popular saying:

"You can't eat the elephant in one bite."

The idea is that you need to break things down in little pieces to get them down. 

If you try to eat the elephant in one bite, I assume that your mouth would easily split in half and your face would literally explode. 

Similarly with projects, if you try to get to the nirvana end state in one fell swoop , the project explodes with complexity and risk, and you will fail miserably.

Thus, managing requirements and phasing them in chunks is critical to projects' succeeding. 

Sure, customers want to get the Promised Land immediately--where the projects have all the "bells and whistles"--but you don't want to sacrifice getting the train on the tracks for the accouterments either. 

Think big, but act small--little by little, one step at a time, you can actually eat an elephant. ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

November 29, 2018

Say YES!

Really liked this sign on my colleague's desk.

It says:
Start With Yes

I remember an old boss who used to say:
Don't make me get through no to get to yes. 

The idea as another colleague put it is to:
Keep a smile on your face and your focus on the customer; everything else takes care of itself. 

Basically, it's all our jobs to make sure that the customer's needs are being met. 

That doesn't mean that we don't need to differentiate between requirements and desirements or that we need to deliver the yacht in the first go around.

As a 4th colleague put it:
The customer is in the water. They want the yacht. But I can give them a boat. It gets them to where they want to go, and they no longer need to swim. We can work our way up to a yacht.

Good analogy analogy and good things to keep in mind for customer service excellence! ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

September 22, 2018

Snowflakes Are Unique

Thought this was an interesting analogy. 

A colleague refers to some customers as snowflakes.

At first, I didn't get it. 

Then I understood. 

Every snowflake is unique. 

Based on how the ice crystals fall to the ground through different temperatures, moisture levels, and atmospheric pressures, the shape of every snowflake is different. 

Sometimes when it comes to project management, customers too think they are unique, different, and special.

They think that solutions that work industry- or enterprise-wide could never work for them and their wholly distinct ways of doing business. 

Hence, as I learned, the term snowflake. 

For those of us who have been around the project management block a few times, we know that while there are specific customer requirements, most of them are not all that unique. 

And when some customers simply don't want to do things differently than they've done it before, there can be greater resistance to change. 

Hence, the "We're special. We're different" reframe along with the standoffishness, doubting, circling the wagons, throwing up obstacles, or just refusing to fully participate. 

Obviously, it's a lot more difficult to modernize and transform through technology and business process re-engineering when your customers aren't on board. 

So it is critical to manage organizational change, address the questions, the fears, and elements that are truly unique, and bring the people along as true partners. 

Not every requirement is a snowflake and neither is every customer, but we have to manage the similarities and differences in every project and make sure it improves performance and meets the needs of the customer and the organization. ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

June 2, 2018

Agile Doesn't Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.

But even in Agile, there is a beginning and an end to the sprint planning and project management.

Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 

Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 

Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).

We need to understand the difference between genuine customer service and irrational project exuberance. 

It's not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

April 14, 2018

Who You Calling Ugly Baby?

So in multiple organizations, I have heard systems referred to as ugly babies!

Whether or not it's true, it certainly doesn't make the IT folks that develop, run, and support that system feel very good. 

Are some of these (legacy) systems ugly?

Well, of course, they are. 

Many of them work despite themselves. 

What I mean by that is they are awkward to navigate and use. 

The functionality is flawed or outdated.

The workflows are unnecessarily complex.

The user interface is inconsistent and sloppy. 

The user experience is punishing. 

I told someone recently in using a particular system that was so convoluted:
"Is this system what they give to prisoners and make them use over and over again to punish them for hideous violent crimes?"

Seriously, that's how it felt, even as I knew it was still lightyears ahead of what a paper process still used in other organizations looks like.

Generally better than the waterfall methodology for the systems development life cycle, I understand that one dilemma with agile development is that requirements can be spotty from sprint to sprint and instead of doing the hard work and thinking it out upfront, users are made to expect a nearly endless series of enhancements and tinkering, which isn't practical functionally or financially either.

Even an ugly baby is still ours, and we love it and nurture it, and even help it change for the better--that's part of our responsibility. 

Whether we parented a real baby or an IT system, we have pride of ownership and a sense of accountability to the person, system, and future. 

My father always taught me never to throw out dirty water until you have clean water. 

Similarly, we shouldn't throw out the (ugly) baby with the bathwater. 

We need to work together--technologists and system users--to make truly functional systems and a user experience more like gaming where the players are so happy, attached (and even addicted) to it that they sometimes don't even get up to eat or go to the bathroom. 

We should love what we have and use, and we should, therefore, work hard to make these things great.

And an ugly baby can be made gorgeous again. ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

September 25, 2016

You Changing My What

So change agents are some of the most sought after...yet most abhorrent individuals on this planet. 

We all recognize that things can be better, and on one hand, we want someone to come and help us make it so...a change agent!

However, change is painful and frequently results in unintended and unwanted consequences, and so on the other hand, we hate change agents. 

Many change agents may not just change things that need to get changed and fixed, but they may change a lot of things that were working just fine before, thank you.  

Can anyone say reorganization? 

Moreover, change agents may not be changing things for the right reasons like the good of the organization.

Instead they may be self promoters, control freaks who have to do things their way, or they may be serial job hunters--next stop change everything and get the heck out of Dodge!

Change agents may work with people to get requirements, input, and vet the issues and the solutions or they may just be paying lip service to others, only to really shove their or someone else's agenda down your throats. 

You see there is healthy change that is based on genuine learning, growth, and maturity, and then there is change that is destructive, diabolical, and selfish. 

When you decide to change something, what's your motivation and your goal--is it to right the wrongs in the organization, reengineer business processes, and introduce new technologies or is it to change for change's sake alone. 

Yes, we did something. Check the box. Tell the management committee. We earned our keep and oh yeah, then some. We changed something, anything. Hip Hip Hooray. Bonus time!

So either you'll get an award and promotion or you'll get asked accusingly and threateningly, "Who told you to change that?!"

Change which has no real support or merit is dead on arrival (DOA), and will be gone, gone, gone long after the change agent is gone.

So don't freak out--the b.s. changes are either going to kill the organization or simply end up in Fresh Kills landfill.

The real changes may actually make you stronger. ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

September 6, 2016

Requirements Management 101

This was a funny Dilbert on Requirements Management. 

In IT, we all know that getting requirements can be like pulling teeth. 

No one either has time or desire to provide them or perhaps they simply don't know what they're really after.

Knowing what you want is a lot harder than just telling someone to automate what I got because it isn't working for me anymore!

In the comic, Dilbert shows the frustration and tension between technology providers and customers in trying to figure out what the new software should do. 

Technology Person: "Tell me what you want to accomplish."

Business Customer: "Tell me what the software can do."

In the end, the customer in exasperation just asks the IT person "Can you design [the software] to tell you my requirements?"

And hence, the age old dilemma of the chicken and egg--which came first with technology, the requirements or the capability--and can't you just provide it!

(Source Comic: Dilbert By Scott Adams)
Share/Save/Bookmark

January 25, 2016

Stack Theory Doesn't Stack Up

Christopher Mims' article in the Wall Street Journal today on why big companies get disrupted by others doesn't make a lot of sense to me. 

He discusses the "Stack Fallacy" of Anshu Sharma a venture capitalist that it "is the mistaken belief that it is trivial to build the layers above yours."

Mims explains that the stack is like a "layer cake of technology"--where one layer is built on another.

Similar to the OSI technology model where there are architecture layers for physical, data, network, application and so on. 

Basically, Mims explains that tech companies can only invent at a single layer of technology (or below). 

But when companies try to invent up the stack, they fail.

Here's why...

Mims says that companies despite their size and resources can't innovate up the stack because they don't understand the users there. 

But this doesn't stack up to me. 

Companies can and do use their resources to study and understand what users want up the food chain and what they can't easily build, they can acquire. 

Apple successfully went from a iPod and iTunes music player and song store to producing a highly sophisticated and integrated iPhone and Apps store where music is just an afterthought.

Similarly, IBM went from being primarily a mainframe and desktop company to being a top-tier consulting firm with expertise in cloud, mobile, social, artificial intelligence, and analytics computing. 

But it isn't easy for a company to change. 

And to me, it's not because they can't understand what users want and need. 

Rather, it is because of something we've all heard of called specialization. 

Like human beings, even extraordinary ones, companies are specialized and good at what they are good at, but they aren't good at everything. 

A great example of this was when NBA superstar, Michael Jordan, tried to take his basketball talents and apply it to baseball...he was "bobbling easy flies and swatting at bad pitches" in the minor leagues. 

As even kindergarteners are taught that "Everyone is good at something, but no one is good at everything."

Companies have a specific culture, a specific niche, a specific specialization and expertise.

And to go beyond that is very, very difficult...as IBM learned, it requires nothing less than a transformation of epic proportions. 

So I think Mims is wrong that companies can't understand what users want in areas up the innovation stack, but rather it's a monumental change management challenge for companies that are specialized in one thing and not another. 

So welcome to the world of Apple after Steve Jobs and his iPhone and to the the recent 25% decline in their stock price with investors and customers anxiously waiting for the possible but not certain next move up the technology stack. ;-)

(Source Photo: Andy Blumenthal)

Share/Save/Bookmark

September 22, 2015

Requirements, I Don't Know

This was a funny cartoon. 

Who are we?  

Clients!

What do we want?

We don't know!

When do we want it?

Now!

This is like way to many IT projects...

The customer knows they need to do something, because of changing market conditions, internal (dys)functioning, arising competition, or external mandates and regulations. 

But when the IT project managers and business analysts interview and ask the customer what they want and need to address these...quite often they get blank faces and hands raised in circuitous, endless doubt. 

What do the customers really want?

For IT to define, solve, and make their problems go away--and by the way do it yesterday and without any extra / proportionate resources

For some IT "professionals" that may be a little lacking themselves, you end up getting half-assed solutions to half-baked requirements that accomplish nothing or perhaps even break things more.

Hence, the true miracle of technology--to read minds and deliver valuable solutions to problems that no one could fully define to begin with! ;-)

(Source Cartoon: Roz Blumenthal @Facebook)
Share/Save/Bookmark

October 29, 2014

Who Makes Change Happen?

Well if "Station Managers do not make change" (happen), who does?

Personally, I like to see everyone think creatively about what they do and how they do it--looking for efficiencies and to create positive change, where warranted.


Not change for change itself...but where requirements have changed or methods and/or tools have changed to create opportunities or mitigate threats. 


While there certainly are "tied and true" ways of doing things, we are an evolving species, and change is fundamental to survival. ;-)


(Source Photo: Andy Blumenthal)

Share/Save/Bookmark

May 4, 2013

When Requirements Go Awry

You may have seen this before--it is a great comic strip on how requirements can go awry. 

When you look at how product or service requirements look from each person's vantage point, it is easy to see how they can be misunderstand, misinterpreted, or misrepresented. 

Getting clarity of the tire swing before we start can save a lot of wasted time, effort, and money on building contraptions that no one wanted or needs. 

Get the business and technical requirements spelled out in as much detail as possible from all parties; document, document, document; and have the customer approval and sign off on these. 

Build to specification, on time, and within budget and make sure it meets the operational mission needs and strategic vision of the organization. 

(Source Photo: here with attribution to tamingdata.com)
Share/Save/Bookmark

March 17, 2013

Is Bureaucracy Just Another Word For Governance?

Fascinating opinion piece by Fisman and Sullivan in the Wall Street Journal on Friday (15 March 2013) called "The Unsung Beauty of Bureaucracy."

The authors argue that bureaucratic rules and regulations serve important purposes in that while "less good stuff gets done--but it also puts a check on the kinds of initiatives that can lead to catastrophe."

And they give numerous examples of industries that perform sensitive functions that you would want to actually take some extra time to make sure they get it right.

A vary basic example given was the company Graco that makes infant car seat and strollers; they have five design phases and hundreds of tests that add up to two years to product development, but who would rationally argue against such quality controls processes to protect our children.

They make another good point, we always here about bureaucracy slowing the innovation and product development down, but what about the "bad ideas that were quashed as a result of the same rules?"

We all rail against having to jump through hoops to get things done and rightfully so. The mission is important, time is of the essence, and resources are limited--last thing anyone wants is to be told you have x process that must be followed, y gates to get through, z signatures to obtain--and that's just for the routine stuff! :-)

But as much as we hate to be slowed down to cross the t's and dot the i's, often that's just what we really need--to make sure we don't do anything half-a*sed, stupid, or jut plain reckless.

One mistake in an operational environment can bring things to a standstill for thousands, in a system it can have a dominos effect taking down others, and in product development it can bring deadly consequences to consumers, and so on. 

So putting up some "bureaucratic" hurdles that ensure good governance may be well worth its weight in gold. 

Frankly, I don't like the word bureaucracy because to me it means senseless rules and regulations, but good governance is not that.

We need to stop and think about what we are doing--sometimes even long and hard and this is difficult in a fast-paced market--but like a race car taking the turn too fast that ends up in a fiery heap--stopped not by their steady pacing, but by the retaining wall protecting the crowds from their folly.

One other thing the author state that I liked was their pointing out the government which is involved in so many life and death matters needs to maintain some heightened-level of governance (I'll use my word), to get the food supplies safe and the terrorists out.

From clear requirements to careful test plans, we need to ensure we know what we are doing and that it will work. 

At the same time, showing up after the party is over serves no purpose.

Like all things in an adult world, balance is critical to achieving anything real. ;-)

(Source Photo: Andy Blumenthal)

Share/Save/Bookmark

January 22, 2012

Work Off Of Standards, But Stay Flexible to Change

Interesting book review in the Wall Street Journal (18 January 2012) on Standards: Recipes for Reality by Lawrence Busch.
Standards are a fundamental principle of enterprise architecture, and they can mean many things to different people--they can imply what is normal or expected and even what is considered ethical.
Reading and thinking about this book review helped me to summarize in my own mind, the numerous benefits of standards:
- Predictability--You get whatever the standard says you get.
- Quality--By removing the deviation and defects, you produce a consistently higher quality.
- Speed--Taking the decision-making out of the routine production of standardized parts (i.e. we don't have to "reinvent the wheel each time"), helps us to move the production process along that much faster.
- Economy--Standardizing facilitates mass production and economies of scale lowering the cost of goods produced and sold.
- Interoperability--Creating standards enables parts from different suppliers to inter-operate and work seamlessly and this has allowed for greater trade and globalization.
- Differentiation--Through the standardization of the routine elements, we are able to focus on differentiating other value-add areas for the consumer to appeal to various tastes, styles, and genuine improvements.
While the benefits of standards are many, there are some concerns or risks:
- Boring--This is the fear of the Ford Model-T that came in only one color, black--if we standardize too much, then we understate the importance of differentiation and as they say "variety is the spice of life."
- Stagnation--If we over-standardize, then we run the risk of stifling innovation and creativity, because everything has to be just "one way."
- Rigidity--By standardizing and requiring things like 3rd-party certification, we risk becoming so rigid in what we do and produce that we may become inflexible in addressing specific needs or meeting new requirements.
The key then when applying standards is to maximize the benefits and minimize the risks.
This requires maintaining a state of vigilance as to what consumers are looking for and the corollary of what is not important to them or what they are not keen on changing. Moreover, it necessitates using consumer feedback to continuously research and develop improvements to products and services. Finally, it is important to always be open to introducing changes when you are reasonably confident that the benefits will outweigh the costs of moving away from the accepted standard(s).
While it's important to work off of a standard, it is critical not to become inflexible to change.
(Source Photo: here )

Share/Save/Bookmark

July 28, 2010

Newer Isn’t Always Better

I love new technology as much or more than the next guy, but...

Last month, I came across an article in USA Today called “Army Ditches Velcro For Buttons,” which chronicles how after deploying high-tech, “space-age Velcro” in uniforms in 2004, the Army found that the good old button worked better on keeping pants packets closed. The Army is now substituting three buttons for Velcro on the cargo pockets of its pants to keep them from opening up and spilling out.

To me, the point is not whether we use new, newer, or even the newest technology out there (like space-age Velcro), but whether we are right-fitting the technology to our organization (in this case, the button met the needs of the soldier better).

I’m sure you may have noticed, as have I that certain technology enthusiasts like, want and literally crave the “latest and greatest” technology gizmos and gadgets, whether they fully work yet or not.

These enthusiasts are often the first to download a new (still buggy) app and the ones that line up (often bringing their own lounge chairs) the night before a new iPhone or other “hot” consumer technology product goes to market.

Similar, and perhaps well-intentioned, enthusiasm for new technology can end up in pushing new technologies before the organization is ready for them (in terms of maturity, adoption, change, priorities, etc.). In other cases, newer technologies may be launched even before the “ink is dried” on IT purchases already made (i.e. the technologies bought are not yet implemented and there has been no return on investment achieved!).

At the extreme, organizations may find themselves with proverbial IT storage closets full of still shrink-wrapped boxes of software and crates of unopened IT hardware and still not be deterred from making another purchase and another and another…

I remember in graduate school learning about shopaholics and those so addicted to consumerism that their behavior bordered on the abnormal according to the Bible of psychiatry, the Diagnostic Statistical Manual (DSM).

This behavior is in sharp contrast with organizations that are disciplined with technology and strong stewards with their organization’s investment dollars—they tend to follow a well-thought-out plan and a structured governance process to ensure that money is well-spent on IT—i.e. it is requirements-driven, strategically aligned, ROI-based, and technologically compliant with the architecture.

In such organizations, responsibility and accountability for IT investments go hand-in-hand, so that success is not measured by whether new technologies get identified and investments “go through,” but rather by how beneficial a technology is for the end-user in doing their jobs and how quickly it actually gets successfully implemented.

This latter organization model is the more mature one and the one that we need to emulate in terms of their architecture and governance. Like the Army, these organizations will chose the old fashioned button over the newer Velcro when it suits the soldier better and will even come out saving 96 cents per uniform.

New technology is great--the key is to be flexible and strategic about when it is needed and when it is not.


Share/Save/Bookmark

April 29, 2010

Powerful Information Visualization Demo

This is not an endorsement of any vendor or product, but rather just sharing a great example of how robust visualization and enabling technology can help us comb through myriads of data and get meaningful information quickly to the people of the front line.

This is the type of architecture that pulls together end-user mission requirements, the vital information to perform, and the system to meet those needs in an eliquent end to end solution.


Share/Save/Bookmark

January 16, 2010

Customer-driven IT Management

For many years, we have witnessed the failures of excessively product-driven management, where companies focus on the development and sales of products (from automobiles to toaster ovens) to their customers—whether the customers really want those products or not. This was epitomized by the “build it and they will come” mentality.

Numerous companies faltered in this over-the-top product mindset, because they were focused not on satisfying their customer’s needs, but on selling their wares. Think GM versus Toyota or the Days Inn versus The Four Seasons.

Now however, organizations are moving from product- to customer-focused management, with the basic premise that organizations need to engage with their customers and assist them in getting the most value out of whatever products meet their requirements best. In the world of IT, this is the essence of user-centric enterprise architecture, which I created and have been advocating for a number of years.

Harvard Business Review, in January-February 2010, has an article titled “Rethinking Marketing” that asserts that “to compete, companies must shift from pushing individual products to building long-term customer relationships.”

· Product-driven companies—“depend on product managers and one-way mass marketing to push a product to many customers.”

· Customer-driven companies—“engage individual customers…in two-way communications, building long-term relationships.”

The old way of doing business was to focus on the products that the company had to offer and “move inventory” as quickly and profitably as possible. I remember hearing the sales managers yelling: “sell-sell-sell”—even if it’s the proverbial Brooklyn Bridge. And the driver of course, was to earn profits to meet quarterly targets and thereby get bigger bonuses and stock options. We saw where that got us with this last recession.

The new way of doing business is to focus on the customer and their needs, and not any particular product. The customer-driven business aligns itself and it’s products with the needs of its customers and builds a long-term profitable relationship.

“In a sense, the role of customer manager is the ultimate expression of marketing find out what the customer wants and fulfill the need), while the product manager is more aligned with the traditional selling mind-set (have product, find customer).”

The new model for a customer-driven enterprise is the epitome of what social computing and Web 2.0 is really all about. In the move from Web 1.0 to 2.0, we transformed from pushing information to stakeholders to having a lively dialogue with them using various social media tools (like Facebook, Twitter, blogs, discussion boards, and many more)—where customers and others can say what they really think and feel. Similarly, we are now moving from pushing products to actively engaging with our customers so as to genuinely understand and address their needs with whatever solutions are best for them.

In a customer-focused organization, “the traditional marketing department must be reconfigured as a customer department [headed by a chief customer officer] that puts building customer relationships ahead of pushing specific products.”

I think that the new organizational architecture of customer-driven management is superior to a product-focused one, just as a emphasis on people is more potent that a focus on things.

Similar to customer-driven management, in User-centric enterprise architecture, we transform from developing useless “artifacts” to push out from the ivory tower to instead create valuable information products based on the IT governance needs of our customers.

Further, by implementing a customer-focus in information technology management, we can create similar benefits where we are not just pushing the technology of the day at people, but are rather working side-by-side with them to develop the best solutions for the business that there is.


Share/Save/Bookmark

October 20, 2009

“The Happiness Myth” and Enterprise Architecture


Recently, I was reminded of an interesting article that appeared in The Wall Street Journal (20 Dec 2007) that what really matters in life is not happiness, but rather peace of mind.

Generally speaking, people “are consumed by the pursuit of happiness,” and this fact is codified in our very Declaration of Independence
that states: “that all men are created equal, that they are endowed with certain unalienable rights, that are among these are life, liberty, and the pursuit of happiness.”

However, absolute happiness is often in conflict with the "reality on the ground".

There are some of the inherent conflicts we deal with in enterprise architecture (sort of like the Murphy's Law of EA):

Here are some typical user wants (often associated with problematic architectures):
  • A baseline, target, and transition plan without their having to provide virtually any input or to collaborate whatsoever.
  • An architecture roadmap that they do not have to actually follow or execute on.
  • A platform for information sharing and access to information 24/7, but they also want to hoard “their information”, and keep it secure and private, on a need-to-know only basis, which they subjectively decide.
  • A structured IT governance process to ensure sound IT investments for the organization, but also they want leeway to conduct their own affairs, their way, in which they buy want they want, when they want, how they want, from whomever they want, with whatever founds they can scrounge up.
  • A requirements generation and management process that captures and aligns specific functional requirements all the way up to the organization’s strategic plan, mandates and legislation, but that they don't have to be bothered with identifying, articulating, or aligning.


The world of EA is filled with conflicting user demands and polarizing directions from user that want and expect to have it all. While certainly, EA wants and strives to meet all reasonable user requirements and to satisfy the user community and “make them happy,” at a point there comes the realization that you can’t (no matter how hard you try) make everyone happy all of the time.

People want it all, want it now, and often when you give them what they want, they realize that it wasn’t “really” what they had wanted anyway.

So the way ahead is to understand and take into account your user requirements, but more importantly to do the “right” thing for the organization based on best practices, common sense, and initiatives that will truly drive improved performance and mission results.

The WSJ states, “Dad told me: “life isn’t built around ‘fun.’ It’s built around peace of mind. Maybe Dad sensed the paradox of happiness: those most desperate for it run a high risk of being the last to find it. That’s because they make foolish decisions. They live disorderly lives, always chasing the high of the moment.”

In User-centric EA, we don’t “chase the high of the moment,” or look to satisfy each and every user whim, but rather we keep the course to developing sound IT planning and governance and to enhancing organizational decision-making capabilities for our end users. EA is a discipline that ultimately strives to ensure peace of mind for the enterprise through the provision of vital "insight" and "oversight" functions.


Share/Save/Bookmark

September 23, 2009

Realistic Optimism and Enterprise Architecture

Optimism can be a key to success in your personal and professional life!

The Wall Street Journal reported in Nov. 2007 that optimism leads to action and that “if even half the time our actions work out well, our life is going to turn out for the better…if you are a pessimist, you are unlikely to even try,” says Dr. Phelps an NYU neuroscientist. Similarly, Dr. Martin Seligman of the University of Pennsylvania observes that “optimists tend to do better in life than their talents alone may suggest.”

So while optimism is often “derided as a naïve, soft-soap disposition that distorts the realities of life,” Duke University researchers found that optimists actually lead more productive and by some measures, successful lives. For example, they found that optimists “worked longer hours every week, expected to retire later in life, were less likely to smoke and, when they divorced, were more likely to remarry. They also saved more, had more of their wealth in liquid assets, invested more in individual stocks, and paid credit-card debt bills more frequently.”

At the same time, overly optimistic people behaved in a counter-productive or destructive fashion. “They overestimated their own likely lifespan by 20 years or more…they squandered, they postponed bill paying. Instead of taking the long view, they barely looked past tomorrow.”

Overall though, “the influence of optimism on human behavior is so pervasive that it must have survival value, researchers speculate, and may give us the ability to act in the face of uncertain odds.”

Optimism coupled with a healthy dose of realism is the best way to develop and maintain the organization’s enterprise architecture plans and governance. Optimism leads the organization to “march on” and take prudent action. At the same time, realism keeps the enterprise from making stupid mistakes. An EA that is grounded in “realistic optimism” provides for better, sounder IT investments. Those investments proactively meet business requirements, but are not reliant on bleeding-edge technologies that are overly risky, potentially harmful to mission execution, and wasteful of valuable corporate resources.


Share/Save/Bookmark

June 27, 2008

Information Warriors and Enterprise Architecture

In the digital age, information is critical to decision making. This is the case in the board room as well as on the battle field.

Information superiority is critical to our warfighters ability to intelligently and efficiently defeat our enemies. Many of the Department of Defense‘s modernization initiatives are aimed at getting the right information to the right people at the right time. Unfortunately, there are still some information gaps.

National Defense Magazine, December 2007, reports “troops in digital age, disconnected.”

Apparently, not everyone in the military is getting all the information they need (at least, not yet).

The problem often is described as a ‘digital divide’ between the technology haves—the upper echelons of command—and the have-nots---the platoons and squads that are deployed in remote areas. These small units for the most part are disconnected from the Army’s main tactical networks and only are able to communicate with short-range voice radios…[however,] at the top echelons, commanders can tap into loads of data—maps, satellite images, video feeds, and reams of intelligence reports.”

Often though it is the small units on the front lines that need to send and receive critical information on combatants or other situational updates that can have life and death implications. This is why the net-centric strategy for virtually connecting all units is so important to achieving the vision of true information dominance.

Here are just a few important ways that information can help our warfighting capabilities:

  • Providing information to soldiers to locate enemy combatants (such as from “live video from unmanned aircraft)
  • Enabling location tracking of soldiers to save lives when they are endangered (such as from GPS locators)
  • Sending information updates back to command for coordination and enhancing decision capabilities (such as from streaming voice and video, instant messaging, etc.)

The good news is that there are a lot of new information technologies coming online to aid our military, including the Future Combat Systems (FCS) and Joint Tactical Radio Systems (JTRS).

To ensure the success of these technologies, we need to manage the solutions using enterprise architecture to validate requirements, reengineer the processes, and effectively plan and govern the change.

  1. Requirements management—“how to identify essential needs for information as opposed to providing information indiscriminately”
  2. Business process reengineering—according to Marine Corps. CAPT Christopher Tsirlis “it’s not just about the latest and greatest technology but also changing the organization to use new technology.”
  3. Planning/governance—we need link resources to results;“the technology exists, the question is how we resource it, and what is the right amount for each level.”

With a solid enterprise architecture and innovative technologies, we can and will enable the best information warriors in the world.


Share/Save/Bookmark