Professional teams practice over and over again to make the transition from raw talent to finely honed, instinctive skill. They practice to identify the strengths and weaknesses of both individual players and the team as a whole. They practice so that the plays in the playbook become second nature. Finally, they practice to make the transition from a collection of individual athletes to a real team. Beyond that, individual players do extensive strength and speed training on their own to meet explicit or implicit performance expectations from the coaches.

The applicability and utility of any efforts to build a risk infrastructure ultimately rely on the development of a risk history. Organizations cannot ensure consistency of practice without awareness of what happened in the past, and for some, a component of the organization''s culture is stories -- that is, its history. Some organizations can cite past acts of heroism and survival.

In a previous Advisor, we saw how organizations can approach vendor selection by first thinking about the outcomes the company seeks in the offshoring relationship ("Vendor Selection Based on Desired Outcomes," 6 December 2006). Once that is accomplished, it is easy to establish specific criteria to help in the winnowing out process. In this Advisor, we apply the concepts of the previous Advisor to the creation of specific criteria for offshoring vendor selection.

In 2006, I started out the year's Advisors with some suggestions for New Year's resolutions. I know how busy things can get around this time of the year, so in keeping with this popular feature and as a continuing service to Enterprise Architecture Advisor readers, here again is a list of ready-made resolutions that you can adopt for 2007.

In his 19 December 2006 Business Intelligence E-Mail Advisor, "Business Performance Management Demands Data Profiling," Cutter Senior Consultant Curt Hall recommends organizations perform a data quality audit of their operational systems prior to conducting a business performance management initiative.

The IT industry today bears little resemblance to the industry of more than four decades ago when I started out in software development. In those early days, the concept of computers actually "communicating" with each other didn't exist.

"What did you know, and when did you know it?"

That query was the signature phrase from the Watergate hearings some 30 years ago in the US, which was looking into illegal activities conducted by the Nixon Whitehouse. It was resurrected during the recent HP boardroom leak flap about who knew what when regarding HP investigators illegally pre-texting corporate board members'' and reporters' identities to uncover personal information about them.

Happy New Year! I want to wish everyone a terrific 2007.

Last week, news articles in the New York Times and elsewhere documented the difficulties that the US Coast Guard was having with a program called "Deepwater" -- a US $24-billion program to rebuild the Coast Guard's fleet of aging vessels. But things have gone south.

All agile methodologies call for high levels of interaction between the development group and the customer or product group (internal IT groups will probably refer to this as the customer team, while software product companies may refer to it as the product team). Both groups are part of the overall project team.

Many corporations' boards and senior management do not believe that the CIO should be concerned with corporate governance. This is a grave blunder, and I pity the CIO and the shareholders of any corporation with this attitude.

One of the popular ideas aimed at increasing the business value of IT outsourcing is the shared risk and return agreement, in which the outsourcer is rewarded for generating additional client benefits. Like many management concepts, this type of arrangement has been less successful than most organizations, and consultants, would like to admit.

Service-oriented architectures (SOA) have moved beyond the hype stage to where organizations are now carrying out their implementation plans. Their goal: increased agility via the ability to configure composite applications -- implemented in the form of services -- in response to changing business conditions and IT requirements. To help make this goal a reality, business rules management systems (BRMSs) are increasingly becoming a part of organizations' SOA implementation plans. Here's why.

collaboration = innovation

About 100 years ago, when I was teaching rhetoric and public address in our nation's colleges and universities, I happened to learn that the maximum normal attention span for an adult human being was in the 12- to 15-second range. That's right. Nobody does better than that.

Project management is a discipline and, like all disciplines, needs to be applied judiciously. Over the past few years, we've seen PMOs and project managers run the discipline gamut: some PMOs are composed of overzealous professionals who sometimes lose sight of their primary mission; and some professionals barely apply project management discipline, working only to very loosely consult on the project management process.

So what are the options? What makes sense -- and what doesn't?

We are constantly amazed at the number of our clients who are strongly focused on cutting IT costs. Just this week, a large financial services organization asked us for assistance in cutting its IT budget. Yet this same organization continues to grow and to demand more IT services.

Over the past few years, I've written a number of times on the use of business rules management systems (BRMSs) for implementing automated decision making applications. One particular area in which I see BRMSs as having a major impact on organizations' BI and decision support efforts is for enterprise decision management (EDM). Just to make sure we're all on the same page, EDM refers to the application of BRMSs -- sometimes in conjunction with analytic models -- to automate and improve operational decisions across the organization.

My new smart, stylish, cool PDA is a pain in the neck to actually use. There are so many features embedded in so many more -- these people have perfected hierarchical menus to everywhere -- that I find it nearly impossible to optimize its performance. There are also way too many decisions for me to make: do I really need 50 ring/vibrate combinations (not to mention the six-gazillion I can download)?

I was recently rereading one of my earliest e-mail Advisors from this Agile Project Management Practice (it was actually e-Project management then). The Advisor was about why this different way of managing projects was so important. After reading it, I decided it was time to revisit and update that issue.

With disaster recovery, 9/11, the war on terror, Sarbanes-Oxley, OMB 300, and a host of other influences, there are very few businesses that have escaped the risk experience. Virtually to a one, businesses are taking on the mantle of risk managers in a forceful, overt fashion. It is not universally because they have seen the error of their ways and suddenly recognize that risk management is a practice that adds value to their shareholders.

I was recently rereading one of my earliest e-mail Advisors from this Agile Project Management Practice (it was actually e-Project management then). The Advisor was about why this different way of managing projects was so important. After reading it, I decided it was time to revisit and update that issue.

In this Advisor, I would like to address the "people" component of getting your organization ready for smart sourcing, pointing out specific situations I have observed in my recent engagements with large and medium business clients. My reasons behind starting with the "people" component are twofold.

There's been a lot of activity in the past few months around SOA standards. For example:

August -- Open SOA Collaboration group is formed to advance SCA and SDO October -- OASIS Reference Model for SOA approved December -- The Object Management Group (OMG) begins work on UML Profile and Metamodel for Services

We've discussed SCA, SDO, Open SOA, and OASIS in previous Advisors this year. This week, I'll turn my attention to the UML Profile.

Senior leadership is often interested in identifying estimated costs before they approve any business-IT alignment or related projects. In some cases, the exercise of investigating the costs involve rigorous and meticulous due diligence as well as arduous cost/benefits analyses. In other cases, as assigned teams, we have used prior experience, calculated guesswork, and a combination of high-level estimation of the tasks involved to come up with the numbers.

by Martin Bauer

To think that because you employ an agile methodology you don't need to bother with requirements is simply wrong. Regardless of what methodology you choose for development, you need to know what it is you're building before you start building. To do otherwise is asking for trouble.