Taking the “real” out of “real” estate negotiations

Having just participated in a couple of house bidding wars, I can see a real opportunity for improving the “user friendliness” of the process.

For those of you that have not experienced it, if you are one of the bidders on a property and the bidding war is taking place at the sellor’s home, you and your buying agent will wait outside the property for an extended period of time that covers initial presentation of your offer as well as any back & forth negotiations and updates to the offer.

While this is not as unpleasant an experience as a long term law enforcement “stakeout”, it is certainly not very comfortable especially in winter conditions.

Why not leverage an existing conferencing technology such as WebEx or LiveMeeting to create a simple remote offer presentation tool (video/audio/document sharing) that would allow each buying agent & their clients to be in their respective offices or homes but able to communicate and negotiate with the selling agent.  Obviously a verbal offer is worth the paper it is printed on, but it would be quite simple to have a means of capturing an electronic signature and transmitting that along with offer updates as they are made.

Not only should this make the whole experience more pleasant, but it would likely reduce stress and discomfort on the part of the buying agent and clients which should translate into better decision making.

This sort of technology change would need to be adopted across a full real estate board but the economies of scale that could be achieved by a board purchase would likely significantly reduce the costs to the individual realtor.

If “Up in the Air” showed a possible future state of long distance firing, why not long distance property negotiations?

The lady or the tiger – improving IT work intake

For your internal customers, submitting a request to IT may be analogous to the story of The Lady or the Tiger (I’ll leave it to your imagination to figure out which of your service areas is the Lady, and which is the Tiger!).

Although most customers are increasingly tech savvy and may be  leading the introduction of disruptive technologies within your organization, they may still not be able to determine whether they are faced with an incident (i.e. something is broken), a service request (i.e. a small change to an existing service) or a project – this is especially true if you have not come up with consistent, objective definitions for these different types of requests.

This confusion is perfectly natural – when you visit your car mechanic to complain about a rattling noise, you won’t usually know whether it is related to a factory recall, a minor maintenance issue or a major replacement.

The difference is that most customer service models provide a single entry point for requests and expect their skilled service staff will help the customer get a better understanding of what they are asking for.  This reduces confusion for customers, helps to reduce the incidence of stealth projects and provides a single process for control and measurement purposes.

This is not to say that your requests should all be tracked and managed in the same fashion – the people, processes and tools should differ depending on the nature of the request.  The entry point should be the same – whether that is a paper or online form, a phone number or an e-mail address.  Once a request has been received and assessed, further handling of the request should be performed by the most appropriate process.

Beyond improving the work intake process, this will also improve the process of providing status updates to your customer.  If the original work request is periodically refreshed with status updates, the customer will benefit from “one stop shopping” to know what’s going on.

The best way to avoid subjecting your customers to the tiger is to lock its door.

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.