So what
is the difference between deploying a solution and a system? Sure, a system can
be a solution to something, but deploying a solution has an entirely different
scope of work. Deploying a system generally consists of having a few
engineering sessions, going onsite to install it, doing some configurations,
maybe migrating some data, training the customer and calling it done.
Deploying
a solution is an entirely different ballgame and requires a different mindset
from the client and the vendor standpoint. A solution will naturally have a
system deployment component, but ultimately there are a lot of other moving
pieces that contribute to program success.
Basically,
there are a lot of other tasks involved in solution deployment to give the
users a usable system that meets their needs. A prime example of this is
training. In a solution deployment, you would not train users on the system;
you would train them on the new business processing using the new system. Prior
to training on the new business process using the new system, these processes
would actually need to be re-defined, designed, developed, tested, deployed,
vetted through user acceptance testing, re-designed and re-deployed and
re-tested and re-vetted through users, etc… there is a lot of work involved.
Let’s go
through a few differences on common deliverables between deploying systems and
solutions. As a head up, I understand that all projects are different. It is
certainly possible that some items from solution column bleed over to the
system column. However, it’s important to acknowledge that when providing a
solution you need to provide ALL of the pieces that make it complete. In other
words, just because a system implementation has the project artifacts from the
solutions column does not guarantee success.
Deliverable
|
System
|
Solution
|
Technical
Architecture
|
·
Hardware/Software
Requirements
·
A few high
level architecture drawings
·
Hardware is
usually provided by the client
|
·
Hardware is
usually included in the initial design
·
Environmental
equipment such as load balancers, storage, networking, servers, KVM, UPSs are
included in the design
|
System
Documentation
|
·
System
Manuals
·
Technical
Support Number
·
CDs and
License Keys
|
·
Installation
Documentation
·
Configuration
Documentation
·
Operations,
Monitoring and Sustainment Plan
·
Test Plan
·
Migration
Plan
·
Cut-Over
Plan
·
Change
Management Plan
·
Security
Plan
Project Documentation include:
·
Risk
Management Plan
·
Training
Plan
·
Communications
Plan
·
Project
Plan
|
Configuration
|
Only
basic, essential configuration is implemented.
|
Specific
to the client’s requirements.
|
Testing
|
Ensures
the system and all components function as desired.
|
Tests the system under
specific configuration of the client, usually involves load/stress testing,
user acceptance testing, DR/HA testing, etc…
|
Change
Management (Operations)
|
n/a
|
Perform
change management to redefine existing business process to take advantage of
new technology.
|
Change
Management (IT)
|
Client
makes any changes they want to the system.
|
Formal process for
requesting, documenting, approving and implementing changes to the design.
|
Now that
you’ve examined the list, I would ask you to reflect on your past experience
with IT deployments and team members and ask yourself two questions:
1) Do you think some projects issues that you witnessed on previous projects could have been avoided by thinking in terms of a solution instead of a system?
2) Who on the team is most suited to writing all of this documentation?
1) Do you think some projects issues that you witnessed on previous projects could have been avoided by thinking in terms of a solution instead of a system?
2) Who on the team is most suited to writing all of this documentation?
No comments:
Post a Comment