Determining the infrastructure implications
The acquisition of a packaged application for the business solution includes the following three components:
Software costs (and any associated maintenance costs)
Services or implementation costs for the delivery of the solution
Hardware or infrastructure costs
The Sure Step
Architecture Assessment Decision Accelerator offering deals primarily
with the third component of the business solution acquisition costs. It
bears mention that infrastructure costs are incurred regardless of
whether the solution will be on-premise, that is, physically located on
one of the customer's sites, if the solution is hosted by a third-party
provider, or it is an online solution. The requirements will definitely
vary depending on whether the solution is on-premise, hosted, or
online—for example, the former will require more hardware or server
components, while the latter two may have higher bandwidth and latency
needs.
Given the understanding of
the customer's requirements and the proposed solution blueprint to meet
the customer's needs, the sales team is able to develop the conceptual
architecture of the solution in this exercise. This exercise, which is
typically carried out by technical solution architects or technical
application consultants, includes developing the high-level hardware and
infrastructure plan. Besides the business requirements from the
previous activity and the solution blueprint, other inputs considered
for this activity include projected transaction volume, key user
scenarios, and any other benchmarking activities. The infrastructure and
hardware recommendations that result from this exercise are then used
by the customer to obtain the estimate for the infrastructure to support
their business solution.
The Architecture
Assessment DA offering also provides deeper offerings to help the
customer in other areas such as performance projections and
benchmarking, and high-availability and disaster recovery planning. A
customer could have a concern in a specific area of their business that
generates high usage or traffic patterns of the solution. Or due to the
mission-critical aspect of the solution, they may require that the
infrastructure plan encompass failover mechanisms to minimize or
eliminate downtime. The customers may also want the plan to include
disaster recovery, in order to ensure that their data is protected
appropriately and can be recovered in the event of failure. For such
situations, the Architecture Assessment DA offering has more technical
sub-offerings, including the Proof of Concept Benchmark DA and the High
Availability Disaster Recovery DA. Both of these offerings are performed
by very senior and experienced technical resources, and can be used to
provide the customer with the desired answers and allay any concerns
about the operation of the system.
Estimating the delivery costs, approach, plans, and roles
The Sure Step Scoping
Assessment Decision Accelerator offering deals with the second component
of the business solution acquisition costs noted in the previous
section—the services or implementation costs for the delivery of the
solution. But this offering provides far more than just the costs—the
decision point for the overall approach to delivering the solution,
resulting in the development of a high-level schedule and the delivery
team structure.
The first step in
executing the Scoping Assessment Decision Accelerator engagement is to
determine the overall solution rollout approach. In this exercise, the
solution delivery team and the customer work together to determine
whether the solution can be rolled out in smaller, manageable releases,
or if the entire functionality is desired at the time of solution
go-live. Rolling out the solution in multiple releases is known as a phased
approach to solution delivery, wherein select solution functionality
is enabled in individual releases, with each release building on the
prior one. The alternative to a phased approach is delivering the full
solution in a single release, which is often referred to as the big-bang
approach to the solution delivery. A key point to bear in mind is: the
reader should not confuse the phased approach with, say, the phases of a
waterfall solution delivery method. The waterfall phases break down an
overall project or release into smaller segments, while the phased
approach is a technique to break down the overall engagement into
multiple projects or releases.
The larger the scope of the
project, and/or greater the reach of the solution within the customer
organization, the more desirable is a phased approach over a big-bang
approach. The following are the supporting reasons:
A phased approach
enables the customer organization to start using the solution much
sooner, facilitating a smoother adoption of the system. As the scope for
each release is limited, the delivery team can promote that part of the
solution quicker to production, thus enabling users to start working
with the system earlier than they would have with the big-bang approach.
Solution
testing can also be more manageable as the limited scope may mean a
more focused applicability of the solution and fewer workflows that are
impacted.
Customers
can also start to benefit from the solution sooner, by selecting those
requirements that are important to them but could be easier or quicker
to solve with the new solution.
For
complex solutions, customers can also earn valuable support for the
project from early adoption of the system, resulting in a quick win for
the delivery team, which, in sales/consulting jargon, is often referred
to as "going after the low-hanging fruit".
From
an overall risk management perspective, the phased approach is often
seen as the less risky strategy for all the reasons noted here.
Of course a phased approach
is not always the best one. Sometimes, the customer organization will
need all the features enabled before they can begin using the system. In
that case, the big-bang approach may be the only alternative. But the
big-bang approach also has other advantages:
If the same user base will be using the addition functionality, they will not need to be retrained at every release.
Solution
testing will encompass all likely scenarios, so the customer
organization can find out, once and for all, whether or not the overall
solution will meet their needs. This could also potentially reduce
overall testing costs. In a phased approach, you test the scenarios for
the first release, and then potentially retest those scenarios in
concert with the others when testing for the second release.
"Throw-away"
interfaces or integration code does not have to be created in instances
where part of the system being used may necessitate external sources to
be temporarily connected to the new system.
Regardless of whether
the overall solution can be rolled out using a phased or a big-bang
approach, the customer and solution delivery teams also need to select
the delivery approach for the individual releases. Solution delivery has
two distinct approaches—waterfall and agile.
Waterfall:
A sequential process that depicts a linear flow of activities from one
phase to another, culminating with the solution being promoted to
production and then into operation.
Agile: An
iterative solution development method that promotes a collaborative
process between the resources that own and specify the requirements for
the solution with the resources responsible for the development and
rollout of the solution.
Just as with the overall
phased or big-bang approaches, there is no right or wrong with either of
the solution delivery approaches; it is just a matter of organizational
preference. Some organizations prefer the structure of the waterfall
approach, as it clearly breaks down the activities in each phase leading
to the deployment of the solution. Others prefer to let the
requirements of the solution evolve during the development activities,
which is a characteristic of the agile approach. The Microsoft Dynamics
Sure Step methodology supports both approaches by offering Standard,
Enterprise, Rapid, and Agile workflows (plus an Upgrade workflow for
existing customer deployments).
The next step for the sales
and solution delivery team, in the execution of the Scoping Assessment
Decision Accelerator offering, is to work with the customer and
understand their solution priorities using the solution blueprint as the
input. To do so, the delivery team will need to identify the inherent
constraints, as well as any imposed constraints for the project.
Inherent constraints are often imposed by the system—for example, a
system will need a certain logical configuration order, such as starting
with the chart of accounts, and then moving to the general ledger of an
ERP system. Imposed constraints, on the other hand, are typically
external constraints—for example, the customer may have licensed
specific software that is up for renewal, which the customer does not
desire to do, and would prefer that the corresponding module of the new
solution is enabled before the license of the third-party software
expires. Understanding these constraints allows the solution delivery
team to come up with a schedule that meets the customer's objectives for
the new solution.
The next step in the
execution of the Scoping Assessment Decision Accelerator offering is to
determine the effort required for the solution deployment activities.
This includes the solution setup, configuration and development, the
environment setup, and the user training needs, among other things. Many
organizations develop costing spreadsheets and databases to support
them in these tasks, and typically populate the spreadsheets based on
their experiences on similar past projects. Other organizations use
Estimator tools that include base values for enabling specific
functionality. These base values may have been garnered from past
history, but typically they constitute the average value from the
experiences of several consultants over multiple projects. As such,
these Estimator tools provide a consistent, repeatable framework for
estimating the solution delivery efforts. Of course, the Estimator tools
would also provide a means to override a given estimate, say to add an
uplift that may be needed in riskier engagements.
The Sure Step methodology
includes two such robust Estimator tools for the Microsoft Dynamics AX
and Microsoft Dynamics CRM solutions. The output from this estimation
exercise produces the overall effort for the solution deployment in the
desired time unit, such as hours or days. This effort can then be
translated into the solution delivery costs, by associating the
corresponding resource rates for each of the tasks. The next screenshot
shows a section of the Sure Step Microsoft Dynamics AX Estimator tool:
Armed with the
information on the overall solution rollout approach, the individual
release delivery approach, the inherent and imposed constraints, and the
effort needed for the solution deployment activities, the sales and
delivery teams can determine the solution rollout schedule in the next
step.
Reducing the risk perception
While the Sure Step
Requirements and Process Review, Fit Gap and Solution Blueprint,
Architecture Assessment, and Scoping Assessment Decision Accelerator
offerings are designed to help the customer envision their future
solution and the costs associated with delivering that solution, the
Proof of Concept DA is provided to allay any potential concerns for the
customer in specific areas of the solution, while continuing the theme
of solution envisioning as well.
The Proof of
Concept Decision Accelerator offering requires the utilization of
solution delivery resources to set up, configure, and customize the
solution to a specific subset of the customer's requirements. As the
customer has not yet acquired the software licenses, the delivery team
will typically build their own demo environment to execute this solution
setup, such as in a Virtual PC (VPC) program that virtualizes a
standard PC and its hardware. After the solution setup has been
completed, the delivery team will set up a solution demonstration in a
conference room setting, where the customer's business and technical
decision makers will be able to preview and criticize the solution
features.
The Proof of Concept DA is an
appropriate offering in instances such as when the customer, after going
through the Requirements and Process Review, Fit Gap and Solution
Blueprint, Architecture Assessment, and Scoping Assessment DA offerings,
is fairly comfortable with the Microsoft Dynamics solution but still
has concerns in specific areas. There are two key points here. The first
is that the customer is fairly certain that the proposed Microsoft
Dynamics solution will meet their needs, and the second is that the
sales team identifies those specific areas where the customer is looking
for additional proof points. These are important points to bear in mind
because the Proof of Concept exercise should be a time-bound, limited
scope engagement exercise that helps the customer with the final
decision point before moving forward with the system acquisition. From
the service provider's perspective, these points become crucially
important if the Proof of Concept DA is positioned as an unpaid
engagement, as resources who may otherwise be working on billable
customer engagements are being called upon to work on this prospective
customer's requirements.
The Proof of Concept DA
can also become the starting point should the customer decide to move
forward with the proposed solution. If the due diligence done by the
delivery and customer teams includes configuration of the system, and/or
custom code is written to meet a specific requirement, these should be
carried through to the implementation of the system. This is another
aspect where having a customer lifecycle methodology such as Sure Step
allows the teams to build upon the work from the previous phases, even
if that previous phase happens to occur during the sales cycle.
Another point about
the Proof of Concept engagement is the potential that the project scope
or solution vision may be altered after the output of this exercise. It
is quite possible that the customer team may think of additional usages,
or request a different solution to meet their requirement. In these
cases, the sales team will need to go back and update the solution
blueprint and corresponding delivery estimates, and perhaps even
redesign the proposed system architecture.
Estimating the Return on Investment (ROI)
The Sure Step Business
Case Decision Accelerator offering is designed to provide Return on
Investment (ROI) analysis for the solution that can help the customer
executives understand the value proposition for the solution and justify
their investment. The Business Case DA determines the quantifiable
business value for the given investment, as well as the Total Cost of
Ownership (TCO) for their new system.
Determining the impact of the solution on the
customer organization and articulating the value is a very important
activity for the customer and sales teams. When there is a value
associated with the solution, it becomes a lot easier to drive executive
support, which is critical for the project. Also, having clearly
defined value projections will help motivate the teams through
inevitable struggles during the course of the implementation of the
solution. In some situations, companies are hesitant to share certain
financial information, but given the investment they are about to make
in terms of money, resources, and time, it behooves them to go through
this exercise so that they can clearly understand the potential for
organizational gains with the new system.
In the Business Case
DA, the customer and service provider teams work together to determine
the direct and indirect benefits associated with the proposed solution.
Direct benefits have measurable impact on the budgets or costs. Examples
of direct benefits resulting from the new system include:
Increased inventory turns and the resulting lower inventory costs
Reduction in personnel needed to accomplish a task
Increased orders processed through the system during a given period
Reduced returns due to wrong shipments
Indirect benefits, on the other
hand, are not easily quantifiable. They may need observation and
projection of estimated impact. Still, these are important factors to
account for. Examples of indirect benefits from the new system include:
Productivity increases gained from better visibility
Reduced administrative overhead costs
Reduced communication costs
Increased customer retention
The Business Case DA also
pulls together all the costs associated with the acquisition of the
solution, with which the customer gains an understanding of the TCO for
their new system. TCO cost elements include solution acquisition costs,
operating costs, and long-term costs.
As mentioned earlier,
the solution acquisition includes three components—software costs (and
any associated maintenance costs), services or implementation costs for
the delivery of the solution, and hardware or infrastructure costs. The
software costs come directly from the licensing agreements. The Scoping
Assessment DA produces the cost estimates for the services delivery,
while the Architecture Assessment DA produces the inputs to determine
the hardware or infrastructure costs.
Operating costs include
costs involved in training and retraining the personnel in the customer
organization, their resources involved in the testing of the solution,
and other costs such as insurance, electricity, and other physical
infrastructure needs. Long-term costs, on the other hand, may include
costs for periodic solution reviews, and costs for solution upgrades and
scaling.
The benefits and costs form
the basis for the determination of the Return on Investment for the
solution. Sure Step provides an effective tool for ROI calculations,
which has been developed by an independent analyst firm, Nucleus
Research. The standardized tool provides a systematic way to capture the
benefits and costs, which in turn allows the teams to project the
expected ROI, payback period, and/or Net Present Value ( NPV)
for the investment. Separate ROI tools are provided for the analysis of
ERP and CRM solutions. The following screenshot shows the report
section of the Nucleus Research ROI Tool for Microsoft Dynamics AX:
The service provider
executes the above steps of the Business Case DA to develop the
financial results and report. The financial results include insights
into risk assessment areas such as capital recovery and variance
potential. These results are then provided to the customer's business
executives and calibrated as needed.
Besides the financial analysis noted previously, the Business Case DA also helps the organization determine Key Performance Indicators (KPIs) and Conditions of Satisfaction (COS)
for the new solution. Establishing the KPIs and COS is an important
exercise for the long-term health of the initiative, as they provide a
means to track on-going progress of the engagement, and eventually the
success (or failure) of the solution. Hand-in-hand with establishing the
KPIs is the need to determine the baseline metrics for these KPIs,
which will help the teams understand where they were at the start of the
engagement and what they have achieved with the new solution.
Developing the project charter
The Sure Step
Proposal Generation activity summarizes the conclusions drawn from the
Decision Accelerator offerings and the preceding Diagnostic activities
into a project charter for the customer. The project charter includes
the high-level project scope, solution delivery approach, workflow,
timelines, activities, and dependencies. It also includes the roles that
will be involved in the solution delivery, both from the service
provider and customer teams, and their corresponding skills
requirements.
The proposal generation
activity begins with summarizing the high-level scope. For this, the
sales team will review the outputs of the Requirements and Process
Review Decision Accelerator offering and the Fit Gap and Solution
Blueprint DA offerings. Based on the requirements that were identified,
defined, and documented in these exercises, the project charter will
define the scope, including the business needs and functional
requirements for the new solution, and the to-be business processes.
The project charter will also
include non-functional requirements and any other technology
requirements such as integrations and interfaces to external systems.
Any performance needs such as system response, latency, system downtime,
and failover requirements, will also be noted in the proposal. For
this, the team will summarize the findings of the Architecture
Assessment DA offering.
The project charter should
also discuss the solution delivery approach that was ascertained in the
Scoping Assessment DA offering. This includes deciding whether we will
go ahead with multiple releases or one single release. It also involves
deciding on the suitable implementation approach for each of the
releases—waterfall or agile.
The project charter should be
accompanied by a high-level project plan. While the overall
implementation approach will be covered in the project charter, the
high-level timeline, activities, and dependencies for the solution
delivery will be noted in the project plan.
Another aspect covered in
the project charter is an assessment of the proposed roles and
responsibilities, and the project team skills and requirements. The
starting point for this assessment can be the output of the Scoping
Assessment DA offering. The project plan should then specify the next
level of detail, including denoting in which activity and when the
corresponding roles will be involved in the implementation. An overall
project governance model should also be defined in the project charter,
especially for longer engagements that involve multiple releases. The
governance model should clearly articulate the project management and
key roles for each of the releases. The model should also define the
structure to bubble up communications and issues at a program level,
such as the formation of a steering committee that will include key
business stakeholders from a cross-section of the customer organization
as well as key stakeholders from the delivery team.
The project charter
can also include project communication plans and schedules, including
the timing and information structure for project statuses, from
individual release resource teams through to the steering committee.
The assumptions, scope
delimitations, and risks identified for the engagement are key areas
that should be highlighted in the project charter. It is important to
list any assumptions that went into the definition of the solution,
along with the requirements that are clearly out of the scope of the
engagement, in order to avoid any misconceptions or misunderstandings.
The project charter should also note the identified risks and attempt to
identify and outline a mitigation strategy for each of them. Any
dependencies owned by the customer and outside of direct project control
should also be clearly highlighted.
The Proposal Generation
activity is typically performed in the Proof stage of the Microsoft
Solution Selling Process and traditionally follows Proof of Concept
and/or Business Case activities. The sales team looks to influence the
solution decision of the customer in this activity, and strives to
obtain verbal approval from the customer. Upon receiving a verbal
approval of their proposal, the sales team can proceed with the
development of a budgetary estimate and the creation of the Statement of Work (SoW).
Closing the sales cycle
The Sure Step Final
Licensing & Services Agreement activity builds on the Proposal
Generation activity to formalize the agreements between the customer and
the selling parties. The selling parties could be multiple entities or,
in some instances, one single entity. From a software licensing and
on-going software maintenance standpoint, it could include Microsoft,
Microsoft Partners, and Independent Software Vendors (ISVs) for add-on
solutions to the core Microsoft Dynamics solutions. Similarly, it could
also include multiple parties on the services delivery side, including
Microsoft-Certified Implementation Partners and Microsoft Consulting Services (MCS).
A typical first step in this
exercise is to provide the customer with a budgetary estimate for the
services delivery. The budgetary estimate essentially summarizes the
results of the Scoping Assessment Decision Accelerator offering, and
includes any rate discounts that may have been proposed between the
service provider and the customer. If the customer has been actively
involved throughout the Diagnostic phase activities, the budgetary
estimate should not come as a surprise to them. However, the service
provider can expect some level of dialog on rate discussions and
timeframes, which is the reason for providing the customer with an
estimate, as it facilitates open communications through negotiations
towards finalizing a formal agreement.
After a satisfactory
round of negotiations for both parties, the service provider initiates
the Statement of Work as the formal agreement to commence implementation
of the solution. The SOW builds off the project charter and project
plan documents initiated in the Proposal Generation activity. It is a
formal legal agreement for services that will need to be signed off by
the customer and the service provider, so it will include many of the
components of the project charter, including the project scope, any
requirements not in-scope, assumptions, risk factors, approach,
timeline, and resources. The SOW will also include legal terms and
conditions both from a services delivery and a payment schedule
perspective.
The Statement of Work itself
can take different approaches. The most common approach is the Time and
Material (T&M) format, where the customer is expected to render
their payments for all services and expenses generated during the course
of the solution implementation at agreed upon intervals. Project
managers from both parties are responsible for ensuring that the project
stays within scope and budget, with change order controls and processes
typically in place to manage deviations. The larger the scope and
length of the engagement, the more likely it is that the parties will
agree to the T&M format, which will allow for a lower risk profile,
especially for the service provider.
The following is a screenshot
from Sure Step of the contents of the Statement of Work for the
Standard project type. The SOW has been provided as a template for
organizations using Sure Step to customize to their specific needs,
including necessary legal references.
The other approach, which is
being seen more frequently in tighter economic times, is a Fixed Scope
engagement. In this approach, the customer and service provider agree to
a very strict definition of the requirements in scope up front, and the
service provider is then responsible for delivering all the
requirements for the agreed fee. This approach is typically more risky
for the service provider, especially in the larger engagements. The
scope of the engagement typically goes through some levels of
modifications during the course of the implementation. This typically
results in the service providers building a risk quotient into their fee
structure, to ensure that they are covered to an extent in mitigating
circumstances. It bears mention that Sure Step includes guidance and
templates to manage the inevitable scope modifications—this is covered
in the Proposal Management sections of the Project Management
discipline.
Besides the Statement of
Work, the other component that is provided to the customer is the
Software License and Maintenance agreements. As mentioned earlier, this
could be only for Microsoft Dynamics, or it could include any associated
ISV solutions.
The third component for a
business solution delivery is the hardware and infrastructure
requirements. These are typically addressed by the customer's
procurement group, based on the recommendations made from the
Architecture Assessment DA offering.
Initiating the delivery cycle
The final activity in the
Sure Step Diagnostic phase is the Project Mobilization activity, which
is the precursor to the start of the solution implementation. This is a
critical activity for the sales and consulting teams, especially in
instances where the resources involved in the sales cycle are different
from those who will deliver the solution.
The Project Mobilization
activity takes place after the customer has signed off the Statement of
Work. It ensures that there is a clear knowledge transfer of the
customer's requirements and the envisioned solution between the sales
resources and the delivery resources. In this activity, the services
delivery managers also lock-in the consulting resources who will execute
the implementation of the solution. If the resources need any
additional training before the start of the implementation, the managers
are responsible for making sure that the training is scheduled and
executed without affecting the start of the solution delivery.
Other usage scenarios for the decision accelerators
In the previous sections,
we discussed the positioning and usage of each of the Sure Step Decision
Accelerator offerings at length. Each of the offerings has been
designed to serve a specific purpose, and they build on each other to
help the customer envision their future solution. As noted before, the
DA offerings are each independent and optional, so only those that are
required for a customer engagement need to be used. That being said,
there are three critical DA offerings that should be executed in some
shape or form to ensure that the solution meets the vision and
requirements. The three DA offerings are the Fit Gap and Solution
Blueprint DA, Architecture Assessment DA, and Scoping Assessment DA.
The first DA,
Requirements and Process Review, is important only if the customer does
not have a full grasp of the requirements for the new solution or the
future processes with the new solution. However, these days many
customers start their business solution selection process with a Request
for Proposal (RFP). If the RFP encompasses a thorough composition of
the organization's requirements and future processes, the seller can
begin with the Fit Gap exercise to determine if the requirements fit
well with their solution. However, as noted earlier, even if a customer
already has an RFP in place, it is possible that another competitor or
vendor assisted the customer in developing the requirements. In that
case you may have to execute the Requirements and Process Review DA, at
least to an extent.
Determining the Degree of Fit of
the solution is of critical importance, as is determining the solution
blueprint, the future infrastructure, and the approach, timeline, and
costs to deliver the proposed solution. This is why the Fit Gap and
Solution Blueprint DA, Architecture Assessment DA, and Scoping
Assessment DA are deemed as critical DA offerings. If, after executing
these offerings, the customer is convinced that they have the right
solution to meet their needs, the sales team may be able to go straight
to the Final Licensing and Services Agreements activity and skip the
other DA offerings.
For
smaller deals, questions often arise from sellers about whether or not
the Sure Step Decision Accelerator offerings are still applicable.
Irrespective of whether the DA offerings are positioned as paid
offerings, they are still applicable because they reduce the risk factor
for a solution of this importance for the customer, as well as for the
service provider, who ensures that they have documented and accounted
for all the requirements in their proposal. It is important to remember
that the duration for each of the DA offerings is dictated by the
selling and customer teams. So, for smaller engagements, it still
behooves the service provider to at least utilize the templates provided
in Sure Step and go through the steps in an abridged manner if needed.
This will ensure that they are not making any erroneous assumptions, and
they are also clearly communicating to the customer their understanding
of the requirements and the vision of the solution. Going through this
process also reduces the risk of underestimating the deal, as during
this process the sales teams may unearth points that they may not have
considered. Therefore, at a very minimum, the sales teams should use the
Sure Step templates to document their assumptions and solution vision,
and make them known to the customer. Another option may be to combine
the three offerings and execute them as a series of steps, resulting in
the documentation noted above.
