There are two components to post-project evaluations that focus on two related areas: how well the project was executed and what was the business impact it created. This second Advisor in a series of three articles on post-project evaluations takes a closer look at the first area, assessing project performance.

Henry Ford may have given us the inexpensive automobile but Alfred Sloan gave us the model year. Ford believed that mass production was based on making millions of one standardized product. Sloan, on the other hand, believed that mass consumerism was based on changing automobile styles every year so that people would be tempted (encouraged) to buy a new car every few years rather than every decade. This was called style-based (or marketing-based) obsolescence.

Recently, the US National Counterterrorism Center (NCC) revealed that its database containing approximately 325,000 names of alleged international terrorist suspects (or people suspected of helping them) is actually inflated by about 135,000 extra names. This revelation serves to highlight a problem that many organizations of all sizes and focus struggle to deal with: duplicate customer names and records.

In my last Trends Advisor ("Real Enterprise Data Architecture, Part 1," 23 February 2006), I touched on the issue of enterprise data architecture from a conceptual standpoint. I suggested that being an enterprise data architect (as opposed to a DBA or data modeler) demands that you take a very high-level view of the company.

Information security risk assessments have become one of the more important techniques to minimize operational risk, improve the security posture in a company, and meet current regulations and standards. Risk assessments have long been used in other domains, such as software and system development and the financial and insurance industries. In information security, risk assessments began as primarily technological evaluations -- an identification of the known [1] vulnerabilities remaining in operational systems and system components.

Scrum is probably the most popular agile method right now in the USA. The power of Scrum is its simplicity. There are only a handful of Scrum rules and so it is easy to get a team started with Scrum [1]. And yet Scrum can unleash the potential of a team and dramatically improve its productivity within weeks. A Scrum team works on one project at a time and Scrum provides a toolkit to cut through complexity so that everyone can focus on doing their job rather than fending off multiple drains on their time.

There are many key moments in projects. What I do during those moments greatly influences the outcome of the project. There is good news here in that we as project managers can learn to recognize these moments and respond well.

I believe a key moment in a project occurs when someone brings me some not-so-good news about the work. This can happen many times in every project. There is a set of activities preceding such a moment:

After performing rigorous due diligence, reviewing several RFP (request for proposal) responses, and evaluating a selected number of suitable vendors, you picked one or more partner(s) to work on your sourcing initiatives. What makes you so confident that you and your partner will have a successful relationship? What assures you that you two are really in this relationship together, for the long haul?

Building a business case is a necessary prerequisite in supporting any major investment decision. Building the business model, calculating costs and quantifying benefits, analyzing cash flow over time, and calculating financial indicators, such as net present value, internal rate of return, return on investment (ROI), or whatever else is required for getting the management approval, are essential parts of "investment engineering." This is the kind of discipline that creates informed and responsible spending decisions, right?

Vendors today are introducing new products that apply advanced algorithms designed specifically for e-mail analysis. The result is an emerging market: e-mail intelligence.

With larger organizations undertaking agile project management and development methods in significant ways, issues around what I've referred to as "agile integration" are becoming more and more important to successful agile implementation. Agile integration involves all the enterprise and organizational issues that must be addressed for agile practices and principles to become fully integrated into an organization's ways of doing business.

Last week, I had the pleasure of attending the XX Winter Olympics in Torino, Italy. Being from the US state of New Hampshire, I had to root for our local competitor Bode Miller, who's from Franconia. At the Men's Combined event (downhill and slalom), he was in first place after the downhill portion of the race, clocking the fastest speed of the day at a blistering 126.8 Km/hr (79 MPH -- I don't even drive that fast). But in the slalom portion of the race, he missed a gate and was disqualified. This was to be the second of five disappointing appearances for Bode.

Our clients' business executives often ask us to tell them the appropriate level of IT spending compared to the company's total revenues. Some companies spend 2% of revenue, others spend 8% or 10% or even more. Of course, the industry in which the company operates affects this; probably financial services firms, for example, spend a higher proportion of revenue than, say, manufacturing firms. But maybe not.

If you spend serious money with a vendor, here are five things you should expect.

NCR Teradata announced it is buying supply chain analytics application vendor SeeCommerce for an undisclosed amount. Teradata will use SeeCommerce's packaged supply chain intelligence (SCI) applications to bolster its Teradata Demand and Supply Chain offerings.

SeeCommerce offers SeeChain -- a packaged SCI application, whose various modules cover a range of supply chain domains and processes, including:

There seems to be a mantra in many agile development organizations that the shorter the iteration, the more agile the team. While I believe strongly in short iterations (on the order of one to four weeks), sometimes the "shorter is better" mantra gets in the way of progress. It may also be a symptom of a process being too developer centric.