Thursday, March 22, 2012

Solutions Engineering


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?

Most of this is Project Management 101; however, it’s very seldom implemented. Teams know that they should do it, but they choose not to, or the value of these artifacts is not stressed upon by the management. There is a lot of planning that needs to be done ahead of time for large solutions. This planning needs to be documented prior to system implementation. This does a few things, but one of the most important is that it creates the same expectation of the final product. This essentially defines