• Planning is everything but plan is nothing however, planning is not a precision engineering. Developing a perfect plan for a task at hand is nothing but developing a perfect plan to lift the moon.  The plan will look so perfect and will exceed compliance requirement but will not meet the objective.  There are quite a few project/compliance managers thrive for a perfect plan. It may appear, on the surface, the plan is going to work as laid out, but it is a plan for a impossible task. At the same time, I’m not suggesting not to have a plan or wild wild west approach. My point is, A balanced agile plan is vital for a successful implementation of a project. Open source project is not an exception to this approach. It is extremely critical to create a balanced agile plan for the open source implementation.

    What is a balanced agile plan?
    It is a plan dynamically changes based on the requirements and has a good balance on accomplishing compliance requirements, exceeding end customer expectation and full filling the project objectives.

    Create a balanced agile plan for the open source implementation.

  • Iterative analysis required to classify differentiating technologies and others. Generally, a logical straight forward approach does not fetch approvals from senior and executive management team. Strategist and architects must understand each senior and executive management team members individuals concerns, passion, interest, motivation and their vision and collate it. Work with them individually and as a team to build the consensus on differentiating technology and others. This classification plays a vital in defining the open source strategy.  The differentiating technology depends on the industry you are in. In oil and gas sector, safety plays a most vital role and classification is made based on those attributes. In banking and finance sector, compliance, information security plays a most vital role. For any companies, the credit ratings are important. Particularly it is very important for banking and finance sector. Explore the criteria used by credit rating companies, bank examiner, external investor to evaluate a company in banking and finance sector and identity the role played by IT in those scenario. It will provide insights on differentiating technologies and other technology category.

    In this step, strategist or architects makes a case for technology investment plan. Differentiating technology requires investment and others category technology requires cost reduction or optimization. Objective in this step is to have net saving projection to the over all IT operating cost.

    At end of this step, you will have the list of technologies which requires cost reduction and investment. In the next blog, I will write on the frame work to reduce technology cost.

    (Note: If you want to follow the story of IT strategy formation in the absence of business strategy, please start from this blog post)

  • A new revolutionary or evolutionary ideas are not agreed in one step nor in first step. It is a process to build consensus even to explore a new idea. An IT strategy may be an evolutionary or revolutionary idea based on the current state of an organization.  In the IT strategy definition process, the idea of change must be agreed by  senior and executive management of an organization before even a new IT strategy definition process is kicked off.  A need and purpose for a change in an IT organization becomes imperative when there is a business strategy clearly defined.  How do you define IT strategy when there is no clearly defined business strategy. In the previous post, I recommended that, in those scenario, create an IT strategy to improve the value of IT organization.  Since the IT valuation process and methods are so vague, I suggest, it is not wise  to start the discussion with senior executives as to increase the value of an IT organization as IT strategy.  The moment an IT strategy person starts the discussion of improving  value of the company, the speculation starts with wild imagination which are destructive.  

    First step in introducing a change is to have courage to talk to executives of the organization and get their blessings for your ideas. The philosophy is, people will listen to your idea when you tell them nicely and you will have their blessings if it is a good one. The rank you hold in the organization does not matter and you will be able to connect with them, make them listen and get their blessings.  Result of the attempt to make the connection with your idea with your ideas  may be career threatening but,  as a strategy person, you need that courage to take the risk to make that change in the organization.

    Reduction in operating cost of an IT organization is an easy sell. If someone has an idea to reduce the operating cost by 20-25% with out the reduction of services nor resources, then you will get everyone’s attention in the board room. Open source platform would be a good starting point if it is not fully maximized in the organization. Receive conceptually concurrence on embracing and encouraging open source platform in the organization. If that   is accomplished, that is a great starting point for a long road to reach the end goal – increase the value of an IT organization.

    It goes back to the abstract strategy approach  “think big, start small and run fast”.

    Once open source platform adoption is agreed than the next step is to show results. Look for a commercial software product that has significant on-going maintenance cost. It could be due to license, complexity, resource availability, hardware  or others. Identify an area carefully and diligently analyze the cause for higher cost. Study the availability of open source equivalent and its capabilities, capacity, supportability and maturity. Compare and contrast it with commercial product. If it is feasible to show cost saving with the open source replacement, identify technical resources and perform end-to-end proof of concept and show the results to the senior management. 

    When people run fast, it is assumed that you reach the destination sooner. Generally, the audience does not have the curiosity to inquire the distance you run.  When you do a first proof of concept to prove your first idea of a long road, the time taken to accomplish it is very important. Don’t take more than 5 weeks to complete the proof of concept to show the results. Draft an implementation plan with risk.

    Details on how to receive concurrence on open source adoption from senior and executive management will be in my next post..