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.


Insourcing for IT organizations

Most IT organizations are structured to becomes a monopoly within the firm and like monopolies are wont to do, they start taking their position for granted. They become large, expensive and slow in response to their customers i.e. the business. Arguably, this hurts the firm’s competitiveness in a big way.

David Rasmussen in Cutter advisor argues that IT organizations should be competing for providing the services like any other firms within a competitive environment . They also need to make the mind shift from speaking techno geek to business speak. He challenges the IT executives to define their value add in terms of EPS to earn the right of being the preferred supplier.

I agree wholeheartedly with this philosophy. What’s not mentioned in the article though is how to break the barriers to entry that IT creates. Often, the business rely upon IT to also make decisions about sourcing from other vendors. This is akin to asking your wife to select a girfriend for you (okay bad metaphor – but you get the point). Other times, the IT still remains in the equation through the backdoor of security and hardware provisioning. IT sometimes also create virtual organizations who act as conduit between business and the external service provider, creating communication barriers.

Business, ultimately, are left no better than where they started from. The competitive environment has to be equal for all participants, for the customer to be better off. What is needed is an ombudsman who can arbitrate on such matters and protect the customer’s rights to earn their value.

Will the real customer please stand up?

One of the prime requirements for the success of Agile Projects is to have an “onsite customer“. In reality the real customers rarely have either the time and often, the inclination to be involved with the development team on a full time basis. After all, there is a business that needs to be attended – things dont come to a standstill while the system is being developed. The accepted wisdom is to have business analysts serve as “proxy customers“, thereby leveraging the real customers’ time. Business analysts are presumed to have the necessary skills and experience to drive out the project requirements by having sessions with the real customer and therefore, be in the position to make the best decision for the project. So far so good.

Unfortunately,there is an additional layer that gets introduced within the fray.The real customer is often hands off, and a token customer is assigned to liaise with the business analyst. This is typically a junior member within the user community or a business analyst / domain expert working for the client.This person might have the knowledge of the functional area for the system, however they usually do not have the same level of authority and big picture outlook that the real customer does.

The risk of not having an onsite customer has now been replaced with a different type of risk – Risk of having a token customer. Listed below are some of its possible implications

1. The token customer’s future career / bonus is usually contingent on the mandated success of this project. Conventional wisdom about a successful project is the delivery of agreed functionality on time, on schedule and to the agreed resources. Usually such mandates are taken too literally and as a result, any form of negotiation is viewed as compromise.
2. Productivity of the team is assumed at the beginning of the project and subsequently, calibrated over a period of time during the iterations depending on the team’s performance. This may mean changes required either in scope, time or resources and usually, our token customer is not the best equipped to make the decision.
3. The token customer may have previous experience with developing a similar system and this could result in typical analysis anti-patterns such as “Re-inventing the wheel”,”Re-inventing the square wheel”, “Golden Hammer” etc. Scope creeps can occur as the token customer may try to shoehorn some requirements within the existing story list.
4. Difficult to establish the business case for the system as the token customer may not necessarily have the complete knowledge of the drivers.

Here are some of the mitigation strategies that have been tried before
1. Involve the real customer as much as possible, especially where key decisions need to be made. Showcases, iteration planning meetings, kickoffs etc. are ideal candidates for the customer involvement. Ensure that the meetings are short and therefore, would not tax the schedule of the customer heavily.
2.The success criteria for the project should get defined jointly between the team and the customer. This ensures that the mandate given to the token customer is aligned to the development team’s delivery commitment.
3. Educate the token customer on their roles and responsibilities within an Agile project. Give examples of different scenarios that occur within an agile project and the different decision points. Ensure that the escalation points are identified as well.
4. Manage the scope at story level tightly. By documenting all key assumptions made during the story identification, estimation and detailing, the BA will have the right arguments to make when negotiating with our token customer.
5. Structure the engagement to have a senior member of the development team emerge as a trusted advisor to the client.This senior member should be able to coach the real customers/ sponsors to identify the business value within the requirements.