In the last
article, we fleetingly talked about how large-scale RFPs need virtual Dojos.
This article builds on this idea and focuses on the future of IT acquisition
and your relationship with Virtual Dojos. It is important to push this link to
understand the true scale of Virtual Dojos in the future. In fact, we would not
be far from saying that the "Virtual Dojo" build will be as standard
as today's DR setup.
Application
development and delivery professionals are increasingly realizing that choosing
a traditional RFP-based vendor is inefficient, time-consuming, and produces
unwanted results. Some organizations, chiefly in the public sector, cannot
avoid the RFP process because legal requirements require it. But even such
organizations can streamline the process and speed up the selection of vendors.
The most common glitches that organizations encounter in RFP based recruitment
projects include:
Time-consuming
and resource-intensive selection processes - Application Vendor Selection
projects can take 6-12 months to complete, especially with a formal request for
proposal process.
Not designed
for new delivery models: The RFP has rightly been criticized as an undesigned
screening process for new delivery models. The cloud offering provider defines
the service description as a common model and standardizes it, denying
application development and delivery professionals the opportunity to customize
services or fit their in-house business environment. This affects the RFP
process. The classic RFP approach, an inside-out method, is no longer valid for
such solutions or services. Decision makers must first identify existing market
solutions and joint capabilities to determine if they fit the overall project
requirements.
Undesirable
and Undesirable Results - The more difficult the RFP process, the more likely
it is that more viable candidate vendors will withdraw after costing sales
considerations and anticipating the competitive position.
Don't
differentiate between mature products or identify innovators - RFPs contain
only requirements that buyers can now imagine. These requirements are generally
similar to capabilities that vendors can offer in current releases rather than
more visionary features that are not found in many products. As a result,
buyers do not consider newer or more innovative products due to feasibility and
trace history issues.
What is the
alternative?
Application
development and delivery professionals should move towards proof-of-concept
(POC) evaluations based on business process requirements rather than checking
functionality and features. Not all steps are necessary in all cases;
Organizations can adapt the methodology to specific situations with various
factors such as product maturity level and implementation methodology.
RFP and
Virtual Dojos: Combine the two
Given the
shortcomings of RFPs and the need for fast purchase confirmation points, we
believe that the Virtual Dojo is a perfect fit for the needs of the application
development and delivery team. Virtual Dojo will be the place to test concepts
in a real environment, allowing the organization to focus on large-scale
adoption of IT projects, to deliver them to their clients. Virtual Dojo will
also allow your distributed workforce to collaborate on a dynamic, fast, and
flexible implementation. The goal of Virtual Dojo in such an environment is to
provide organizations and suppliers with a pay-per-use option for a practice.
Simply put, it's a "hypothesis-based experiment" with no capital
investment. This will help them achieve innovation faster at lower costs.
To
demonstrate how Virtual Dojo can help in a real environment, let's take the
example of a global, independent company that "makes and distributes
heating, ventilation, and air conditioning (HVAC) systems, commercial
refrigeration, and food service equipment and technology. Security." This
company wanted to integrate its ERP applications across its multiple global
units and offices. A practice of this size and complexity would require a
virtual Dojo to allow for some real-time concept testing to find unwanted and
undesirable outcomes one might encounter. Actual integration project.
techdirtblog slashdotblog justhealthguide healthandblog supercomputerworld
