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."
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
result for the long term?
-Does
a strategic governance discipline help to streamline operation and make it more
effective, but slightly slower?
effective, but slightly slower?
- From an
*
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
* 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