Phil Laplante of Penn State is a prolific and respected writer on many software and project topics as well as being part of my local IT community.  In the July/August issue of the IEEE IT professional magazine, Phil steps back and writes a thoughtful and though provoking article that is perfect for contemplation on the beach.

In “Nexialism and the Law of Unintended Consequences,” (there’s a search term you won’t use very often) Phil suggests that to understand complex interactions that could impact our project risk we need to spend at least some time thinking in simple terms about the big picture.  Nexialism is defined as “the science of joining in an orderly fashion the knowledge of one field of learning with that of other fields.”

OK so that sounds a little grandiose and you might be wondering how it impacts your project risks.  Think of it this way, how many times in a failing project did somebody know that it was going wrong early but was never asked?  Is the test manager communicating (talking and listening) with the coding team lead (and vice versa).  What is the opinion of the DBA’s?  The performance test team?  Like it or not, these are different disciplines (or fields if you like) with different perspectives and, too often, we do not take care to “join their knowledge in an orderly fashion.”

An article by Tom Costello in the May/June 2010 edition of the IEEE IT Professional magazine caught my eye because the title sounded like a new CD from a favorite band of my youth, “Status Quo - The Silent Killer “

It’s not every day I can say that about my technical reading!

Costello makes the point in his article that, today, IT are often asked to justify the business value of every initiative that touches IT with the underlying requirement that IT is expected to create value for the business.  He goes on to ask the question, “So how does IT create value when the business model ‘in play’ isn’t designed to do so?” and then, “What can technology investment achieve?”

Based on the premise that if the first 80% of technology capability in a particular problem space can be delivered at a given cost then the next 10% will have a similar cost and the next 5% the same cost and so on, Costello’s answer to this last question is based on trying to work out where your company is on this particular curve.

With some simple but interesting models and charts, Costello argues that the potential for IT to create business value is dependent on whether the business growth strategy at any given time is proactive, reactive or passive and where the business sits in relation to its competitors on a spectrum of profit margins for different revenues.  Essentially, Costello puts the case that the only case where IT can be expected to create business value is when the business growth strategy is proactive and the business has low revenue but high margins relative to the competition.

Costello presents and interesting concept and one that can be fairly easily constructed for companies competing in the public space.  it brings to mind Christensen’s disruptive technology proposition.  However, it has weaknesses.  For example, it assumes that the problem space stays the same and doesn’t allow for low cost innovation due to changes in either technology capabilities or the business environment.  Such changes effectively reset the degree to which the current capabilities satisfy the problem requirements back to below the 80% level.  I guess that Christensen would argue that this is precisely the opportunity that a disruptive technology seeks to address because its business model is more flexible that the incumbents.

Finally, I wonder what the equivalent of this sort of analysis is for the government departments?

Interesting survey result in the June 2010 edition of CIO Magazine.  90% of respondents to a survey by Forrester Research reported that customer experience was “critical” or “very important” to the corporate strategy.  No surprise there.  The responses on the obstacles to improving customer experience were very revealing:

• 53% (over half) reported “No clear strategy for improving the customers experience
• 50% expressed a “Need for customer-experience management processes.”
• 49% are experiencing “insufficient cooperation across groups”
• 32% report a “lack of understanding about customers”

If any of this sounds familiar, you need help!  Give us a call or work it out yourselves.    All of these are solvable but the third bullet rings particular true across the business-IT interface.  We run across this all the time with our clients and it improvements in breaking down internal barriers DO benefit customers!

I have heard or read the phrase “IT-Business convergence” a number of times in the past few months.  It’s a neat phrase but what does it mean?   Different things to different people it seems.  Some examples:

• One of our clients is seeking to collapse its various product offerings onto a single connectivity and data management architecture to serve multiple vertical markets - “IT-Business convergence”?
• In the May 17, 2010 issue of Informationweek, John Burns CIO of Credit Suisse investment bank talks about, “… the increasing convergence in the way business is transacted.  We’ve been very siloed because our products and business are diverse but there’s more and more commonality in the way business is transacted, and electronic trading is becoming more common across all asset classes.” - “IT-Business convergence”?
• In the May 24, 2010 issue of Computerworld, Julia King spoke to five “Pioneers of Convergence” including Paul Heller, CIO of our local giant Vanguard Group.   From these interviews, Ms King identified six indicator of companies that have a high-degree of “IT-Business Convergence”:

1. View IT as an innovation engine that continually transforms the business, often enabling new revenue streams
2. Regard their customers as kings and view customer service, both internal and external, as supreme
3. Rotate business and IT staffers across departments and job functions
4. Provide an overarching goal that is crystal clear to each and every IT and business employee
5. Ensure that IT employees know how the company makes (or loses) money
6. Create a distinct, vibrant and unique company culture

Software development for software products shares all of the opportunities and challenges of software development in corporations with a few majors quirks all of its own.  One of these is the issue of managing a code line for a single product while accommodating (or not) variations for specific customers.  If you are working or have worked for a software product developer, you will be familiar with this problem.

Essentially, the easiest, cheapest and most efficient way to maintain a software product is to have a single code line with all clients on the same, latest version.  In this ideal model, any defects can be fixed in the single code base and provided to clients in the next maintenance release (maybe with a short-term patch to get over any short-term delay).  This model is illustrate below:

At the other extreme, different clients for a software product each have different versions of the software in production with differing levels of maintenance releases and patched loaded.  Many of the clients have their own special customizations to the code some of which overlap with the core product code. A simple example of the challenges is illustrated below:

Many software products will acknowledge more complicated scenarios than this.  Over the years, managing these scenarios has been made slightly easier by more sophisticated configuration management software which manages code branches and code line re-mergers.  That said, such systems still require a level of discipline comparable to the complexity they offer to manage and it is crucial to remember that some code branches just cannot be “automatically” re-merged.

If it is so difficult to manage code branches, why do software product vendors allow or even facilitate the branching of the core product code line?  The following drivers are all relevant:

1. New software product releases of any kind require effort from the clients to acceptance test before loading into  production.
2. A big license deal requires some updates to the product that are needed before the next release will be ready so the software product vendor creates a custom version for the “special”client.  When the next release comes out, the client is in the middle of configuration and implementation and does not want to take the new release.
3. There is pressure on software product vendors to provide minimal patch fixes to a clients specific problems to avoid the need to load maintenance releases which fix every clients problems.
4. All clients believe that they are unique and need changes to software products to reflect their specific operating methods (instead of changing their operating methods to suit the software).
5. All clients understand the long-term costs of customizing software products and so strive to stay on the core product line without necessarily loading every release (Why load a new release if WE don’t need the new functionality or bug fixes?).

“AIE” is the last in the series of four metrics for measuring the business value of IT that I introduced in my posting of July 7, 2009.  The first three in the series were the “Business Value Index,” “Total Economic Impact” (TEI) and “Val IT.”

AIE is considered to be the most rigorous of these four approaches but it has not gained widespread use.  With its mathematical, statistical and economic underpinnings, AIE provides investment decision-makers with a high degree of confidence in its results but there is a steep learning curve and it requires significant expertise.  Key features of AIE include:

• Rigorous “Unit of Measure” definitions even for such normally subjective elements as customer satisfaction.
• Systematic uncertainty analysis - quantification of the risk of an IT investment in such a way that it can be directly compared with a non-IT investment.
• Calculation of the economic value of information - AIE works on the logic that information reduces uncertainty, less uncertainty improves decisions, better decisions result in more effective actions and effective actions improve profit or mission results.  AIE includes a mathematical framework for calculating an pricing all this in dollars!
• IT investments as an investment portfolio - this is perhaps obvious from the previous three features but the rigor of the previous three features allows the IT investments to be analyzed alongside, and compared using, the same tools as those used extensively for non-IT investments.

As often happens, i was looking for something else when I came across a 2008 article in IEEE Computer by Mary Lacity and Joseph Rottman (don’t worry - the subject matter is covered in their 2008 book, “Offshore Outsourcing of IT work).  Having just set one of our clients off on the implementation of some outsourcing options to supplement their in-house resources, the list of 20 major effects of offshore outsourcing reported by project managers caught my eye.  I strongly recommend that you think of this list as a set of risks that need to be mitigated in any outsourcing implementation.  With apologies to the authors, I have sorted their list according to my highest priorities.  The in-house Project Managers reported that they:

• needed a mentor the first time they managed a project with offshore resources
• had to motivate the supplier to share bad news
• had to make offshore suppliers feel welcome and comfortable
• needed to thoroughly verify the offshore supplier’s work estimates, which tended to be optimistic
• had to provide greater detail in requirements definitions
• had to do more knowledge transfer up front
• were forced to shortcut the knowledge transfer process because of deadlines set by senior IT leaders
• had to ensure that knowledge transfer was successful by testing the supplier employees’ knowledge
• had to set more frequent milestones
• needed more frequent and more detailed status reports
• required more frequent working meetings to prevent client-caused bottlenecks
• needed to accompany offshore suppliers to all client-facing meetings
• experienced higher transaction costs which threatened their ability to deliver projects on budget
• experienced project delays which threatened their ability to deliver projects on time
• had to guarantee that the supplier followed pre-agreed knowledge renewal practices
• had to ensure that the supplier transferred knowledge about new applications or technologies to the client
• had to learn about new applications or technologies independent of suppliers to ensure that the suppliers information and bids were valid
• had to integrate the suppliers CMM/CMMI processes into their own project management processes
• had to ensure that the supplier’s employees were fully trained as promised by the suppliers
• had to fill many of the roles the the PMO should have performed

An IDC report published in January 2010 (IDC Analyst Amy Konary) cited enterprise software customers (e.g. the CIO’s in corporations) as seeking the option from software product vendors to pay for their product based upon the in-house usage rather than the traditional model of up-front license fees followed by annual maintenance fees.

The corporate customers are seeking a pay-per-use model for their enterprise COTS applications similar to the sort of models that they are now getting from their adoption of cloud computing or software as a service (SaaS) models.  Software product vendors need to think carefully about this pricing option.  It offers a pricing model that sits halfway between the traditional licensing model and SaaS.  Interestingly, it may offer an unexpected side benefit to software product vendors by providing a means to get immediate value out of new enhancements to the core software.  These new enhancements are expected on a regular basis by corporate customers, partly in return for their maintenance fees but often the license plus maintenance model is stretched to incredulity over time.  This “you get what you pay for” model has the potential to yield a much more “honest” relationship between software product vendor and customer.  That said, the IDC report hints that all will not be plain sailing with the “pay as you go” model because CIOs will want assurance that costs wont suddenly spike as a result of unexpectedly heavy usage.  I’m sure they will be willing to trade this for similar assurances to the software vendor at the other end of the spectrum (just a small joke for my software vendor friends).

One of the major areas that will require serious thought for software vendors is the nature of the usage granularity they should offer.  An obvious cut would be user access over time similar to the monthly “per user” fees typically associated with SaaS.  Another idea would be to mix in user access to different subsets of functionality.  This will probably require some changes to the software either to proactively control access to subsets of the functionality or to retrospectively report access to subsets of the functionality.  An obvious approach to the functionality granularity would be to identify and group use cases or transactions (using function point analysis techniques).  This could be very attractive to clients - imagine only having to pay for the parts of Microsoft Word that you actually use!  Even if that meant paying a premium for those functions that you need but only use rarely.

Interesting report by Mitch Betts in the the January 4, 2010 edition of Computerworld on how The Corporate Executive Board think the corporate IT funding model should evolve.

You know what this is all about - balancing the budget by transferring money from the profits centers to the costs centers (of which IT, and software development, are usually one of the largest).  Your organization probably does it in one of three ways:

• usage-based chargeback (which requires detailed cost accounting)
• lump sum payments (based on some arbitrary metric to divide up which profit center pays how much e.g. headcount)
• A mix of the two

The Corporate Executive Board believe that a much better way option for the future is to parcel up all of IT into 12-24 “business services” and assign costs for each one.  They recommend that the IT services should be described in business terms e.g. “video conferencing” not network “bandwidth.”  Although if video conferencing ios one service, how on earth do you describe It in only 12-24 services.

That brings me to my main point.  How would software development fit into these 12-24 services?

My guess is that it would be included in the services that it supports.  So if, say,  Service A needs to enhanced or modified, the software development cost would be included in the Service A cost to the business.   Hmmm.  That’s not so easy.  Presumably the typical cost of Service A is an operational cost.  How would you handle a one-off enhancement cost?  Would it be amortized over, say, two years and added to the operational cost?   What if the software development included some architectural changes that benefit more than one service?  Well you could make some arbitrary decisions about how to divide up the architectural costs among the services.  Oh!  Wait a minute! isn’t that where we came in?

“Val IT” is the 3rd in the series of four metrics for measuring the business value of IT that I introduced in my posting of July 7, 2009.  The first two in the series were the “Business Value Index” and “Total Economic Impact” (TEI).  Val IT is a complementary framework to the COBIT IT governance framework (described in our book, “The Business Value of IT” and elsewhere). While Val IT does not require a simultaneous COBIT implementation, it is clearly a good IT valuation option for organizations which already have COBIT in place.

Like TEI, Val IT started out focused on new IT investments.  Val IT is made up of three key processes which contain a total of 41 key management practices:

1. Value Governance (11 key management practices)

• Governance, Monitoring & Control
• Provision of strategic direction
• Define investment portfolio characteristics

2. Portfolio Management (15 key management practices)

• Identify and maintain resource profiles
• Define investment thresholds
• Evaluate, prioritize, select, defer or reject investments
• Manage the overall profile
• Monitor and report on portfolio performance

3. Investment Management (15 key management practices)

• Identify business requirements
• Develop clear understanding of candidate investment programs
• Analyze alternatives
• Definition and documentation of business case including benefits
• Assign accountability and ownership
• Manage through the economic life cycle
• Monitor and report on performance