The Feld Framework For IT Leadership â€“ (Part 5)
March 3, 2010
My previous post talked about WHAT will we do. In this post, I will discuss HOW?.
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.
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:
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!!.
HOW will it be done?
- 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.
- 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.
|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|
|Phases||Businessâ€™s Role||ITâ€™s Role|
|Integration & Acceptance|
|Implementation & Deployment|