Thursday, December 20, 2012

Good, Fast, Cheap: Can CIOs Have them All

The CIO’s set of criteria should balance a multitude of viewpoint above, to make an effective choice on "built-to-last or build-to-change."

Holiday season actually stimulates creativity, and spurs optimism; from one of IT performance debates: “good cheap, fast for enterprise application development, which two should CIO pick?” Many commentators set positive tunes and think it possible to have them all.




1.    Well-defined business goal and project scope make it possible

Broadly speaking, it completely depends on the company you work for, their goals, long term strategy, and the drivers for why you are doing the project, it also depends on what good and fast means for the organization

  • Good- what really solves a business problem? The user defines it;
  • Speed- iterative process, cycle time to process the scope of work. PM and user jointly define this.
  • Cheap- most important as it defines ROI. Let vendors compete hard to get the contract. Having good linkage to sourcing function will get the lower price

From old experience, sometimes Good and Fast doesn't always go together. For enterprise application development,  it is best to make sure you have the best solution that meets the organization's needs, budgeting time and finances accordingly to avoid costly headaches usually associated with "quickie' development projects.

The main issue is the ability to clearly define and agree on the scope and IT / Business working together to deliver success. As long as a due diligence process is done with what good or fast is going to do for the organization, then the rest depends on the execution strategy. Some times, good is best for the organization in the long term as far as the ROI is concerned. At other times, fast turn around may be the best alternative for better returns. In executing the strategy, the CIO must weigh in on scope, time, cost, resources, quality, and risk mitigation before settling on the right path. If you follow the philosophy right and manage it well, all three parameters are available to you.

In addition, the key to success is managing deployment into operational service while following the concept of things being "useful but incomplete". Generally, applications are tools for people to use in their daily work,  so it's necessary for all to have a clear understanding of what a tool is for and, even more important, what it isn't for. 

2. Agile methodology and Cloud envelop makes it possible

 It's a myth that you have to sacrifice any of the three. Most traditional software projects fail because the business requirements change before the project is completed. Agile/ SCRUM approaches help to overcome these issues by breaking requirements and work into discrete sprints. But this approach can fail too if stakeholders lose patience with progress towards long-term development goals. 

Hopefully, the "pick any two" approach is becoming obsolete... It is becoming increasingly possible to achieve all three with different/creative SDLC methodologies, cloud technologies (IaaS, PaaS), and appropriate leveraging of global solutions...

Though there’re positives on Agile development methodology as a silver bullet to solve the “Good, Fast, Cheap” dilemma.  More often than not it is the loose ends that stop a development project from being successful, In essence, and as almost always, it is a question of discipline and leadership,  not so much of method. Further, the fourth dimension needs to be added to the equation: Complete. While it is true that agile methodologies can deliver functional components of a larger solution to the business in pretty short order and do it with a high degree of quality, in the end, you are still only getting part of the picture until every piece is completed.

3. Oversight/process governance helps to maximize business value

It has always been possible to achieve all three (relatively speaking) and it is easier now than ever before. From a business governance perspective, it requires organizations to hire well, communicate well, plan well, trust their IT staff when they are unable to completely understand the intricacies of every single technology, and fund appropriately. This is not an impossibility, but a measure of the maturity of a leadership team. Impossible IT projects are more a reflection of overall lack of leadership not only from the CIO but from the organization that as a whole lacks the commitment to see the "bigger picture."

The problem, therefore, isn't just in the SDLC, but rather in business oversight and process governance.

  • At the strategic level, the executive team shall make well-informed choices which include considering the business impact of different approaches, the pattern of benefit delivery, the risks involved and what else is going on in the portfolio. The key point is, value is multi-dimensional and perception-based, leverage upon asking
         -Does the faster operation at daily base help to achieve the good or worst strategic business
          result for the long term?
          -Does a strategic governance discipline help to streamline operation and make it more
           effective, but slightly slower?

  • From an Enterprise Architecture perspective:  rapid engineering on a modular architecture is possible without a compromise on quality and performance. It all depends on which "Class of applications" one is building today,  it may depend on nature of the project as well as the budget limit., etc An effective EA practice will improve business capabilities below:
            * Agility-Doing things better, faster.
            * Elasticity-Scale up/down more seamlessly
            * Resilience-From Risk Mitigation to Risk Intelligence
            * Flexibility -Multi-dimensional choices to optimize the customer experience.
            * Value Proposition-Economical value, quality value, utility value, social value

  • At tactical level: It's the age-old problem on balancing the need to get software done quickly (because there are business reasons to do so) with the desire to get it done with the feature depth that developers and users might wish for (because sometimes, if it doesn't do the whole job, it wasn't worth doing). Create a dev group without silos for teams doing requirements, software architecture, hardware architecture, development/engineering, Q/A testing, to implementations/training 
  • How to manage stakeholders’ expectation? Go ahead and use the cloud, agile, and any other techniques to manage risk and increase productivity but please don't be surprised when your new level of performance is taken for granted and a senior stakeholder becomes convinced that someone else can do more in less time and for less money. The need to manage stakeholder expectations and help them make well-informed choices is not going away for very long. 
  • Bonus question: If you are (or have been) an enterprise application developer, how does the CIO make the decision about balancing "get it done quickly" and "build it to last"? How do you wish they made the decision? How should CIO choose the schedule for a specific project? or how should CIO make a list of criteria that would help a new manager make the correct decision? 
In summary, the CIO’s set of criteria should balance a multitude of viewpoint above, to make an effective choice on "built-to-last or build-to-change," the goal shall not just focus on the application itself, but the business vision & end goal, and how to cultivate a set of business capabilities not just fitting today, but for the future; Good, Fast, Cheap, CIO may have them all.







0 comments:

Post a Comment