Take the agility test

Michael Hugos has come up with an agility test for the IT executive.

Take it. Get your clients and colleagues to take it. Compare notes. Learnt anything new ?

What is the business case for a disruptive business model / technology ?

Imagine being commissioned by Chad Hurley to work on a project for “Online video sharing” or by Steve Jobs to work on a project to deliver “Digital Music Player with a cool interface”. What business case or strategy would they have shared ? There was no existing market for their inventions before they introduced it. They could share with us their vision as shaped by the trends , the changing customer behaviour and the enabling technologies , but they would have been hard to pin down on what they thought the business benefits case might look like. In fact, Youtube did not even have a revenue model till a year after its launch

What does this mean for the well-intentioned analyst who believe their job is to protect the customer’s stakeholder value by coaching them against investing in such projects ?

The truth is that it is not always possible to judge disruptive technologies or business models using traditional tools of analysis. In fact, Clayton Christensen, the Harvard Professor who coined the term “disruptive innovation” advises us of the following

“In highly uncertain situations that typify disruptive innovations, following the typical strategy-making process just doesn’t work. In these uncertain situations, some companies believe they need to fly by the seat of their pants. However, companies can follow a rigorous process by using an emergent strategy supported by a discovery-driven planning process that enables them to adjust their strategy when they encounter unanticipated opportunities, problems and successes.”

As a business analyst the role is more about supporting this emergent strategy development process and not just a resource allocation filter. Admittedly this requires a significant mind-shift. Michael Hugos gives us a very important mantra – Be strategically focussed and tactically agile to meet the needs of a customer in an dynamic business environment. Delivering business value is as much about offering flexibility for the business to change direction as it is about delivering incremental revenues or saving costs.

Technical Debt Part 2

Following PierG‘s comments, I had further discussions with my colleagues and realised that he and I may be speaking about slightly different things. Technical debt can be generated by either of these

1. Technical debt generated from having poor safeguards such as bad testing, insufficient code reviews, no refactoring etc is bad (See Thomas Looy’s post )

2. Technical debt generated from having made a conscious decision about achieving short term fix that includes things like having stuff in a configuration file, static html page, manual workarounds etc.

One is a clear compromise on principles of working whereas other is a conscious well thought out short term fix. I suspect PierG had the former in mind when he talks about taking on technical debt as wrong.

Technical debt

There is an interesting ongoing conversation I am having with Pier G around technical debt.

In one sense, “Technical debt” is a brilliant term that establishes the debtor’s(the system) obligation to repay at a future point.Until that point is reached, this debt will have to be serviced with interest payments ( harder maintenance, lesser flexibility etc).

In another sense, the word technical seems to imply that the decision is taken by technical stakeholders, which is simply not true.This is not just a technical decision. It is about features, it is about investment and it is about opportunity cost.

Pier G says ” And as a general rule I prefer to think that making a technical debt is wrong!”

It is all right to have a preference, but it certainly is not his sole decision (unless he is a 1 man army building software for himself).

To be fair, he also says “And … having someone in the team who’s able to decide when it’s time to make that mistake is a GREAT value.”

Hurrah !! We are in concurrence except that I wouldnt call it a mistake, though it might be one.

One has to judge every decision point with the business value yardstick to ensure that correct decisions are being made with available information at that point of time.

Comments ?

Operational Art

From Answers.com

“Operational art translates the joint force commander’s strategy into operational design and, ultimately, tactical action, by integrating the key activities at all levels of war”

In IT parlance, this means translating the business strategies into IT organizational design and tactical project selection to maximise the organizational value. It is about IT leaders being perceptive of the business needs and spotting opportunities for improvements.

Michael Hugos provides an interesting example in his post “Turning Business Strategy into IT action”, where he provided a business solution which not only helped the business overcome an inefficient process, but also helped long term sales and revenue prospects for the company .Little surprise that he has been the recipient of CIO 100 award twice for innovative use of technology and business vision.

Here’s a set of mantras for growing and nurturing the relationship using the Operational Art terminology.

  1. Understand the synergy
    Be cognizant of the organizational drivers. Too often they get presented in a disjointed fashion like a giant jigsaw puzzle.
  2. Use Simultaneity and depth for business solutions
    Use all available resourctes to come up with creative solutions for client and their customers
  3. Anticipate the business needs
    Remain alert for the unexpected and for opportunities to exploit the situation
  4. Have a Balanced team
    Have a team of mixed capabilities that can fulfill the task
  5. Leverage existing advantage
    Maintain competitive edge by constantly seeking opportunities to improve existing situation
  6. Timing and tempo
    Act decisively and quickly
  7. Understand your operational reach
    Know what your capabilities are and the cost of your services
  8. Improve Forces and functions
    Improve existing IT capability on both technical capabilities as well as operational processes
  9. Arrange operations
    Plan a phased execution of projects to achieve the desired business outcome
  10. Develop Centers of Gravity
    Create an agile organization with a motivated workforce and enhaced technical and process capabilities
  11. Act on Decisive points
    Business critical decisions that would influence the long term organizational future.
  12. Culmination
    Fail fast without wasting huge amount of resources
  13. Termination
    Terminate the initiative when the incremental cost of delivering exceeds the benefits

It would be very hard for business to not respect and like someone who is so switched on about their needs and who finds creative ways to fulfill them.

Financing Agile Projects

Here’s a story about a major toothpaste manufacture .In a bid to improve their sales, they decided to offer 400g toothpaste for the price of 300g. A normal 300g toothpaste, if it lasts 30 days in a household, could now potentially last 10 days longer.This wasnt good. It would affect long term sales. To counteract this, the manufacturers got clever.They increased the diameter of the toothpaste tube outlet. They were counting on the customer maintaining their behaviour. Consumers would cover the length of the toothbrush irrespective of the volume of toothpaste .

The takeaway for me in this story is that consumers were not able to extract value out of the increased offer because they focussed too much on a single dimension. Business firms also run their departments using a single dimension – budgets be it in monetary terms or resource terms. Whilst this soft constraints based model worked well with the predictive methodologies which had discrete decision points, it does not sit well with the Agile methodologies.

Executives need to change the way they think about IT project financing. Agile projects are like the toothpaste with extra 100g. To extract the true value, the consumer needs to change their behaviour. Agile methodologies, done in the right way, deliver to business strong risk management, flexibility and quicker returns. The following behavioural change is required for project financing

1. Budget based financing –> Line of credit / Venture capital financing
Provide different levels of capital based on demonstrable results for IT projects.

2. Returns –> Risk vs Return
Focus on mitigating risks as much as earning returns

3 Fixed Price –> Real options
Seek more flexibility to change the direction of the program of work

4. Worrying about sunk costs –> Fail fast
A quicker feedback cycle helps prevent overcommitment

Stakeholder value and not business value

The classical view of a firm has been that is a profit maximising organization operated by professional managers on behalf of the shareholders.All the activities of the professional managers on behalf of the firm are geared towards maximising the shareholder value.

A more balanced view is that a firm is more than simply a financial vehicle and has more constituents than shareholders alone.A firm combines the interests of customers, employers and suppliers, all of whom contribute to the firm’s success. This approach is known as “stakeholder approach” and makes the firm’s managers accountable to a wider community than just the shareholders.

In Agile, the approach has been to establish and validate the “business value” of a project and its constituent stories for efficient prioritisation. This has often led to the confusion amongst project team members. The connotation “Business Value” establishes an unnecessary connection with “Business” i.e. the project sponsors, inadvertently leading to prioritising functional stories over non-functional stories.

One approach to solve this problem has been to demonstrate that even non-functional stories have “business value”. For example,it is possible to show that “Logging” allows the Application support team to spend lesser time on defect analysis, thereby reducing the turnaround time for the defect. “Business” would therefore be in a position to prioritise such a technical story as well.

Whilst this approach has been successful, it fails to achieve the mind shift that is required to make it happen consistently. There is a wider community out there which will determine the success of the project such as the project team members, the application users, the support team members etc. All of these are stakeholders who have an interest in how the project shapes up and should rightfully, be involved within any prioritisation exercise.

Only when we start looking for “Stakeholder Value”, will we ensure that the wider community is not forgotten. The term “Business Value” needs to be consigned to history.

My colleague,Marc, has gone a step further and suggests associating drivers for each stakeholder to achieve the same result.