This action might not be possible to undo. Are you sure you want to continue?
10 Best Practices for a Successful Customer Solution Engagement
10 Best Practices for a Successful Customer Solution Engagement
Executive Overview ........................................................................... 1 Introduction ....................................................................................... 2 1. The Sales Process: Product Sales Versus Solution Sales ............. 4 2. The Scope of the Project ............................................................... 7 3. Communication During the Delivery and the Handoff .................. 10 4. Time-and-Material Versus Fixed-Price Delivery ........................... 13 5. IT Maturity Level .......................................................................... 15 6. Security Maturity Level ................................................................ 18 Level 1 – Chaotic Security Level 2 – Basic Security Level 3 – Effective Security Level 4 – Optimized Security Level 5 – Adaptive/Dynamic Security Example Security Models 19 19 20 20 21 21
7. Pre-sales and Delivery Architecture ............................................. 23 8. The Role of Security Architecture ................................................ 35 9. The Pros and Cons of Using Partners ......................................... 39 10. Documentation and Customer Training for Products ................. 46 Conclusion ...................................................................................... 48 For More Information ....................................................................... 49
10 Best Practices for a Successful Customer Solution Engagement
The ability of a company to successfully manage and deliver an integrated solution is critical for becoming a true solutions provider. Ten key areas often are not handled correctly and lead to customer dissatisfaction during these type of engagements. These same areas often cause stress within the delivery team, creating a negative work environment. The 10 key areas are:
The sales process The project scope Communication during the sales process through the delivery handoff Deciding if a time-and-materials or fixed-price engagement is best Defining the customer's Information Technology (IT) maturity level Defining the customer's IT security maturity level The development of a pre-sales and final-delivery architecture Determining whether there is a need for a security architecture Deciding when and how to use partners Determining what documentation and training should be provided before final delivery
If each one of these 10 areas is addressed by your team, your company will be sought after to be a trusted advisor by your customers. Mastering these 10 areas will lead to a greater success rate in regard to the procedures, process, and communication process for your solution deliveries, increasing productivity and professionalism.
10 Best Practices for a Successful Customer Solution Engagement
This paper is based on information from Information Technology Infrastructure Library (ITIL), International Organization for Standardization (ISO), and other IT models and methodologies. This paper is also based on my 17+ years in the IT industry as a government employee working at large enterprises, a contractor (body shop) contracted into a large government IT integrator, and as a computer vendor employee working in sales and professional services performing delivery. Over my career, I have worked on many projects across the U.S., mostly for U.S. Government customers, and I have seen the same errors made repeatedly:
Confusion about tactical sales versus strategic sales Poor communication about the final deployed solution Scope creep Confusion about when to use a time-and-materials versus fixed-pricing engagement Regulatory or fiduciary requirements and security requirements not addressed or addressed late in the architecture design or deployment process
Current internal IT practices (that is, IT maturity level) not addressed during the development of the solution nor for the final state
Unclear transitions and unclear detail within and between the pre-sales and delivery architecture drawings
Transition into production not developed correctly Impact of partner utilization on the project not considered Lack of engagement management
10 Best Practices for a Successful Customer Solution Engagement
There are some differences between commercial and government IT work; however, I believe the points made in this paper apply to both environments. This paper is about the processes, how to maintain control of the delivery, and traps that are fallen into during the delivery of the solution. It is not about any given technical solution. First, the sales side is briefly talked about to point out issues that need to be considered during the sales cycle and what type of sales process is taking place. Then, the remainder of the paper is about what to do after the sale has taken place, how to survive the delivery and walk away with a successfully delivered solution, and what to do so the customer wants to bring you back for follow-on work. It is understood that a good solution, with a strong technical team to develop and deploy the solution, along with great management, is critical to success, and this is not discussed in this paper. This paper focuses only on the 10 items that are often missed. If they become part of the solution process, they can help set your team apart from the rest of the solutions companies and teams.
Product sales are more successful when tied to business needs. cheap JBOD. The commodity nature of the product makes it much easier to train people to fix or repair the product. For large organizations. and storage (NAS. can read a facts sheet and know what they are getting. these tactical sales are critical and should not be ignored. SAN. however. or provide support via email (in all cases the sales team has limited interaction). Currently. small iron. it should be pointed out that as competitors move into solution sales. big iron. provide support by phone. as a rule. less research. let’s look at the tactical sales process. As the need for internal code writers becomes less. Products can be sold with false expectations. Some things that make a product-only sale easier are: Product support usually is easy for the sales team because the product is under warranty. there will be fewer and fewer tactical product sales opportunities left. The Sales Process: Product Sales Versus Solution Sales This section discusses two types of sales strategies: tactical (product only) sales and strategic (solutions) sales. however. desktops. projects are more about product integration and customization than custom application writing. product-only sales have a lower risk (less time.10 Best Practices for a Successful Customer Solution Engagement 1. so less custom coding is needed. the focus should move more to external expertise to integrate off-the-shelf products. Technical support is performed by a non-sales technical team that will come on site. 4 . So the risk of false expectation is lower when selling only pricelisted commodity products. This means the budget has already been allocated or is being put together for the project by the project lead. First. and you sell a known commodity) in comparison to strategic sales. On the down side of product sales. As a rule. Product sales require some knowledge of customer direction. Another downside in product sales is that off-the-shelf products have gained more features. the real solution to meet those needs will be designed and built by someone else. or more expensive RAID devices). because others have figured out the solution and you are just selling products that are part of a solution that was already sold at the higher levels. to be successful. Product-only sales are usually sold lower in the company's organization. for example. however. customers. Sales then have moved down to the project leads and architects who decide what products are part of the solution. this means they no longer need a team of programmers to write custom code to meet their specific IT needs.
Here is a brief look at some of the considerations that should be taken into account when determining which partners to bring into the solution development and deployment process. their current areas of focus. will use external companies to get integration skill sets for the one-time integration of complex products to create integrated solutions. however. Often it takes investment of time and money to make these large sales successful. and if you do not win the sale. you need to spend time developing a solution that can meet their business needs. These types of sales require an intimate knowledge of the customer's business. Partners. As you determine what the customer problems are and build the relationships at the high levels required to sell a solution for your customer. you become the go-to guy and the trusted advisor for those for whom you have created the solution.10 Best Practices for a Successful Customer Solution Engagement Another trend is that IT departments are usually trying to cut costs and. Solution sales put more of your eggs in one basket. Often this type of sales requires partners to provide parts of the overall solution. bring their own set of risks to the project. 5 . If you lose. as well as time and expense in doing all the research and architecting to bring all the parts together to build the correct solution. which adds a bit of an unknown to the final product. much time and money is lost trying to win the business. which can be critical to a solution. so to speak. and then use internal IT staff for maintenance of the system. in doing so. There can be a lot of complexity trying to put all this together. Often. you lose big and can have long periods without new revenue. Research is required to map solutions to business needs. They usually involve some custom work. as long as you are successful with your delivery. Other things to consider should be: Are you talking at the right level? Have you looked at other ways to solve the problem? Do you have the real problem or are you working on a stated problem that is just a symptom versus the cure? The cycle of solution sales is longer than product-only sales. I would expect that IT departments will become much like power from the power company: just a service with all the technologies and people to run it owned by another company supplying the service. and their long-term goals. Long term. when you win. this process of architecting a complex solution should have a peer review process with architects from the delivery side of the organization. Solution sales are higher risk because of the following: They require longer sales time.
or delivering the wrong solution for the company's true needs. because they will not be in the trusted advisor role. the less work and risk there is for the customer's IT leads. security. IBM products. it is critical to understand where they fit in and what their skill focus is: Sun products. there are regulations and laws about separation of duty within the roles of defining problems.10 Best Practices for a Successful Customer Solution Engagement Obviously. There is a higher risk of failure and a higher cost for a company to "build it here" versus pay an integration specialist to deliver a solution with off-the-shelf products. defining solutions/products. identity solutions. so pick them wisely. and so on. HP products. Another key point of solution sales is that the more a sales teams creates solutions that work. biometrics. Government. Success here has great rewards.S. however. Government. Partners are often key to the success of solution deliveries and can make or break you. practitioner. It is critical to understand the current laws and rules to be sure that you do not break laws that could hinder you and your company's ability to sell a solution/product for that sales cycle or. will this change affect the partner relationship? Each area here must be looked at and thought about before bringing in partners. this can put the sales team back to selling tactical products. Government customer for some period. On the positive side. it is good to understand the unique features your and your partner's solution brings that your competitors’ solution can't bring. and being able to bid on the solution/product. Microsoft products.S. you must consider their level of talent—junior. In addition. the inability to smoothly transition the solution into production. which lowers cost and risk for the company. or the final delivery could be jeopardized and customer satisfaction will be negatively effected. because of the unknown agenda of the partner and their relationship with the customer. Even if all they supply are bodies for integration. Government customer or possibly any U. to that U. in some cases. which helps the company achieve its stated goals and then helps open the door for you as a vendor to be part of the inner circle as a trusted advisor. or the guru—and are they looking for long-term contracts. 6 . A trap needs to be avoided with solution sales in the U. If a solution sale fails. either because of the inability to deliver the sold solution. I know the following point was made earlier. I believe it needs to be addressed again.S. On top of understanding your company's product set.S. the risk gets higher when more partners are added to the solution. In the U. you also need to understand the partner's company's product set and strengths to be sure they are the right fit for the solution. or is their focus on short-term projects? Other complexities arise with partners such as: Have they worked with your company before and how have those experiences worked out? Has your company changed direction or expanded and now has a product or solution that overlaps part of the partner's portfolio? If so. The other side of that is a solid delivery of a solution.
the IT shop. This training is best if sold up front with the sale of the product/solution. this key training is left out in hopes of keeping cost down. 2. In both types of sales. the scope of what is being sold should be well defined and in put in writing. there could be multiple views of what was sold. For example. communicating scope. training of the customer's staff to support the products and/or the solution after delivery is important. If the IT shop that will support what was sold does not feel comfortable supporting the solution. 7 . Once the solution is delivered. Government. they might become a roadblock in the delivery of that solution. there always seems to be three different views of what was sold: What the sales team believes they sold What the customer believes they purchased What the delivery team believes they are on the hook to deliver I understand that within each of these groups. The Scope of the Project In this section. It is critical to understand and obey these rules. they will have supportability issues that will end with customer satisfaction issues. It is critical to pick the right partners When dealing with the U. the CIO. and the CEO all might have different views of what was sold to them.10 Best Practices for a Successful Customer Solution Engagement Most companies that target the U. As with any complex sale. Solution sales cycles are much longer and require lots of research. I will talk about defining scope. if they are not ready to handle the new technology. Often.S. During the sales process. Government. and the pitfalls of scope creep. so you and your company can continue to be successful within the U. understand the rules of engagement to prevent a scenario where you cannot bid on a given solution. The key points in this section are: Product-only sales happen at a lower level than solution sales and have less risk. Government are trained to understand these rules and have people assigned to assist if you have question about any of these laws. within the customer's company.S.S.
there are customer constraints that might not allow that to happen. 8 . This section stresses the need for communication between sales and delivery teams. Since the early days of the computer industry. the more possibility of success there is for the final delivery. If there is not a proper briefing between the sales team and the delivery team. what marketing states a product does and what the product really does often do not completely match. There could be other reasons why this could occur. a review by someone from the delivery side of the organization is critical. Negative messages by the delivery team will undermine the trusted advisor role that the sales team is trying to build with the customer. there could be frustration from the delivery team regarding why the sales team did not have a clue about what they should have sold. it is critical that all the key parties meet and go over the contract and ask questions to gain an understanding of the solution and what it will take to deliver that solution.10 Best Practices for a Successful Customer Solution Engagement Even though it might seem obvious to the sales team what was sold. Any mismatch of product information or misunderstanding of product functionality needs to be addressed early to keep from setting false expectation with the customer on what they will be getting at delivery of the solution. Any or all of these items could be pushing the sales team. however. and the delivery team should understand this before talking with the customer. it is critical to get the delivery team involved early. Even though a sales team might want to sell the best solution possible. and delivery) of friction that is a destructive power for all involved. For the sales team. A big error by the delivery team would be to vocalize this frustration to the customer. There are times that the sales team does not know who will be doing the delivery. Any issues about what was sold versus what is being delivered should be worked out between the sales team and the delivery team away from the customer. and delivery. This disconnect can cause the delivery team to deliver a different message to the customer about what they purchased than the message the sales team delivered. It is critical that the customer hears one voice and one message from the solution provider. It should also be pointed out that there are times that the sales team might need to sell what could be considered as a non-optimum product for a given solution. which sets up a triangle (sales. there might be a push to get the money to meet a deadline or to get the contract signed right now in order to get the win. All details of the contract need to be in writing and understood by all three groups: sales. Negative messages also set customer expectations that the final solution/product is not a quality product and should be complained about. This can happen either because the customer does not have the money for the better product or the skill set to maintain the better product. however. The key here is the earlier in the solution architecture process the delivery team can be engaged. customer. I have seen cases where the sales team is given marketing material that describes features of a product that do not match features described in the delivery team's installation documents. This disconnect will confuse the customer and can be an issue with supportability of the solution sold by the sales team. customer.
it is the sales team. Communication between the sales team. The sales team should be kept apprised of any additional work the customer would like and the delivery team should work with the sales team to try to sell it. the sales team. Funding for the delivery team should be worked out before any additional scope is promised. Scope creep can add cost and/or time to the delivery that is not part of the original scope of the contract. additional scope creep is the fault of the delivery team. The key point here is that scope creep can happen from any of the three groups involved with the solution: the customer. Scope creep is a common pitfall within a project. 9 . This behavior can confuse the customer into believing that the solution was not right and that scope creep is OK and that they should be able to add scope as well. the delivery team. and the customer is critical. These types of strategies need to be communicated well with the delivery team and the customer with well-defined parameters about what the additional scope is. Sometimes. it is not the customer who is responsible for scope creep. It is critical to keep the delivery team focused on what is in the scope of the contract. It can be painful when the sales team you are doing delivery for decides to give away additional scope on a project to meet a customer satisfaction issue. it should be clear where the funding for the additional labor and product will come from. Scope creep usually will cost money and time. Furthermore. Customers often want to get more accomplished with their dollar or get additional features turned on once they understand those features are available in the product. The key points in this section are: The sales team needs to have the scope of the project well defined and in writing. Any scope creep should be defined and how it will be paid for should be addressed before additional work begins. and it should happen only after good communication occurs among all parties and an agreement among all parties is reached. The delivery team might want to make the solution more robust of might feel the need to add features to the delivery and create scope creep within their work.10 Best Practices for a Successful Customer Solution Engagement The two key points here are that sales and delivery need to meet before delivery begins and if the delivery team has issues. and the delivery team. Sometimes. they need to quietly bring the issues back to the sales team and work together to resolve the issues.
and so on. the delivery team. cables. generally. as stated before. Communication During the Delivery and the Handoff Communication between teams and within teams can be the key to a successful delivery. salespeople are communicators and technical delivery people seem to be less communicative. how to configure software and hardware. The size and complexity of the project and the number and location of participants will determine the frequency and types of methods used for this communication process. communication and diplomacy are critical to success. there needs to be one voice and one message being delivered to the customer as much as possible. it is critical to have an open and honest communication process. however. As you add partners. the customer's advisors (in the U. Government space. in some cases. I recommend real-time communication during delivery as well as in advance. One of the many places where a lack of communication can hinder you is when the customer has not met physical or logical security requirements. You can also see there are lots of places where a lack of communication can start one party talking poorly about one group because they feel left out or do not understand what is going on. providing correct passwords. racks.S. and integration of products so technical and sales teams understand given products. From just a few parties to a large group of parties to deal with during the delivery process. Working through bugs in products can be a very complex problem and becomes more complex as more vendors are added to the product mix. however. you can see there are a lot of places where miscommunication can take place and cause problems.S. such as acquiring required room access.10 Best Practices for a Successful Customer Solution Engagement 3. Government tactic). There is often training for product lines. The more of a lead role you have in the solution. think MITRE). During troubleshooting and ultimately during the fixing of these bugs. another group that is responsible for seeing that you delivered what was in the contract (another U. Within the IT world. This document does not go into the different types of communication and when to use them. 10 . and lining up rack space. and floor space for the equipment. Lack of communication to make sure these critical things are ready can cost days to weeks of delay and cost you money for resources that are not able to work as expected. Lack of good communication is one of the biggest problems during delivery of a solution/product. and. the customer. it cannot be stated strongly enough that communication is critical to being successful when delivering solutions. the more responsibility you have to be the leader in this communication process. Communication skills are often missed as a critical skill when it comes to training team members for success. The complexity of the solution being delivered determines the amount of communication that needs to take place.
or another product will need to be selected and brought in to provide the missing feature. engineering might have a testing process that still needs to be followed before a given fix can be deemed supportable. proper expectation setting in this area is critical. however. the customer needs to be brought in to discuss the issue and what impact the changes will have on the delivered solution/product. Sometimes the easiest thing to do. the product will need to be enhanced to meet the architecture. Most customers understand this. Inevitably. Sometimes the sales team will end up in this role of being the one button to push. there often is some communication back to the product development team (that is. This needs to be understood by the delivery team and the customer and communicated correctly. The key here is that product bugs happen and expectation setting is critical to help all understand what is expected and can be accomplished. and a request to fix a bug needs to be sent in. it can be a very delicate issue to determine who should fix or enhance their product.10 Best Practices for a Successful Customer Solution Engagement For complex solutions. I should point out this is the rarest case and never seems to be the way it works. is to change the architecture in such a minor way that the only thing required is for the team to decide to make the change and move forward. engineering). If customer expectations are not set correctly. It is critical to get support from within the company to push the fix through to meet customer needs. these requests impact the delivery schedule and should be communicated to the customer. however. One issue that could arise if you are from the company that is working on the bug fix for a given product is that the customer often believes the delivery team should have some control over how fast the bug work is accomplished. things do not work as billed or a product has undocumented features that are not wanted. In almost all cases. The design will need to be changed to work around the product's deficiencies. This means they will push on the delivery team as the one button to get the bug fixed. the delivery and/or sales team will get frustrated being pushed for something they do not have control over. Sometimes. If the delivery team has the skills to help with the bug fix. The question often is. Often the sales and/or delivery teams need to define the priority of the problem to internal engineering teams. Sometimes a product does not integrate into a solution the way it was architected for one reason or another. and delivery timeline. "Whose product did not work the way it was expected?" This situation can be quite a fingerpointing contest. depending on how the contract was written. cost. this is truly the hardest situation. and costs to be contained. With more than one company's products in the mix. that can be a help to engineering. they still expect deadlines to be met. 11 . No matter whom the customer pushes to get the problem resolved. high quality to be maintained. Engineering teams are always limited on resources and need help in prioritization of resources.
These issues add to the stress of the deployment and put stress on the partner relationship. and working with the customer to be sure they are ready for the next phase can be critical to moving through the stop gates required for final delivery. or you might have them on a fringe of their market. and letting upper management work the issues in an expedient manor can be critical to a successful deployment. which is often directly related to how this process is accomplished. pilot. when you have more than one company's products in the mix. and production environment with formal methodologies for how they load. There are bugs in the software. The key message in this section is that when the integration process does not go as expected. A new architecture needs to be developed to meet integration or functionality needs. Good communication. Understanding the customer's process. 12 . Next. Finally. Some customers might run the solution as a pilot for some given time to be sure it has functionality and performance that meets the needs of the user base and then "go live" with it once some threshold is met. but they need to be enhanced to meet the solution needs. Later in this document. communicating where you are in the process. Other customers will build a small pilot for a few key/power users to test against. the more complex and political this problem can be with you having less control over the outcome. Some of the areas that can affect change are: The products do not have any bugs. it can be a very delicate and political problem.10 Best Practices for a Successful Customer Solution Engagement As pointed out earlier. The customer and the sale might not have the same importance to this vendor as it does to you and your company. test. using the customer to help push fixes. At some customer sites. configure. I talk about IT maturity. and once integration and functionality are met. Using the customer and upper management to guide and help drive the right changes is critical. and fixes need to be made or changes need to be made to overcome the bugs. it can be very hard to get another company to make an enhancement to their product for your solution. the deployment process can vary from customer to customer and understanding it while communicating your status is critical to a smooth final delivery. and test systems between each one of these environments. a "production ready" system is built and deployed. they might just turn the system on and go live with it. the more partners you have. They might not have the resources to fix the problem. so they do not see the issue as a critical or core market for them. The transition of the system to production can be an interesting event. Other customers use a very strict and formal development.
and the final solution. This delivery method has the most risk of scope creep. however. cost. deadlines can be easily missed. we will talk about time-and-material pricing versus fixed pricing. a TM engagement is best for customers who are doing things that are "new" or "untested" solutions and require a fair amount of development/integration of products. The sales team should know which to sell and why. In my experience. and schedule. often the changes are small. the architecture. if not followed. This apparent loss of control makes it easier for the sales team and delivery management to lose control over these types of engagements. how does a sales team say no? The customer will be upset if they are paying TM and the delivery team does not perform the task requested by the customer. much like building a house. These types of changes do not always require architecture changes. they do change the scope of the project and need to be communicated as such. As changes are made. What I mean by this is if a customer wants to make changes and they are paying the bill. Time-and-Material Versus Fixed-Price Delivery In this section. such as the content. One of the key methods for the sales and delivery management teams to maintain some control over this type of engagement is through good communication around the final solution. this can lead to dissatisfaction with the delivery of the solution. there is an architecture that. and feel on web pages. who is in control of scope creep. From my experience. can cause the final product to not work correctly. the architecture needs to be adjusted and the impact on expected cost and schedule need to be addressed with the customer. The delivery team needs to understand what behavior they should exhibit depending on which engagement type is used. the sales team and delivery team in many cases will still be blamed for these slips as well as for any failures in the solution. and if proper expectations are not set. When delivering an IT solution. First. 13 . Because of the customer's ability to drive scope creep. this can lead to more sales and therefore might seem like the right thing to do for your company. these engagements have the most risk of going beyond the sales team’s expectations. Oddly enough. and the flexibility of this option. If additional software or hardware is required for the changes. I will point out what I see as issues and benefits of both of these types of engagements. the risk for the final solution seems to be moved to the customer because of their control over scope. Often used for engagements that require custom code and do not have a line item in the price book. look. In a TM engagement. solution control. A TM engagement usually gives the sales team the least control over the final solution and the delivery resources.10 Best Practices for a Successful Customer Solution Engagement 4. I will cover "time and materials" (TM) and describe scope creep.
and the customer. the delivery team needs to have a good understanding of what solution is to be delivered and how it will be delivered. less margin can be made from the delivery because of the extra hours that drive up cost by the delivery team. there is a possibility of scope creep. Training can be an issue no matter what type of delivery is taking place. delivery entities (engagement managers. on-the-job training should be handled in such a way as to not jeopardize smooth deliveries. enables the delivery team to make a good profit from a well-priced line item. To maximize customer satisfaction and margin on these sales. delivery architects/engineers. because the solution has a price based on predefined parameters and on previous deliveries of that solution. the more likely the customer is to think that the solution is complex or hard to install. and usually product back-end support). delivery team. if the delivery team is slow and seems unsure of itself. The easiest fixed-price sale is the line-item sale. Success with this type of delivery method requires either a well-defined final product with a defined schedule and labor efforts (custom solution) or a line item from a price book that predefines things for you. Delivery teams need training to bring delivery people up to speed on new technology or to get a given technician experience on a given product or solution build. A fast and smooth delivery gets the customer up and running quickly. In contrast. which leads to less scope creep and a more satisfied customer. which requires good communication among the sales team. It should be obvious that this hurts both the sales-side and the customer-side when the delivery goes in this direction. 14 . As stated many times in this paper. From the sales side of a slow delivery. is very successful for the sales team. which might cause concern about the long-term maintainability of the system. good communication between all parties leads to a well-defined end state. However. I will talk about the fixed-price delivery method. Second. and the customer. fixed-price solutions do not give the customer much control over the delivery process because everything is in the contract and the contract is usually more rigid in nature. and it gives the customer a great deal of control over the final product. and makes the team look very professional. As in any project. Though this paper does not address how training should be accomplished. it can be both profitable to the sales/delivery company and cost effective to the customer. When this type of engagement is correctly managed. Generally. To protect against scope creep.10 Best Practices for a Successful Customer Solution Engagement This type of engagement should be a shared-risk engagement. Scope creep in a fixed-price solution is more apt to occur in a "one off" contract with poorly written boundaries on what will be delivered and how the solution will be delivered. when sold with well-defined expectations and a delivery team that knows what is in the line-item solution. A line-item solution. I feel it is critical to point out some problems that can occur when training is not handled correctly. delivery team. the speed and quality of the delivery team is key. which increases customer satisfaction with the end solution.
which can affect customer satisfaction possibly cause long-term customer relationship problems. Cutting training for delivery teams might add to margins in the short run and keep more technical people working. 15 . it is critical that continuous communication takes place between all parties and that scope creep be kept to a minimum. If it is not possible to have a well-trained person for a given delivery.10 Best Practices for a Successful Customer Solution Engagement Based on my experience. Finally. a possible way to offset the learning curve and help the customer with customer satisfaction might be to give some of the delivery person's time free to the customer as a way to offset the lack of experience. however. for both types of engagements. The key points of this section are: TM engagements work best for untried solutions and fixed pricing is best for repeatable solutions where all the parameters are known. it will erode the technical skills of the delivery team and in the long run cost customer satisfaction and the technician's job satisfaction. For either engagement method. This is especially true when things seem to be going slow or having issues. often training is accomplished on the job and sometimes without experienced technicians guiding the process. Even an understanding customer does not want to get the first delivery of a given solution by a given delivery person. higher availability. Well-trained and experienced delivery teams are critical to the success of an IT solution provider. Much like the old snake oil salesmen of the past. Good communication and setting proper expectations are critical to the success of either type of engagement. Sales teams will use this desire to help motivate the customer to buy the latest greatest technology to solve their problems. I think the vision of IT efficiency. it is often easy to believe that the next upgrade or capabilities will fix the chaos in the environment and things will get better. 5. In a less mature environment. It is critical to have a solid training program for technical staff for technical progression within an ever‑ evolving industry. completely updated and communicated project plan is key. they have the solution to all of the customer's ailments. or new capabilities are the focus of the sale process. a realistic. Often. A well-trained technical staff is critical to the success of the delivery team. IT Maturity Level IT maturity is critical to understanding what type of solution the customer is able to support and the probability of success in delivering a given solution to the customer. The assessment of an IT organization's maturity level as part of the sales and delivery process is often missed.
10 Best Practices for a Successful Customer Solution Engagement The truth is that they often do have the solution to the problem. the solution often cannot be used to its potential and is not a success.org/wiki/Capability_Maturity_Model_Integration) 16 . As with many things within the IT world. Since CMM is a common standard used in the industry for both software development and IT infrastructure. however. I believe people generally understood that there was a maturity level of IT organizations. and software development. IT infrastructure. it was not formally defined and named until Watts Humphrey published a book named Managing the Software Process in 1989. by not understanding the IT maturity level of the customer. Image 1 is included in this section for your reference.S. to name a few. we see how things work in one place and apply that to others. Government contract software development.wikipedia. Image 1: Capability Maturity Model (Source: http://en. however. IT security. These early models were mainly focused on software development and. on U. So the real question is what is IT maturity level and why should a sales team and the delivery team care about it? There are many evolutions of what some call an IT maturity level or an IT Capability Maturity Model (CMM). in particular. Various maturity models have been created for IT architecture.
which is why I say you can use whatever model works for you. In the Gartner model. the general idea of each phase/level is similar. and solutions that are not overly complex. 17 . however. How sales approaches an organization based on each of these phases can be different.10 Best Practices for a Successful Customer Solution Engagement Another example of an IT maturity model is the Gartner Networking Maturity Model. When referencing a given model to others. each phase/level is a bit different. define what you mean by a given level so everyone understands your assessment of the IT environment. Note that on the CMM model. I do not believe that the model you choose to use is as critical as the fact that you use a model. inventory documentation (consolidation efforts). Image 2: The Gartner Networking Maturity Model I like the Gartner model. which was published in 2005. and when they are used. a 1 is "Chaotic. If you look at Image 1 for CMM and Image 2 for the Networking Maturity Model. you communicate what the different phases/levels mean. however. a 1 is "Competent people and heroics" and in the Networking Maturity Model. a phase 1 "Chaotic" a sales approach could be to help the customer move up to the next maturity level with monitoring tools." So each model is a bit different.
Finally. if time is taken to help move a customer up the maturity level. site B will be the same. and these should be understood before a solution is sold to ensure the solution meets these requirements. so do not assume that if site A is maturity level 3. an IT shop is just trying to stay alive and business does not and could not use IT as a differentiator. business-focused. the sales and technical teams understand how to sell the correct technology and help guide customers to the next level so their IT departments can better support their business. Meeting security requirements is also discussed in the section 8. therefore. Sales will probably make more tactical type sales to the IT shop and work with the business side to help them make decisions that could help move their IT shop up the maturity model. The second message is that selling or driving technology that is above the maturity level of a given customer will lead to failure of that solution. At phase 5. even if the solution has the ability to do what it was sold to do. Even though it is quite apparent that at phase 1. the customer will view the sales team more as an advisor than just a vendor trying to make money." 18 . The key message here is that the IT maturity level should help drive the type of sales and relationships a vendor should have with the customer. Through understanding the IT maturity model. help move them up." The ability to help guide an organization from a lower phase to a higher one can endear you as a trusted advisor within the IT shop. business understands IT at such a level that it uses IT as a business differentiator and. From phase 3 through phase 5. there should be a much more complex. not all parts of a large organization/agency have the same IT maturity level. strategic sales methodology that should tie business needs directly to IT expenditures. "The Role of Security Architecture. There are many regulatory and fiduciary security requirements that might apply for any given organization. sales should be an advisor to the CEO/CIO to support and help drive the CEO's business objectives. it is important to help build business value around sales. 6. "Reactive. Security Maturity Level Most of the previous section applies also to this section: Don't sell above a customer's security maturity level. which supports the trusted advisor role higher up within the company.10 Best Practices for a Successful Customer Solution Engagement The hope of these types of sales is to help the organization move to phase 2. As a final thought. and be a trusted advisor. This is true because IT and business are much more tied together in a way that IT truly supports business and understands how they support the business. This coveted spot for a sales team can truly lead to a continued pipeline of sales from a given customer.
because it is close in format to the Gartner IT maturity model. help educate the business side of the house about the business value of security and what these changes bring to the organization. although such investments tend to be focused on specific projects or problems and often use point solutions that are not guided by an overall integrated vision and strategy. privacy. if any. standards. and create policies that map well to the business. or customers. Much like the IT maturity model. Level 2 – Basic Security At Level 2. If the organization is on the lower side (level 1 to 3 of the security model). some investment has been made in the area of IT security. as a rule. The organization is still exposed to substantial liability. This model seems to focus on the enterprise and not on just one aspect of the enterprise. Level 1 is reached when IT staff show up for work in the morning. auditors. processes. an organization can be moved up only one level at a time. IT security policies. Investment has been minimal and any organization IT security success thus far has been solely achieved through the efforts of heroes. 19 . although often they are not widely and consistently developed. part of your goal might be to help guide them to the next level by helping them set goals. written by Joel Weise of Sun Microsystems in a Technocrat article written in September of 2006. I like the following security model. communicated. implemented. Activities. and controls can be found. or compliance problems are discovered by IT users. When needed. the responsibility of meeting security requirements is on the team building the solution. and controls are beginning to be formalized in some fashion. Then. processes. At this level. The organization is reactive and often is relegated to fire fighting activities after security. Level 1 – Chaotic Security At Level 1. Core IT security policy. or managed. an organization's security capability is best characterized as immature or chaotic. which makes it easier to understand by all. create procedures. there has been little effort completed towards creating and sustaining a secure and compliant IT environment.10 Best Practices for a Successful Customer Solution Engagement When selling just a product. In addition to the regulatory and fiduciary requirements. but this effort is still in the very formative stages. there are also organizational-specific policies and procedures that should be addressed. are focused on the security needs of individual projects or elements within the IT infrastructure. It is critical to understand all of these and then to also understand how well an organization follows and enforces them (their security maturity level). The organization is exposed to substantial liability.
and control are derived. capability. and controls. people. policies. as well as a plan that will serve as a transformational roadmap to help the organization achieve its IT security and compliance goals. and configuration standards. Level 4 – Optimized Security At Level 4. privacy. and regulatory advantages for developing and maintaining a consistent IT security posture throughout their environment. and services. Such organizations have developed and applied (more systemically) product. There is a clear IT security and compliance vision and strategy from which projects. competitive. and compliance vision and strategy. and solutions for. Organizations will develop a security. predictable. where appropriate. Level 3 – Effective Security At Level 3. and technology. process. the IT security capabilities of the organization are measurable. processes. its IT security and compliance problems. There is a well-defined governance process for engaging IT security in the service development and information protection lifecycle. Greater levels of efficiency and optimization are achieved through automation and continuous refinement practices. and all security requirements have been addressed. as well as lessons learned.10 Best Practices for a Successful Customer Solution Engagement The level of IT security throughout the environment is still inconsistent due to the fact that most of the policies and processes are not defined and those that are defined might not be consistently implemented and audited. Failures. The realization is that ensuring the secure delivery of services and the protection of IT assets requires a holistic approach that addresses the environment systemically from the perspective of policy. IT security can be consistently measured and managed in accordance with well-defined metrics. policies. through the implementation of an integrated security architecture. Organizations at Level 3 are characterized by a more proactive approach to IT security with respect to infrastructure. Most organizations reach Level 2 without structured. The organization might have also started to streamline its IT security management practices through automation technologies for control and assessment. liability management is in equilibrium. processes. and service agreements. systemic efforts to address IT security and compliance problems. Reaching Level 3 requires that an organization have an epiphany regarding the nature of. applications. 20 . The security of the environment also strengthens as IT security processes become more repeatable and they are audited for compliance. are viewed as an opportunity to improve IT security and are consistently used in the development and refinement of policy. and repeatable. the organization has begun to realize the strategic.
all the while ensuring that a compliant IT security posture is maintained throughout service development and delivery lifecycles. NIST. and is focused on continuous process improvement adding quantifiable value to the business. IT security innovation. risk. therefore. With each security challenge or failure. the organization learns and grows safer. the IT security organization has moved beyond addressing liability issues and the implementation of an integrated and holistic security architecture. regulatory. The data available from the management and support infrastructures is used to modify processes in order to gain efficiencies. and the customer—understand it. Level 5 – Adaptive/Dynamic Security At Level 5. stronger. Adaptive security can be used to construct self-defending architectures that are not only resilient to attack but can also adapt in response to new security requirements or threats. This understanding is critical when sharing an assessment with other members of the team. accreditation. Adaptive architectures allow the organization to respond in a more agile manner to "just in time" business opportunities. and more compliant. certification. and so on). compliance has been achieved to all applicable legal. processes. Liability management is in equilibrium (that is. Common Criteria. compliant service delivery organization. Security.10 Best Practices for a Successful Customer Solution Engagement Reaching Level 4 generally occurs when the organization shifts from being an IT security operations organization to being a secure. and compliance decisions are now more grounded in facts rather than conjecture. innovation is now more readily possible. ISO 17799. and controls. 21 . I do not believe that the model used is as critical as using a model and making sure that all parties—sales. Example Security Models There are a number of security models out there and much like the IT maturity model. In addition. as necessary). leading organizations to more wisely and efficiently use and secure their IT assets. Traceability from the business metrics to the IT security metrics allows decisions and process improvement in one area to be based on information from another. often focuses on driving predictive and proactive change through adaptive and dynamic security architectures. FIPS 140-2. Here are a few outlines of industry-standard IT security maturity models that could be used. Furthermore. or both have been obtained for applicable standards and industry best practices (for example. ISO 27001. and other mandates. IT security at Level 5 is already leveraging automation and has been optimized for the business. delivery.
which has five levels of progressive maturity and is focused toward security engineering and software design: 1. Quantitatively controlled 5. Optimized SSE-CMM Model. If there is a mismatch between the delivered solution and the customer's capabilities. and complexity that customer can be expected to manage successfully. Repeatable but intuitive 3. Policy 2. however. Managed and measurable 5. Continuously improving You should not get too wrapped up in a detailed assessment of a customer against one of these models without an assessment contract being attached to the process. Initial/ad hoc 2. policies. If the solution sold has enough margin and the team believes that this activity would be critical to the final deliverable. then it could be accomplished as part of the sold solution. 22 . Performed informally 2. Well-defined 4. Integration COBIT Maturity Model. Procedure 3.10 Best Practices for a Successful Customer Solution Engagement NIST CSEAT IT Security Maturity Model. Implementation 4. It is best if some time and energy is taken early in the sales process. Defined process 4. which has five levels of progressive maturity and is focused toward levels of documentation: 1. Testing 5. then start early in the delivery process to evaluate the customer at a high. Planned and tracked 3. there will be a perception that the solution did not meet the needs of the customer. it is critical to understand the customer's security maturity level to understand what level of procedures. if that is not accomplished. Much like the IT maturity level. which has five levels of progressive maturity and is focused toward auditing procedures: 1. cursory level against an IT security maturity level to understand the customer's needs.
Understand that a solution with no security might be less complex than a solution with the addition of security controls. and provide the functionality required to meet the customer's business needs. simplicity is a friend of security and simplicity should be architected into all solutions when possible. Security might dictate that through removing some complexity. and how the solution process uses it. however.10 Best Practices for a Successful Customer Solution Engagement It easily can be argued that solution did not meet their needs. The first key point here is that understanding the security maturity level of a customer is critical at a high level to understand what type of security controls should be built into the solution. I start this section by quoting a section out of the NASCIO Enterprise Architecture Maturity Model (EAMM): 23 . a usable solution can be created. is a great win for both the customer and the vendor/integrator providing the solution. Finally. If a proper balance is met. and security is always a delicate one and should be addressed as early as possible in the engagement and architecture process. Pre-sales and Delivery Architecture This section addresses why an understanding of the entire enterprise architecture is critical. however. It should be obvious that this is not the desired end state when you want to become a trusted advisor for that customer. the security maturity level of the customer. so I will point out here that complexity is an enemy of security. delivered on time in a professional manor. configuration. so effort should be made to keep solutions as simple as possible to meet the needs of the customer. Complexity is also covered in the next section. The second point is that understanding the customer's security requirements is critical to building a solution that meets the needs of the customer. Often people seem to want to add complexity to an architecture to add functionality that adds minimal value to the end solution. it is important. The balance of functionality. additional security is gained through fewer points for errors to be made that could create security vulnerabilities. ease of use. 7. and maintenance. and the functionality needed to meet the customer's needs are brought together. When a correctly balanced understanding of the security needs of the customer. be usable by the customer. complexity creates more places to make errors in architecture. "Pre-sales and Delivery Architecture". The customer might also believe that the solution did not meet the stated ability of the solution. because they are not able to manage it. and they might feel dissatisfied with the final product if they are unable to maintain or support it. A solution that meets these requirements. what the lifecycle of an architecture is. the solution should meet the security needs of the customer.
Often each of these groups has its own diagram or understanding of the architecture. then the delivery team has the responsibility to manage the architecture's final state upon product delivery. used a large plotter to print the architecture. 24 . Without continuous monitoring of the driving business and technology factors. computer hardware. Just as individual product and compliance components contained in the Blueprint need to go through the cyclic process of Documentation. Review. and posted it on his wall. If the sales team has developed and sold an architecture for a given business problem. any Enterprise Architecture Blueprint can soon become obsolete. but they do not have a complete picture of the entire enterprise. change in the enterprise is happening even faster than in the past. application support. When selling products. and it is easier to accomplish with the greater adoption of virtualization in the enterprise. the high-level Enterprise Architecture Framework and procedures must be reviewed and updated to properly reflect environmental changes. each activity undertaken also has its own life-cycle. This work is getting easier as IT shops use more monitoring tools to map out their architecture to understand the enterprise and reduce costs. the team that has responsibility for the delivered solution has the main responsibility for this work. Today. the sales team has an obligation to play a key role in the architecture process. Often the IT shop is broken down into networking. OS. I have often started by mapping out the current architecture and the customer is so happy to see this work accomplished that I get extended to build the entire current architecture for them. and Vitality. Communication. In one case. and application development." Image 3: NASCIO Enterprise Architecture Maturity Model When selling solutions. the CIO took my drawing.10 Best Practices for a Successful Customer Solution Engagement "Whatever the current stage of the organization's enterprise architecture program. I have worked for many clients who do not have a single group or individual that has responsibility for the enterprise architecture. Compliance.
they can be addressed and worked out before work starts and resources get wasted waiting for issues to get resolved or starting to build a solution that has known issues. it is critical for the architect to define the build. the better the sales team can properly scope the true level of work required for the solution and its deployment. and power. The best situation is that both the sales and delivery teams have been talking during the solution peer review process. It is key to understand the enterprise architecture to understand how the solution that you are delivering fits in and how it may affect and integrate with other systems and devices within the enterprise. guide the delivery team to stay on target with the architecture. the sales architecture should be seen by the delivery team. It is obvious that the more the sales team understands and defines the architecture.. space. we will document it later. Let's take each one of the delivery team's architect's responsibilities with regard to the architecture and look at what function it provides. 25 . The key points here are that a handoff process needs to take place between the sales and delivery teams and that during the peer review of the solution. there are usually additional details that need to be defined by the delivery team for the delivery build team. so the handoff is more of a formality than a discovery process.. The level of detail and the flow of this information can make or break the success of a solutions delivery. During the handoff from the sales team to the delivery team. add detail for the build team. and make modifications if needed. If errors are found early. and they should be the focal point for build team questions. You might say this was already accomplished by the sales team. I have often heard "we need to get this. application integration. the engineering/architecture documents are handed over to the delivery team. This enables them to write a better contract with expectations that are more realistic and a better-defined statement of work. There are a couple of purposes for this event. On some occasions. One is so the delivery team's architect can see what the sales team has given the customer to know what is expected to be built and look for any delivery team known issues in the solution. the more this problem is prevalent. The lower the enterprises maturity level is. As mentioned earlier there are often issues between what the marketing team gives the sales team about functions and features and what the delivery team finds to be reality. IT maturity level. however. because new urgent projects or tasks come up that keep people busy. This flow might seem obvious. security. the more up-front work that takes place. Once the delivery team gets on site. Also. Areas that often need to be addressed in greater detail by the delivery architect are networks. it is often broken in one place or another in many "solution" engagements. The first is to get the sales team's engineering or architect documents and review them." I find that later often does not come. however. To some level. the delivery architect will have to deal with hardware sizing and storage configuration from some on-site storage pool. this is true. the more they can tailor the solution to the customer. The delivery architect is there to take the sales engineer/architect documents and verify them.10 Best Practices for a Successful Customer Solution Engagement This ever-evolving enterprise complicates the maintenance of enterprise drawings.accomplished now.
after all. often other questions come up. Often there are events that take place that require some modification to the final architecture. this is one area that is neglected by the sales team and is key to a successful delivery. The key here is that the entire environment that will interact with the solution needs to be understood. In most installations. and the people at those locations were not computer savvy at all. or (usually) the current infrastructure not being defined well enough for the solutions integration process. so our customer did not want to and could not force the end user to change to a URL versus the hard-coded IP address. browser. These satellite offices did not have any IT support because of their small office size. had to work with the network and delivery team to architect a solution for this group of users that would use the newly delivered solution's architecture.10 Best Practices for a Successful Customer Solution Engagement Let's start with the networks. authentication. user name/password. The planned solution required DNS names (URLs) as part of the system-access requirements because URL re-writes to a nonroutable IP address range was planned for security. where is it? Follow-on: What rules are currently between those systems and the delivered solution? As these questions get answered. It would have taken a lot of research and understanding of the customer's network for the sales team to know this information. I have seen situations where the end user used a hard-coded IP address in a URL instead of a DNS address to reach the resources needed by the end user. biometrics. and so on) will they need to follow to get to your solution? If there is integration with current infrastructure." Some key questions are: Where on the network is the solution to be installed? What are the firewall rules that have to be dealt with? Are there enough ports on the current switches/load balancers to meet the needs of the new hardware? Where on the network are the users that will be using the system? Follow-on: What rules (firewall. The good news was that the delivery architect figured this out early enough to solve the problem before the build team got too deep into the build. The key to this is realizing that the delivery architect's understanding of the infrastructure's network and how users will access systems can be critical to a successful delivery. This could be a product that did not integrate as it was first thought. the customer changing their requirements. I should also point out that these users were a customer of our customer. PKI. 26 . "The Network is the Computer. upon discovery of this problem. So the delivery architect.
if you will. the IT shop does not have the IT maturity to support this type of system and will fight with the delivery team to delay or kill the project. so they feel they are working with a skeleton crew. Imagine. the delivery team is on schedule. network trunking. Good work is often rewarded with more work. like most. If the project does get through delivery. The solution you want to install is a Service Oriented Architecture (SOA). As stated earlier. The IT shop manager is not letting anyone take training on this new technology and is expecting the delivery team to give a good enough handoff for the current IT shop team to manage the new solution. the latest version of an OS. This IT shop. It is not critical which IT maturity model you choose. and new SAN and storage technology. and need to manually look at log files to know what is going on within the infrastructure. this current network/enterprise drawing was hung in the office of chief of the IT department. has had budget cuts. I have often wondered why there is such a difference. This IT shop does not have system monitoring. the customer will have satisfaction issues that will come back to haunt the sales and delivery teams. because the customer is not ready to support a system of this complexity. Another example might be an IT shop that does not have drawings of their current systems and is not sure what their environment looks like from a hardware. It is interesting that during my career. new hardware the customer has not supported before. I have concluded that it can often be directly related to the IT maturity level of the solution and the IT maturity level of the IT shop taking on the care of the solution after it is built. it is critical that you choose one and use it to measure the customer's IT maturity level. and licensing point of view. SOA is not a way to help a shop that does not have a handle on their current IT environment manage their services better. Even though the system is robust and has many failover capabilities to help with availability (much needed in the current IT shop's environment). and it seems like you have to fight all the way to delivery with the customer's IT shop. software. It is a way to set up an IT shop for failure and for them to spend a lot of money and energy on a solution they are not ready to deal with. they build systems from bare metal with CDs/DVDs. the work taken to understand the customer network by the delivery architect led to more hours for the delivery architect to map out the entire network and build a drawing of it. load balancer for failover. clustering. This is a recipe for disaster. an IT shop that is at a maturity level of 1 (fire-fighting mode). It does not provide a way for them to deploy services faster. 27 .10 Best Practices for a Successful Customer Solution Engagement It should be pointed out that in the example above. I have been on installation teams where the architecture is solid. Then there are places where everything moves smoothly and the handoff is very easy. The system you are building is very complex with technology such as IPMP.
and dictate what is needed. test. if the IT shop deploys a system from a test/pilot system right into production. when push comes to shove to meet schedule. and design the solution to work within that maturity level. software. In either case. As stated in section 6. networks.10 Best Practices for a Successful Customer Solution Engagement Finally. I do not believe it is critical which security model you use. it is very likely that the architected solution will not be as successful as the architected solution should be. which also has a maturity level. there is a security disconnect for this customer. Even if they buy into this method of deployment. This situation is an indication that either the security policies and regulation are not in line with the business or security is not viewed as essential by customer's management team. it is critical to understand IT security. The first key here is that IT security maturity level is as critical as IT maturity level when architecting and delivering a solution. it is critical to use one. push the CSO around. and so on for a development. and production environment. I have seen situations where a good security architect came in and helped the CSO build and modify policies that met the customer's business needs. The key is that without knowing the IT maturity level of an IT shop. similar to the IT maturity model. The second key here is that working with the customer's CSO and business teams can lead to better-aligned security policies and procedures. When they do this. the large amount of hardware and software purchased will seem like overkill and this will become a sore spot between the vendor and the IT shop. It can happen only if the CSO and the delivery team have a positive working relationship. I have been at customer sites where I read the security policies that were written by the CSO. and it needs to be addressed. before developing a solution. If you do get the buy-in for the system. These changes became something that the business side accepted and the CSO was happy and able to enforce. you probably will not do well talking about hardware. and those policies were not implemented and were not enforced because they were deemed as things that get in the way of doing business. assess the customer's IT security level. Often the CSO is overworked and is very happy to have some help with this alignment process. they will fall back and just deploy without the formal test process. and they might deploy right on the development systems. and then from test into production. As talked about in section 6. This is not a situation where the delivery team can just come in. 28 . and described in the previous paragraph. The method for implementing and willingness to use solid security practices has a lot to do with the security maturity level of the customer's IT shop. and the customer will not feel comfortable with the final integration process. you then will find it very difficult to use strict controls for moving from development into test. there is more than one security IT maturity model that can be used.
I. Complete IT shop revamping is very rare and would most likely happen only with a corporate takeover and IT moving to another company's IT department or a major shake-up because of some catastrophic failure of the IT department. known building block (hardware. personally. When building an architecture. OS. combine multiple subcomponents that have different functions and build an overall solution architecture. however. and networks) to build the larger solution. This might seem obvious. There are also processes and procedures that must be taken into account during the information gathering process and the design process. however. software. in theory. it is often missed when designing a large architecture. Image 4: Building Blocks and Patterns for an Architecture 29 . Then. You can take a number of small subcomponents of an architecture and use a given process or procedure for combining them (building patterns) to create a single subcomponent of an architecture. it could happen. if there was a complete revamping of the IT shop. The following diagram represents this. it is often easier to start with the smallest repeatable part of the overall design and use this small. It would not be practical to design a system that requires regular human intervention in an environment that is lights-out. have never seen or been part of an event like that. I have never seen a customer move more than one level at a time. The key here is that knowing the IT and IT security maturity level is critical and can be raised only one level at a time with the right motivation and help.10 Best Practices for a Successful Customer Solution Engagement I want to stress this point again: A good relationship with a customer can lead to helping them move from one IT or IT security maturity level to the next.
The storage could be swapped out for a comparably performing SAN. The smallest part of this building block is the server and the software.000 users with 250 of them being concurrently on the system. There is no High Availability (HA) requirement. This is and example of when it is critical to build a pilot to work through these types of issues. This process of finding properly configured parts continues until you build out the solution. down time costs money and reduces customer satisfaction. we determine that the database will be about 500 Gbytes in size and will be used for a custom search tool. as always. Back to our example: Once you start to look around. This component is based on smaller building blocks that have a known set of patterns concerning how they are built. other solutions can be reused to create a new solution by going to these core. For most solution architectures. You could say that the smallest purchasable piece of a system is the CPU. we do not know whether it will integrate with all the other products. there usually are preconfigured servers that will meet your needs with minimal modifications. such as new hardware or software that has not been set up before or sized to the range required for the solution. a user directory. not custom-built systems. it becomes one of our building blocks. a second building block is found: a MySQL database with 8 CPUs at about 1. a database. As you dig to find out more about the environment. though. 30 . In most cases.5 GHz with 16 Gbytes of RAM will support LDAP running on Oracle Directory Server Enterprise Edition (formerly called Sun Java System Directory Server Enterprise) with Oracle Solaris for x86 platforms. With that being said. You also find out there are other web services that need to be integrated into the portal.10 Best Practices for a Successful Customer Solution Engagement An example of this might be a large portal solution that requires a portal. and then additional peripherals could be added as needed. desktop. there are tools that will help someone plug in requirements. If you were to change the storage to a NAS storage environment. With some additional research. at this point. or other device from the ground up. that could effect the network configuration of the server supporting the applications. In some cases. In today's world. so it can become our single building block even though there are a number of smaller building blocks within it. Then. we will assume that we are going to use preconfigured servers. Even though. you find that the solution needs to support 10. and the tools will spit out the correct hardware sizing. previously built parts.6 GHz with 32 Gbytes of RAM running on Oracle Solaris for x86 platforms is connected to a SAN made of Just a Bunch of Disks (JBOD) configured at RAID 5 using Solstice DiskSuite. I would say that a given server would be the smallest part of the solution. you find that a 4-core CPU at about 1. and some type of authentication mechanism. however. This could be true if you were going to build a server. You might ask what you do if there are unknowns.
This could be finding known integration issues or it could be looking for incompatibilities that might be detectable by reading technical product and configuration information. how data will be accessed and processed. storage. can calculate response times. If system utilization is known (for example. Finally. number of users that will use the system. Part of the delivery architect's job is to look at the hardware (servers. Other areas of responsibility for the delivery architect might seem natural and some might fall into the gray area overlapping the sales engineer/architect's job. unless these scaling thresholds are documented or you scale up until you hit them. calculate mean time between failures (MTBF). this is often not possible. software packages. If. This is a good way of sizing a system. of course. relies on a person's memory of a product and their estimates about performance. availability requirements. however. they are a very good starting point for an architect to use to get a feel for correct sizing. 31 . These tools do not take into account network latency or any latency that other systems that interact with your solution might add to the response times of your solution. solid building blocks have been selected with common open standards between products being used. therefore. This method often gets a customer close enough. however. and it is used more than many might think. and even figure out system availability numbers. and vendors that are part of the solution. There might be tools that.10 Best Practices for a Successful Customer Solution Engagement The last step in architecting this solution would be to look for integration issues. It is always best if a proof of concept can be built. during the architecture process. Other methods are to build a scaled down proof-of-concept and then stress test it to see how the system might scale. it is often possible to find automated tools to verify whether sizing is correct. On the downside. a proof of concept is best for confirmation of architectures and should be used when possible. with enough data entered into them. and the required response times of the system). virtualization. however. the best way to figure out whether sizing is correct on a complex system is to build the system and test it. Some of the pit falls of this method are applications that do not scale linearly and." This usually comes from an expert that has worked with this software before and has some concept of how the hardware and software scale. and network. the likelihood of success with the final product is good. the less automated tools can help in sizing accurately. This method. the more hardware. if applicable) and software to see if it has been sized correctly and if the architecture seems solid. using open standards that are common between components leads to a more modular architecture. Second. you could make incorrect sizing decisions. One of the not-so-scientific methods of sizing is what we call the "educated guesses. The first key here is to build each component using small groupings of products and procedures that are known. amount of data that will be stored. that is not always a luxury the customer is willing to pay for. In many cases. which might be inaccurate due to updated hardware or new versions of software.
and space that could be reduced if the solution was properly sized. Or. The issue is that this number is based on a peak utilization of system resources. Beyond the expense of buying more than was needed. So if you add up all the application requirements and put them into a server that is sized based on all the numbers. As stated earlier. cooling. 65% of the system is not being used. 32 . a correctly sized solution has a better chance of providing the best cost. I have pulled it out because it has its own set of issues. the person making the WAG will try to go large so that any errors they made are less obvious. and disk space. backplane bandwidth. there can be contention for resources. WAGs come from those who are not experts on the given solution. network resources. When a system is oversized and. it is best if the solution and its sizing information are reviewed in a peer review to help find any sizing errors. even with correct sizing for CPU. based on a 90% maximum server utilization level for optimal resource utilization. not every application will peak at the same time. it is much easier to figure out the correct size. so they guess at it. is only 25% utilized. Normally. the more accurately the solution can be architected to meet those needs. It might scare some people to know that this method is used a lot in the IT world.10 Best Practices for a Successful Customer Solution Engagement The least effective method. Finally. Following these rules leads to customer satisfaction and the view of you as a trusted advisor. outside of just throwing the solution together. the better the chance of a correctly sized solution. how many CPUs of this speed. and value to the customer. which creates user experience issues. they go the other way and under size the solution to sell it to management as not that costly. and so on. and disk space are not being overly utilized. having 90% or less utilization is more accepted than having a system that is 100% utilized and dropping packets (possibly sized 10% or more beyond optimal). so much RAM. or might not have knowledge about how to size the system. The better the system requirements are defined and the more science that goes into sizing the systems and software used. RAM. do not have time to use a scientific approach. the server will usually be oversized. RAM. performance. In a virtualized world. depending on the architecture and interaction of the applications. which take place even though CPU. Often there are tools for this that will look at the number of expected users and the amount of data that will be stored and spit out a sizing requirement. such as spinning disks (for read/write access). Another issue is that. and so much disk space. is the Wild Ass Guess (WAG). let's say. The keys are that the more information there is about the requirements for a given solution. Sometimes. When only one service/application will be loaded onto a single server. Though sizing a virtualized environment is similar to the process described in previous paragraphs. for example. the underutilized resource is using power.
remove them for that resource until optimal utilization is obtained. it is easier to add additional applications to the resource until proper utilization is achieved than to undersize and go through some procurement process to gain more hardware and space. worse. automated monitoring of the system. I address the fact that there are often events that require some modification to the final architecture. if you oversize the hardware. One is to size based on adding up the single server requirements. 33 . The other method. however. In this paragraph on architecture. and better resource utilization can save floor space. the customers of the services provided by the system will become the monitoring tool. it is critical to have solid. a WAG at the sizing of the system. then monitor the system to see how oversized it is. So virtualization could do more harm than good. With all the benefits of virtualization. Then. Second. The key is first that virtualization can make sizing harder. and cooling for the hardware. correctly sizing the resources for current utilization and future utilization is still key for proper IT cost versus performance. much like the IT sizing in the previous paragraph. The delivery architect has the responsibility to handle these events and work with the customer and the sales team to get an architecture that can be delivered and meet the needs of the customer. if it is overutilized. If the maturity level of the environment is low enough that there is not proper testing for sizing or good. I think this methodology is more of a lab mentality and is indicative of an enterprise with an IT maturity level of one. virtualization requires a higher level of IT maturity to gain the many benefits that virtualization offers. in a virtualized world. is that virtualized applications and systems can be moved from one resource to another with minimal effort. Since many services can be affected by one server in a virtualized world. when used correctly. There will be user stratification issues when users. With all the benefits that come from virtualization.10 Best Practices for a Successful Customer Solution Engagement There seems to be two primary methods for dealing with this. some resources will be moved until the customer's performance problems are reduced enough that calls get to a tolerable level. the system is looked at. and then add additional virtualized systems or. you might think it is the silver bullet for IT utilization problems and it is often marketed as such. The IT maturity level of a customer will help you decide whether this type of technology is correct for a given customer. power. customers can shoot themselves faster with virtualization by creating more fires that must be put out. the use of automated monitory tools is critical to proper utilization of resources in this environment. power. faster deployment of applications can be achieved. could be an educated guess or. if there are resource contentions. The beauty of virtualization. and cooling in a data center. With a low IT maturity level. instead of automated IT monitoring tools. automated monitoring tools and a good IT maturity level to handle the additional complexity. are used for monitoring performance. Once the customer starts complaining about the performance of the system. Finally. It might seem obvious.
and the sales team and helping to guide the customer to an architecture that will be deployable. Intrusion Detection Systems (IDS). either with other services or with the end user. So it is critical to keep them in the loop and include them in the change process during the delivery. If the delivery architect does not know the answer. that the final delivered product looks exactly like what the sales engineer/architect drew. and the current infrastructure not being defined well enough for the solutions to integrate correctly. Sometimes. many parts have to be considered when making changes. In large solutions. he needs to know who on the team or within the customer's organization understands the area well enough to get their input so he can make an informed decision before any changes are made. and the load balancer configuration. it could be a customer change in the form of scope creep. depending on how these systems were configured. meet the customer business needs. In the previous example. This change could affect firewalls. and help the sales team to continue to be a trusted advisor for this customer. The delivery architect is responsible for ensuring that any change will not alter things in such a way that the final solution does not function correctly or does not meet the needs of the customer. The change could be as small as going from HTTPS to HTTP on a given communication path to something much more grand. Any change might also affect the infrastructure that the solution has to be deployed into. the delivery teams need to remember once they leave. or it could be product issues that are undocumented features or incorrectly documented features. Finally. what I am saying is that often things seem to happen that change the architecture in some way before the final delivery. The other point is that the delivery architect is the focal point for all issues and changes that take place during the delivery process. It is very rare. The key is that the delivery architect needs to understand the solution. the infrastructure. 34 . I am not saying that the sales team did not do their job. and the architect is responsible for making sure that any changes that are made still integrate correctly. The delivery architect is responsible for gathering these changes by listening to the customer. the sales team will still be working with this customer and have the responsibility for the relationship between your company and the customer. customers changing their requirements. server performance.10 Best Practices for a Successful Customer Solution Engagement Some things that could cause a change are a product that did not integrate as first thought. changing HTTPS to HTTP on a given service could affect the infrastructure. and the user base well enough to make sure that all parts of the solution work correctly. in my experience. A change in the other direction from HTTP to HTTPS could have even a bigger negative effect on these systems. meet the schedule requirements. the delivery team. such as software and hardware changes that affect the entire solution. the cause of change is additional detail discovered about integration of the solution.
There is a need for integration into a corporation or organization's current security technology. 11MEDIS-DC. leading to security controls that were not needed or did not do the job or to security controls that needed to be added. IT and government industry standards. and policies along with the current technologies. and procedures that can be used by a solution or enterprise to meet them. A number of regulatory security requirements or standards might affect a given customer. SB-1386 (US CA). SEC Rule 240. but not by a security professional. you might understand the basics.S. ISO‑ 17799 & 13335. policies. security has become critical to keep a system's confidentiality. integrity. US HSPD-24. ISO 18501. Hong Kong Data Protection Act. GDPdU & GoBS. OSHA. Basel II. WEEE. EU Richtlinie. and corporate policies. PIC/S PH 1/97. With more and more critical corporate data being stored on computer systems. BS-7799-2. I address changes in IT that drive more focus on security. The belief that security is just a good practice to incorporate in the enterprise is changing to a realization that security is requirement. I have been part of many deployments where security was not addressed or it was addressed. The Role of Security Architecture In this section. HIPPA. I believe some people think that security is a network issue and will be handled at the perimeter by the network team. To this point.S. standards. policies. NASD 3010 & 3110. No company or organization wants to be the next news headline or "a CNN moment" about data loss due to poor security. US DCID 6/3. US DoD 5015. and availability (CIA) intact. A professional security architect is needed to understand all the regulations. however. it is best to have a trained professional to handle this quagmire of security regulations.10 Best Practices for a Successful Customer Solution Engagement 8. US privacy Act of 1974. and so on. With the evolution of laws in the U. Add to this the evolution of hackers evolving from some people just showing how smart they are to trying to get their name posted or in the news. 35 . HIPAA regulations. Patriot Act & Patriot Act II. EU GMP. the fact that simplicity is a friend of security.17. where within the solutions process security should start. GLB. Much like being your own lawyer. just a few that could effect a given customer might be Sarbanes-Oxley. health care facility needing to meet the U. and policies. it is becoming more and more of a legal issue if there are breaches in corporate data. The issue here is that security should be layered throughout the enterprise. I have never been on a project where the big security regulations don't get thought about like a U. GAO. standards. to organized crime using hacking as a business model. BS-179. and procedures for a solution's success. and why a security architect is critical in today's government-written mandatory regulations.S. and around the world in regard to IT security.
10 Best Practices for a Successful Customer Solution Engagement Any one or more of these could apply to a given solution. For example. there is a different degree of a surety needed in each case because there is a different level of risk if the message is tampered with or if the message is read by others. a decision about using signed PKI certificates by a company such as VeriSign or using an internally signed certificate authority has to be made.com on an auction item or a doctor sending an electronic prescription for drugs to a pharmacist versus a 911 call center sending out an alert to an emergency responder for an emergency. To meet the many security requirements of a given solution. If the solution decision was to use encryption from end to end (HTTPS). the level of CIA required could be different. since there might be customer-specific policies and procedures that also need to be addressed. some options might be encryption of the data in transit (end-to-end). there are often many different approaches. Will all parties within the environment be forced to verify the PKI certificate before accepting a connection. An example of a given requirement with multiple methods for solving the problem follows. however. The key here is there are a number of regulations that might affect a given solution. a segregated network. and they should be looked at by a security expert with expertise in the area/industry of the solution. depending on the customer (industry and location) and the customer's clients and partners. signed data. the receiver of the message would like to know who sent the information and that the data is what the sender sent. or some combination of these. For this given customer's solution. encryption of the data in transit (in sections). a bank that is moving $1M U. or could a user accept a bogus PKI certificate from a nonsigned source and get spoofed? Do you have control of this through control of the receiving systems. and/or enforceable policies? 36 .S. dollars based on Internet banking might have different requirements for CIA than eBay. which I address a bit later. and this becomes a list of requirements that a given solution might have to meet. there is a confidentiality and integrity requirement. If encryption is used and/or PKI authentication is used. In each case. end-user education. other parts of an architecture could be affected by this decision. Other issues that might need to be addressed are user name and password authentication versus PKI authentication. The key point here is that a solution should meet the level of risk needed by the business or organization. Each option used to meet the requirements has different risks and might affect the entire architecture in different ways. You then add to these imposed government regulations. There are many options for addressing this problem and depending on the industry. Back to my example: To meet the confidentiality and integrity of the connection.
it should be pointed out that complexity is an enemy of security. the more places people can make mistakes during configuration. their logs might contain critical data. The key here is that a security professional should be part of an architecture review and should be part of the engagement if possible. By breaking the encryption at the network device. The other key point here is that getting the right solution for the required amount of security can be complex. The more complex a system is. and the more likely someone is going to make a change during system support without understanding how that change will affect security. and there are always trade-offs that need to be considered. this can present its own set of challenges. So the VeriSign check of the server's PKI certificate before allowing encryption would be broken. for example. and policies of a given customer. and procedures around the solution to meet those needs. Other issues could be that URL re-writes could change the domain of the receiving connection and create a mismatch for the PKI certificate. some authentication applications that use PKI authentication will not accept the authentication. Other systems that might get affected are load balancers that cannot insert pro-cookies for session stickiness. the architect must understand how to add security technology. and this could be a place for possible compromise of confidential data. Beyond the logs. as well as understanding the security regulations. As you go through each option. For example. A complete understanding of the infrastructure is necessary to ensure the decisions made will meet the customer's requirements and fit into the infrastructure. there are effects to the overall solution that need to be addressed. network devices. end-user devices.10 Best Practices for a Successful Customer Solution Engagement Some considerations when making decisions about end-to-end encryption could be that Intrusion Detection Systems (IDS) or Intrusion Prevention System (IPS) cannot look at the content of packets. finally. if the network device gets hacked or the administrator of that device decides to do bad things. the end destination PKI certificate (the network device) will not be what is used by the original end point (the final server) to perform the encryption between systems. or other systems that are already part of the infrastructure. A security architect must understand all the technology that creates the solution. rules. Though there are times that adding security does ass an additional level of complexity to the solution. 37 . Each decision can affect aspects of integration that might not be part of your part of the delivered solution. Often security is thought of as adding complexity to the system. policies. When decryption takes place at network devices for IDS and IPS systems. If the choice is to do encryption but decrypt at one or more network devices to get load balancer pro-cookie insertion or to let IDS or IPS applications on network devices work. the data is easily gathered from those devices and this could break the confidentiality and integrity requirements of a given system. because the encryption certificate does not match the user authentication certificate.
The key here is that you have to understand an entire system. Since this organization uses zlogin from the global/root zone. Any virtualization product. they will meet any requirements. the only truly secure system is a broken system that is in a safe and buried in an unknown location. PKI SSO as a security control could be more secure than multiple user names and passwords and more user friendly. root access is required to use the zlogin commands. the partner that has applications on the hardware could possibly see the HR systems data. the administrator is looking to just clone the zone and move it.10 Best Practices for a Successful Customer Solution Engagement This same concept is true with firewall rules. All the HR systems currently run on their own hardware systems. change data from the global/root zone. people try to completely secure a system because they that believe by doing this. and other controls on a system where one rule changing could negate or affect all rules that follow the changed rule. Security is not about perfect security. it is about good-enough security to meet the needs of the solution. they now have access to your corporate data. Access Control List (ACL) rule sets. Worse. Security is viewed in even a better light by the customer when it can be used to make usability a bit better. or delete data through a simple mistyped command. An example of this could be using PKI authentication for a Single Sign-On (SSO) solution for the elimination of multiple user name and passwords. and one of the administrators decides to move an HR system onto one of the systems that supports their partner's applications. Virtualization adds complexity even though it can add functionality and the ability to utilize resources in a much more efficient manor. Often. Because the hardware architecture is the same and the OS level is the same. The customer has decided on Solaris 10 zones for virtualization. has its own added complexity that needs to be looked at from a holistic view when assessing security and complexity. This partner does their own administration of the applications on the hardware supporting their applications. the more chance there is for errors that could cause a security vulnerability. be it commercial product such as VMware Infrastructure 3. and zlogin commands can be run directly into another zone from the global/root zone. In this scenario. there are a number of servers being used with an enterprise-level web-based solution and multiple departments within the organization with different applications that all work within the web environment. an open source product such as Oracle VM VirtualBox (formerly called Sun VirtualBox). First. if they have an administrator who wants to do damage because of some problem they have with their employer. An example of this could be a large solution that is using virtualization as one of the key methods of running multiple applications with different functions on the same hardware. 38 . and the more complex the system. or an OS-specific component such as Oracle Solaris Zones.
or a company. I have been amazed at the number of delivery engagements that have a very strong security need and do not have any security specialist (security architect) assigned to them. the CSO can become an insurmountable roadblock keeping the solution from being built as architected. peer reviewed by a security expert to be sure enough security is incorporated in the solution. it is always amazing that if you have buy-in from the Chief Security Officer (CSO) on the proposed solution and the deployment method used for that solution. Government. the architecture should be. review their policies. business needs often win out over security. at a minimum. In the commercial world.S. educate them on the solution. either by not hitting the mark or by being overkill. In this last part of the discussion on security architecture. and work with them to make sure they support your solution. with all the security regulatory requirements on a solution. does not like the solution. I talk about the importance of looking at the internal security policies and procedures. if a CSO feels left out. it is viewed as a detriment or at best an evil necessity. Government. On the other hand within the U. The first key point here is that there is no such thing as perfect security.10 Best Practices for a Successful Customer Solution Engagement Security used as a competitive advantage is also a good way to get the customer to be motivated towards security. I use some companies as examples of places where partnering works and briefly point out why I believe partnering works. This situation often means that the security implemented in the solution does not meet the requirement. stopping the delivery all together. though. however. The Pros and Cons of Using Partners In this section. security seems to be a thing that needs to be accomplished because of some regulation or policy. I talk about the pros and cons of using partners and things to look for and watch out for when selecting partners. procedures. they do not seem to have the roadblocking power they have in the U. CSOs can be a help. it is a win-win situation. The key here is find out who the CSO or similarly roled person is. Second. This practice always leaves the sales and delivery team to try to define the security requirements and implement what they view as good security to meet the needs of the solution. Government. 39 . Finally. or delaying the planned schedule. As a rule.S.S. in my experience. When looking at security for a given solution. I would say the most often missed aspect is internal security policies written by an organization. Tracking these down and making sure that the solution complies with these policies. agency. how much the CSO will move obstacles to help you achieve a successful delivery. if security can be used to make the end-user experience better. 9. In the commercial world. Within the U. or does not like the deployment method. and regulations can be critical to the success of your solution's deployment. listen to their concerns. and if it costs more.
and the installation and integration for a solution. 40 . you control it all. So they have the most to gain from this type of engagement. they produce only solutions.S. and a company must evaluate its strategy and select the best direction based on the delivery strategy. then they have the potential to make the most money and have the most control over the customer. other IT integrators might not want to partner with a do-it-all IT vendor. The rest of this section talks about some critical differences between some of these options and the pros and cons that should be thought about when making partnering decisions. software. For any large IT solution provider. now or later down the road. because they can be in direct competition for the same business. they produce multi-vendor integrated solutions. A company like IBM wants to own as much of the contract as they can get. This means that in some cases during the bidding on a contract IBM could be in direct competition with an IT integrator that would like to use IBM to sub on its proposal for a given contract. they take the prime role in a U. since they might try to take the contract themselves. drive their hardware. One of the downsides of this type of business model is that other IT integrators might be concerned when creating a partnership with IBM. The intent is to show there are many market strategies for delivering products and solutions that can be used. One of the best known. however. the question is not. IBM has proven that this has a profitable strategy for doing business. They produce hardware and software.10 Best Practices for a Successful Customer Solution Engagement Most large IT delivery organizations. Second. either vendors or IT integrators. use partners for some part of their delivery strategy. The key here is if you own it all. if to partner. or they take a subcontractor role to another solution provider. a company like IBM might deliver an integrated solution of their products. A company must decide which of the following it is going to do: Deliver only its own products Deliver integrated solutions with other vendor products Be only an integration organization and produce no vendor-type products Try to be the prime contract for large integration projects Only subcontract on large integration projects Work in a small section of the IT industry and specialize in just that area Have no large-scale solutions delivery ability It is not the intent of this paper to address each one of these options with their pros and cons. it might not be a best-of-breed solution. it is when to partner and how much to partner. What I mean by this is if they can get the contract. Government solutions contract. do-it-all IT delivery companies would have to be IBM. Lastly.
because they view the Microsoft OS as the industry standard. a company like IBM might try to push or lock the customer into their products. Their model was to find best-of-breed vendor products. hardware or software packages). The hardware produced by Dell is based on products that any IT hardware vendor can buy or build. EDS was one of the pure IT integrators. As a rule. In most cases. This might not be the case. so it might not always want to use best-of-breed products in solutions either. In some cases.10 Best Practices for a Successful Customer Solution Engagement Before HP purchased EDS. they might develop solutions around what they are comfortable with instead of around best-of-breed products. Another reason an IT integrator might not truly use best-of-breed products is because they want to use what they know or what they feel they can integrate fastest to get a solution out the door. these type of companies produce products in large quantity and as cheaply as possible. Companies like EDS also profit from being able to place their technical staff into long-term contracts within their customer's IT environment. and then sell that solution. or they might select only products that fit mainstream IT direction. This means the key to their success is building it cheaper than the next guy. Third. this model is viewed by the customer as a way to get best-of-breed products because the integrator does not produce an IT product (for example. This business model is about beating the competition with cost and volume. delivery management. they often make money from placing people into long-term contracts in other company's IT shops. Second. they wanted to prime a contract around those solutions. So they would pick products around that OS when a better best-of-breed product might run on another OS. and delivering faster and easier for the customer than the other hardware vendors. a company such as EDS writes software that is part of an integration of other Commercial Off-The-Shelf (COTS) products for a given solution or performs some unique function that cannot be met by buying COTS products. the people. 41 . They controlled the sale. On the other hand. the contract. First. there are companies that are primarily a production company such as Dell. cutting overhead. The key here is that pure IT integrators want to control the contract. Dell produces commodity products that are sold as their main source of revenue. Often. There are three types of companies that are hardware/software producing companies. so the integrator should be an unbiased solution provider. they can bring best-of-breed solutions and can be a great partner for vendors to deliver solutions with. Then they brought in partners in for technical support when they did not have the skills or manpower for any given delivery. and some portion of the technical delivery team. they might work with vendors they are comfortable with or with products they have a skill set to deliver. and that is a value-add to a given market segment. such as Linux or UNIX. An example of this would be to select a product because it runs on Microsoft Windows. and the final solution. create a solution. though they are perceived as delivering best-of-breed solutions. Finally.
HP. not from IT integration and solution development. because there is no risk of them competing for their contracts. Often a company might start as a pure vendor or pure IT integrator and then want to become more of a do-it-all company. To continue to be a disruptive technology company requires a large R&D department to be successful. much as Microsoft does with their OS and software product sets. This type of company must figure out where the industry is going and either build a solution first to meet the ever-changing direction of IT or build it better than the early trailblazers for a given technology.10 Best Practices for a Successful Customer Solution Engagement Second are companies that produce a product that is unique and proprietary using the product to lock customers into their product set. as well as from a single-focused to multi-focused company. who need to partner with companies such as Dell. Many companies that produced great technology no longer exist because they did not transition well. commodity producing and unique COTS producing companies have some form of delivery staff that deploy to a customer location for a product installation or to assist in a solution delivery. I point this out only to say that building best-of-breed products or using bleeding edge technologies might not be the best partnering decision. this is not their primary business model. This model requires continuous development of products that will keep customers loyal and dependent on their proprietary products. Sun Microsystems. Many good books discuss the issues around growing from a garage shop to a multi-billion dollar global company. These transitions can be hard both internally for the company trying to create a new identity and externally from a marketing and customer-messaging point of view. and it requires a large Research and Development (R&D) department. Companies such Intel and AMD come to mind. however. from a partner perspective. The final group in this class is those that use innovation as their model of doing business. Companies that only do integration might like to partner with these types of companies. The key points are that COTS-only producing companies make most of their money from the COTS products they produce. As a rule. such as Sun Microsystems. Finally. This paper does not address this issue other than to say that there are growing pains during each evolution a company takes. This business model is considered disruptive. they might take a solutions-type delivery contract. It seems obvious that a company that only produces a widget will need to build partnerships. These types of companies do not market themselves as solution companies or integrators that take prime position on major contracts requiring integration of multiple vendor products. 42 . and IBM to produce computers with their CPUs. IT integrators have less risk when they partner with COTS-only companies. If they have a COTS solution from their company. The whole company and their products must be looked at before making a decision to partner.
they will keep you at a distance. and the contract of a given solution. because your customer is the prime on the contract and their customer is also your customer by default. There are a number of ways to accomplish account control. Second. It is not about whether to partner or not to partner. By owning the solution. Earlier. This would be yet another handicap when it comes to driving your products into the customer site when. If the customer views you as having agenda that is not in line with their business needs. people. or an IT body shop to get technical skills for a given solution that their company does not have readily available. One might wonder how this is different from other vendors going to the customer. The first key is to own the solution contract. you need to keep them happy. you have more control. so the integrator can maintain control. By owning the customer contract. First. Dell. your technology. since your products. companies such as EDS that deliver IT solutions often partner with companies such as Sun Microsystems.10 Best Practices for a Successful Customer Solution Engagement On the other side. the customer that gets the final solution needs to be satisfied with the final solution. The key message here is by owning the contract you own the solution and the primary customer relationship. however. however. you control what products will be used and what the architecture is for the solution. so they now have two places to go to remove you from the contract. Customer account control comes from you being a trusted advisor to the customer. you own the solution architecture and you own who will be on the project. I should point out that they still can go to the customer and they can go to the prime of the contract. or your technical delivery staff is being used. I stated that by owning more of the hardware. it is about whom to partner with and how much of your business you will use partners for. as a sub your company could be used as the fall guy for why there are issues. software. as a vendor. if for any reason the solution goes bad. Fourth and finally. you are in the sub role with limited access to the customer. other vendors can still push their products to the prime on the contract. you might feel a great victory in being a sub on a contract in which your product is key. it puts your company in a much more delicate position to try to keep both parties happy. It should seem obvious that you then are removed from the contract or your role is reduced. if the prime contractor is successful and maintains account control. Also. Keeping both of these parties happy can be a delicate balancing act. Third. I discuss those that are part of solutions delivery and those that I have personally been part of that seem to have a successful strategy. As a vendor. Vendors who sub to an IT integrator might have clauses in the contract that deny them direct access to the customer to pitch their products. 43 . there can be long-term issues with this. in this section. Microsoft. in the end. The contract holding company might have a different agenda than your company. and you have control over the customer experience through the development and delivery process. there is no guarantee that your company will still have products and people that will be used for any additional follow-on work. and with them being your customer.
the role of a customer trusted advisor can even have more power in the long-term success of an engagement. is the solution team Technical Lead/Architect. assigning responsibilities. and technical Team Leads/Architects. How a delivery team works and how the customer on a contract is managed is the responsibility of the delivery management team. Technical Lead/Architects often are able to be a key insider for the sales team. Delivery Manager. Often these technical leads are the trusted advisors to both the delivery team and the customer. First. tracking hours worked.10 Best Practices for a Successful Customer Solution Engagement The second key is to own the management of the contract. Often. This team can consist of a Project Manager. for large solutions. The key here is that by owning the management and technical leads for a given solution. and usually they have more access with the customer's technical people. They can be brought in to help manage a large complex IT or service project. the Delivery Manager will be at the customer site on a daily basis tracking and guiding the final delivery. They often have revenue targets and need to keep projects profitable. Their role includes maintaining the overall schedule. who might have the inside scoop on other projects or issues within the customer's IT environment. which should manage the continued development of the solution after getting the handoff from the sales technical team. 44 . It should seem obvious that the delivery team would view the Technical Lead/Architect as a trusted advisor because of their senior role. reporting issues to both back-end internal resources and customer management to keep the project moving. Second. however. Project Managers often have multiple projects they work on and spend limited time directly involved on any given single project or customer. you own and control the architecture and how the customer is managed. the Project Manager often has responsibilities for pre-sales consulting for expected customer projects and services. This relationship can be critical to the success of an engagement. The customer often is not threatened by the technical guy and will share issues and problems in a much more candid manor than with managers or sales staff. the Delivery Manager often has the responsibility for the day-to-day activities of a project and is usually at customer sites on medium-to-large engagements. Their role on current projects is to be sure they stay on time and within budget. Third. They often have a dual role of identification and evaluation of opportunities for future customer opportunities and ensuring delivery of current projects. The Technical Lead/Architect should be looked at as the focal point for all technical issues from both the delivery technical team and the customer's technical team.
When they are a member of the prime contractor's team and they have a senior position. I will talk about the technical people who are doing the configurations and writing code to make the delivery a success. The Technical Lead/Architect is a key in any large solution delivery. this person management goes to about those issues. and it is even more pronounced when the Technical Team Lead/Architect is also a subcontractor. Because of their role of continued technical discovery of requirements. If a subcontractor company is used and it has technicians. and reporting how things are going. They key message here is that the Technical Lead/Architect should be from the prime contractor's company. 45 . which can be critical for troubleshooting issues during delivery. so what problem is there in subcontracting this out? If this role were limited to these administrative functions. I will talk a bit about why the Delivery Manager role should not be subcontracted out. they usually have relationships with internal back-end technical support staff. As mentioned before. or products. solutions. This group of people. This is a handy cap for the delivery team when problems come up.10 Best Practices for a Successful Customer Solution Engagement In this paragraph. With this role holding the keys to the architecture. as long as they are qualified technicians. which could include talking bad about your company to solidify its company for possible follow-on direct contracts with the customer. They key here is that the Delivery Manager should be from the prime contractor's company for account control. keeping workers on track. At first glance. it has an obligation to do what it can for the company. Lastly. The Delivery Manager often is in customer management meetings. then it would not be a major issue. The other issue with this role being part of a subcontractor is that the information from holding the trusted advisor role might not be pushed back to the prime contractor as a way to promote follow-on contracts and maintain good account control. they also play a key trusted advisor role within the customer and a technical bridge between the customer and the technical delivery team. does not have as large an impact on account control. This role is about schedule. integration requirements. and if problems start developing. it is critical that they have a solid understanding of the products and solutions sold by the prime contractor. as a rule. they are a key leader of the delivery team. and troubleshooting. The other obvious issue is that they usually will not have the prime contractor's back-end support relationships to reach back and get internal support for issues that come up. they could drive technology or alternate solutions that are not in the best interest of the prime contractor. this person also is the management face of the delivery team to the customer. however. you might wonder what issue could come from this. When this role is owned by a subcontractor and the delivery does not go as planned.
Documentation and Customer Training for Products One of the areas I have seen the most misunderstanding over is how much documentation and training accompanies a given solution. A company has a balancing act with delivery people to keep the amount of nonbillable time (training and sitting the bench) and billable time at the right percentage to keep profits up. The key message here is that technical people doing the work are the easiest to contract out. the perception by the customer could be that if prime contractor internal technicians were used. Always understand your role within any given contract and do your best for your customer and. if applicable. from my experience. there are pitfalls that need to be managed for a smooth and successful engagement. and keep valued resources on the payroll. 46 . As a rule the more of the work force that you own. Good documentation shows professionalism from the delivery team and makes it much easier for sustaining IT support teams to maintain the solution. the more account control you can maintain. and internal politics all play into a company's IT delivery strategy. My final advice on this topic is to understand your company's model of doing business. they expect the vendor/integrator to provide top technical talent and not bring in lower-cost talent they could have contracted directly. Lack of manpower. The strategy determines which roles subcontractor must be used for in spite of the risk for loss of account control and negative impact on the customer's experience. 10. then create contracts and relationships around that model. is in two places: The first one is when the prime contractor has a high bill rate (per hour rate) that is used for pricing in the contract and the subcontractor has a much lower bill rate. their customer. the main point of contention. fast growth. if addressed early and communicated correctly. A well-documented solution is usually much appreciated by the receiving customer's IT shop. the engagement would move more smoothly. It is critical that all subcontractors are labeled and work as if they are part of the prime contractor's company. Both of these issues.10 Best Practices for a Successful Customer Solution Engagement When subcontractors are brought in. keep technical skills up. If a customer is willing to pay the high price for a given solution provider's technicians. however. The second issue is that if things start to go bad during the delivery. Poor or little documentation is often viewed as a poorly delivered system. can be minimized.
A customer that has a maturity level of one might feel they are fighting fires and do not have time to send IT staff out for training. Edelbrock EFI manifolds. it is very critical to have well-documented systems. An IT shop that has an IT maturity level of 5. Some IT technicians like the thought of figuring out any system on their own. the more customized the documentation should be. some training should take place so the support staff can maintain the technology or solution. They might feel the delivery team should train their IT team during transition.10 Best Practices for a Successful Customer Solution Engagement With the complexity of today's technology and solutions. So point one is to know what type of IT maturity level the IT shop has. Either way. will normally already have considered this as part of their business cost for the delivered solution. There can be occasions where the IT staff could be supplemented with a new-hire that already has the technical knowledge to support the new technology or solution. There is more to documentation than just referencing other documentation. The maturity level of the IT shop will often give some indication of the customer's probability of putting resources into this effort. and the contract determine the level of custom documentation that the delivery team will be responsible for. The more customized and complex the system. most still prefer good documentation. Point two is to know whether training is going to come from some formal vendor/solution company training or whether the delivery team is responsible for providing this training during handoff of the solution. The key point here is that good customized documentation shows professionalism from the delivery team and aids in customer satisfaction. I do not believe that most people would want to take apart a car engine or transmission without a very good technical manual that explains how it comes apart. Finally. however. and Wiseco pistons to get the documentation needed to repair your car's engine. goes back together. It feels more personal if the documentation is customized for the customer's given solution on a CD than if generic documentation is posted on the Internet. Any time new technologies or solutions are introduced into an IT environment. Ford engine blocks. there is a need to upgrade the IT staff with skills to meet the needs of the new technology or solution. A system that is a line-item type solution and has been delivered many times should have a good repository of documentation from other installations that can be customized with minor changes for a given customer. I believe most customers would prefer to have documentation handed to them on a CD than get a link to some web site. what the specifications of each part are. and any special tools required during the process. the number of products. It would also be unfair to ask someone to look up the manual on Delphi Electronic Fuel Injection Systems (EFI). Delivering a system without good documentation is not a professional way to deliver a system in today's IT environment. 47 . The complexity of a project.
The more transparent the solution process is to the customer and the more the solution flows through the entire sales process to the final delivery. which can cause the final delivered solution to not meet the needs or expectations of the customer: The sales process The scope of the project Communication from the sales process through the delivery handoff Time-and-material versus fixed-price deliveries IT maturity level Security maturity level The evolving details of the architecture Correlating an integrated security architecture The use of partners The final documentation and customer training The more skilled the sales and delivery team gets at addressing each of these areas with the customer. the more the customer is going to feel that the team is doing what is right and the more the customer will want to bring you back in to help with key business problems. I tried to lay out the following 10 areas of a solution engagement that often get missed or are not thought out well during the delivery or sales process. the more you and your team will be in demand to solve key problems. 48 . some sell "solutions. A company that becomes a "trusted advisor" and produces customized solutions that meet customers' business needs and are manageable will be endeared by their customers. and some become "trusted advisors" that help customers solve key business problems. I wish you great success in your endeavors to provide key solutions to customers and become trusted advisors to them." some sell both. Based on my experience. There are companies that sell products.10 Best Practices for a Successful Customer Solution Engagement Conclusion A number of things can prevent a solution delivery from working as sold or as expected by the customer.
com and the Documentation Center (http://www.sun.com Community system administration experts: http://www. Sun download site: http://www.com/download/ Sun training courses web site: http://www.sun.sun.com/display/BluePrints/Main)and the BigAdmin wiki (http://wikis.com/training/ Discussions.sun.com/display/BigAdmin/Home) Support: Sun resources: Register your Sun gear: https://inventory.sun. such as the Sun BluePrints wiki (http://wikis.com/service/index.com/index.10 Best Practices for a Successful Customer Solution Engagement For More Information Here are additional Sun resources.sun.sun.jsp SunSolve: http://sunsolve.sun.sun.jspa) and the BigAdmin Discussions collection (http://www.com/documentation/) Sun wikis.com/bigadmin/content/communityexperts/ 49 . such as Sun forums (http://forums.sun.sun.com/bigadmin/discussions/) Product documentation at http://docs.sun.com/inventory/ Services: http://www.
Inc. AMD.10 Best Practices for a Successful Customer Solution Engagement March 2010 Author: Edward Clay Copyright © 2010. for any purpose. This document is provided for information purposes only and the contents hereof are subject to change without notice. Intel Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores. UNIX is a registered trademark licensed through X/Open Company.S. Other names may be trademarks of their respective owners. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International. Ltd. . including implied warranties and conditions of merchantability or fitness for a particular purpose. without our prior written permission. Worldwide Inquiries: Phone: +1. Oracle and/or its affiliates.A. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. CA 94065 U. Opteron.7000 Fax: +1. electronic or mechanical.506.7200 oracle. This document may not be reproduced or transmitted in any form or by any means. All rights reserved.650. nor subject to any other warranties or conditions.506. Oracle and Java are registered trademarks of Oracle and/or its affiliates. and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices.com and Intel Xeon are trademarks or registered trademarks of Intel Corporation. This document is not warranted to be error-free. the AMD logo. whether expressed orally or implied in law.650.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.