My previous post talked about WHAT will we do. In this post, I will discuss HOW?.

HOW HOW will it be done?

The pathway from current state to the future state. Business and IT organization do heavy lifting and follow the following three principles: HOW Principle 1: Define and design a business application and technology blueprint andarchitecture before beginning investment and construction. HOW Principle 2: Enforce a “Common Way” for development and quality engineering. HOW Principle 3:Be disciplined in program and project management.

HOW (Execution) pathway is the most important for the success after the WHY and WHAT. Historically, most enterprises fail when they arrive at this plank. Once a well articulated plan on WHY the change is needed and WHAT to change is done, many executives consider that plan to be (a) a threat, naive, or impractical or (b) on the spot. In case of (a), the executive fails because they do not believe and are not vested in the proposal and in case (b) the executives and board members have no confidence in the team to deliver the IT enabled business transformation in time, and on budget, with expected returns. The Feld Framework provides the principles of execution that provides a clear direction for execution and increases odds of success. HOW Principle 1—Key requirement is that team has developed and understood the business architecture with the IT architecture and the construction plan before building the IT infrastructure, software applications, and deployment.  

• Layer 1: Business architecture—Key Role Player: Executive team (with CIO). Time boxed: 90 days. Process co-owners: IT and business leaders. Focus on breaking down necessary investments into actionable, discrete pieces of work. Warning: do NOT delegate or skip this layer.

   

• Layer 2: IT architecture (applications, information and technical architecture)—Key Role Player: CIO/IT leadership. Time boxed: 90-180 days. Focus on the details required to construct a quality product at the “deal” price. Warning: No one should start programming or acquire IT hardware/software WHILE planning for IT architecture is going on.

  Leadership team should make effort to lead this and not delegate it to be successful. The main cause of failure comes from lack of executive leaders’ involvement in leading this pathway. HOW Principle 2—A large transformation work results in many changes in architecture, business processes, organization, structures, incentives, cultures, financials, analysis and reporting that must be managed and harmonized as systems are built and deployed. The business work streams should be well-integrated with the systems development lifecycle. Enterprises select a development methodology, but fail to enforce it across because of teams choosing not to follow the methodology, or because the methodology is so rigid and enforced with overbearing bureaucracy that it kills the speed of development and the motivation to carry it out. These two pitfalls should be avoided in building the operating culture. The success of strategic multiyear projects depends on a successful release plan. This plan should address the following clearly and concisely:  

• Major releases are done between every three to twelve months (typically six months) apart. All business work streams are included and synchronized.

   

• A consistent way of managing delivery of software, function and organizational change to the business.

   

• End-to-end use cases or real business scenario testing using optimized resources.

  Provide rally points for all organizations to converge at specified tollgates.

HOW
	Transformation Release Methodology
	WHY	WHAT	Business Process & Application Changes				Integration	Deployment
	Strategy	Business Model	Technology & Infrastructure Changes
			Organization & Culture Changes
			Location & Physical Asset Changes
			Financial and Metrics Changes
Tollgates	1		2	3	4	5	6	7

Any methodology should include the following phases or tollgates. The respective roles of business and IT switch around during the above 8 phases as shown below:

Phases	Business’s Role		IT’s Role
	Lead	Support	Lead	Support
Initiation
Requirements
Design
Construction
System Testing
Integration & Acceptance
Implementation & Deployment
Support

The methodology deployed should be enterprise-wide and it should include progress to plan, quality metrics, and so on. Remember that the total cost of ownership is significantly higher for a poorly designed and engineered system compared to a well-designed high quality system with initial high cost of development. HOW Principle 3—This principle provides life and motion to the HOW principle 1 and 2. Both principles 1and 2 are critical processes and structures, but how they are managed together will lead to success or failure. This requires that IT organizations have a culture of build to delivery, with a strong project review process. The project review process should be for self-disciplining and keep at large a methodology police or process cops. Bureaucracy is harmful to the process as well. Setting a cadence for reviews, meetings and tollgates helps to establish participation and management. Meetings should be only during designated meeting times and rest of the time should be devoted to work. Maintenance and support team should be integral part from the beginning. The quality of HOW is inextricably tied to the quality of WHO. In my next post, I will discuss, the next plank, the WHO!!.