Challenges with achieving business value from technology projects

Few companies can afford to launch projects that will not deliver tangible business value – even regulatory compliance projects need to deliver results, even if that is just to keep the company’s leadership out of jail!

New product release projects, or mergers & acquisitions should have measurable financial results.  The waters start to get murkier as we get into business process (re)engineering projects and get downright muddy once we get into back-office technology projects.

So what are some challenges with defining and proving quantifiable returns on technology investments?

1. Technology projects are rarely revenue-generating

One only has to look at the business cases offered by many back-office technology vendors regarding “operational cost savings” incurred by implementing their solutions to know that this is pure snake oil.  The majority of these business cases are based on the assumption that freeing up skilled staff time from administrative drudgery automatically translates into higher productivity – if the resources spend more time at the water cooler or on Facebook, those savings are never realized.  Business cases built on FTE reduction were great a decade or two ago, but few companies have a lot of low hanging “dead wood”.  On the other hand, the acquisition, implementation and ongoing operational support costs of these technologies are quantifiable and when put on the spot, few vendors can truly claim a positive ROI that would stand up to scrutiny.

2. Technology projects deliver products and services that change almost from the first day they are released

Few technology projects are completed with the end products remaining in a static state for more than a few weeks.  Bug fixes, vendor upgrades and change requests all change the very nature of what the deliverables are.  Given this, how long can a business owner continue to claim benefits from a project before it is clear that the service has changed too much for this recognition to remain valid?  I would be surprised if a measurement period longer than a year after release would be considered valid.  This supports the application of release management practices to technology services – instead of continuous changes, plan scheduled release projects that will roll-up the upgrade, bug fixes and service requests.  This way, it is possible to distinguish between the benefits achieved from the original product as compared to subsequent releases.

3. A lack of operational metrics or no base line data

Aside from those organizations that have undertaken operational excellence initiatives requiring the definition and capture of key metrics, the majority of companies do not have well defined non-financial KPIs and even those that have defined these may not have sufficient historical data to be able to prove that a particular technology project made a tangible difference.

4. The Butterfly Effect

As Levitt and Dubner discovered in their Freakonomics research, establishing a strong causal relationship between an action and a positive outcome is difficult in a system as complex as the operational environment of most organization.  Could it be that improvements to a particular KPI were less a result of a technology project, and more related to turnover in staff or indirect influence from individual training plans?  Can a technology project by itself make a bigger difference than a process enhancement or a staff quality improvement?

I’m interested in receiving your comments on this topic given that it is a core expectation of most projects these days.

Consistent portfolio reporting in the absence of a comprehensive PM methodology

A common concern is that the lack of a comprehensive project management methodology is a key impediment to being able to evaluate a portfolio of active projects in a consistent fashion.

While this gap may increase the risks of poor data quality or incompleteness, I believe that you can introduce a few standards to support consistent reporting while still enabling project teams sufficient flexibility to choose the degree of rigor that is used to manage their projects.

I would focus on:

1. Task progress reporting – if teams insist on using a percentage complete method of reporting progress against tasks & projects, insist that they follow one of the following approaches – 0/100, 0/50/100, 0/25/50/75/100 and accept no other options.  If they are using the (better) method of evaluating the remaining effort on tasks, you can then allow for more granularity.

2. Issue severity – to overcome individual biases (i.e. conservatives vs. gamblers) it is a good idea to define an objective basis for setting the severity of a project issue.  For example, if the issue does not have an action plan in place and has the risk of creating a 25% or greater impact to the schedule, it should be flagged as “critical”.

3. Frequency of status reporting – this needs to be driven by your portfolio review team’s schedule.  If they meet on a monthly basis, then project data needs to be updated a couple of days in advance of the scheduled meeting date so that you have sufficient time to chase down laggards and do a quick sanity check on the data before it is rolled up for the portfolio review.

4. Define a bare minimum of metrics to be tracked – the following should cover the key knowledge areas:

• Overall work or percent remaining vs. expected overall work or percent remaining
• Forecast project completion date vs. approved project completion date
• Spend to date vs. expected spend to date
• Forecast spend vs. approved budget
• Actual effort vs. planned effort to date
• Forecast overall effort vs. planned overall effort
• # of unresolved critical & high severity issues
• Customer satisfaction – green (“all is well”), amber (“customer has expressed some concerns”), red (“customer is not happy”)

In summary, focus on a few key standards, and allow project teams to have flexibility over the rest.  This will help to ease the organization change of introducing a comprehensive project management methodology while still addressing mandatory reporting requirements.

I never thought I’d say it – major hotel chains can learn something from the airlines!

I just finished a stay in Chicago at one of the “premium” brands of one of the top two hotel chains.

The hotel charged $14.95 per day for Internet access plus $2.17 in taxes.  Other than Internet access, the only other benefit of paying this fee was free local phone calls – with most travelers using their cell phones, this seems of marginal value. Let’s put this in perspective – in most large cities, you can get monthly residential high-speed Internet access for double or at most triple this price!  Charging for Internet access made economic sense a decade or two ago when it was not ubiquitous however now, it is equivalent to charging for the use of the TV.

What makes this interesting is that these same hotel chains provide free Internet access at their “economy” brands.  As a frequent traveler, the level of service and amenities I benefited from at the premium brand were equivalent to what I would have enjoyed at a discount brand.

Businesses usually fleece customers who purchase bare bones services, but are quick to pamper those that are willing to pay more for premium service.

The airlines are perfect examples of this – fly economy class and you will pay for headphones, drinks and checked in luggage. Fly business class and the same add on’s are included in the cost of your ticket.  In addition, achieving a status threshold with most airline loyalty programs usually results in fees being waived for check in luggage, access to lounges and similar add on’s.

The major hotel chains need to follow the lead of the airlines – eliminate fees for Internet access at their premium brands or at minimum drop them for customers that have achieved a minimal (e.g. Silver) status level within their loyalty programs.

Evaluate frequently & terminate fast – project selection for the new decade

If your organization has a consistent project intake & selection process, kudos to you.  But if your intake process happens only once a year, is mostly focused on hard dollar consuming or capital-oriented projects or takes more than two weeks to complete, my condolences.

Let’s look at each of these practices in turn:

1. Annual project selection: I am a strong proponent for strategic planning and the need for organizations to try to establish a medium-long term initiatives plan that looks beyond the next quarter but you cannot expect that projects identified at the beginning of your fiscal year will still all be valuable and prioritized appropriately by the third or fourth quarter of that year.   The frequency of portfolio reviews needs to be tuned to how often reasonable project requests are submitted.

2. Don’t purely focus on hard-dollar or capital-intensive projects.  In nearly all services organizations and a significant percentage of product organizations, resource availability is a primary bottleneck to throughput and a critical source of project schedule risk.  Given this, your project selection process needs to consider all projects especially those that consume internal resources.  You might be better off initiating a project that costs money, but can be mostly delivered using external resources (assuming of course, this project will deliver real business value!) instead of one that costs little but consumes critical internal resources.

3. If your project selection process takes more than two weeks to complete from the moment that reasonable project requests have been submitted, you are encouraging the genesis of “stealth” projects.  In addition, since most strategic projects have time sensitivity, the longer your governance committees spin their wheels in making decisions, the greater the likelihood that the market viability or business benefits of these projects will be reduced.  I am not advocating impulsive decision making – what I am recommending is a combination of a consistent, objective approach to evaluate projects in a rapid fashion, combined with a stage gate process that is able to kill off poorly performing or low value projects in a timely manner.

Traditional approaches to project intake & selection are losing their value unless you happen to be work for a company that operates as a monopoly (or at worse a very limited oligopoly).  Of course, even a monopoly situation won’t help if the market for your products or services is shrinking.