IT Managed Services – Effective Operation of the Maintenance Process of IT Systems
What are Managed Services?
The Managed Services model is already used in many industries, including HR, manufacturing and IT, and is becoming one of the most important and fastest-growing segments of services. Another important issue here is security – often an external, specialized company can provide not only the appropriate conditions for achieving better results, but can also better ensure the security of access to data.
Due to growing interest from managers in this model of cooperation, the topic is becoming increasingly popular on European market. Based on the experience which I have gained at JCommerce, I would therefore like to introduce readers to the concept of Managed Services.
Managed Services as support for IT governance within a company
The Managed Services model has a wide range of potential applications. The simplest indicator of the moment at which it is worth considering the introduction of Managed Services is the implementation phase of the new system. After building the IT infrastructure and the commencement of system operations, it is necessary to conduct maintenance on the new system. It is precisely at this point that Managed Services start to be used, the aim of which is to take care of the area indicated by the customer, e.g. to ensure the continuity of the company’s ERP system or to ensure the smooth functioning of business intelligence systems.
Managed Services, in terms of support for business, cover a wide range of services and can encompass every part of the company’s IT system. The main tasks are to manage and maintain servers, infrastructure, applications (ERP, CRM), and data processing systems and to cover the crucial area of daily management of technical support services. In addition, the range of services can be extended to the Help Desk and Service Desk. Additionally, the variants of service provision by the service provider, offered by the market, are also beneficial to the customer. Support services can be carried out on the customer’s own technological background or in the form of a model in which the supplier is fully responsible for the supply and maintenance of solutions, as well as for providing the environment and infrastructure.
Why are Managed Services worthwhile?
As I previously mentioned, the range of services is very wide, but it is worth mentioning the benefits to the customer. It is worth looking at them through the prism of the challenges facing today’s IT departments in Europe. As indicated by the C-Level report “Managed Services – A new trend on the outsourcing services market”, increased operational efficiency, optimizing IT processes, reducing operating costs of IT infrastructure, access to new technologies and skills, and higher service levels are all still among the most important IT department tasks. This goes to confirm the apparent trend for many companies to move away from the physical ownership and management of their resources, towards the transition to using an external partner to maintain the environment or IT system, either in part or in its entirety. Such decisions in particular are facilitated by the growing popularity and understanding of cloud services – where the issue of physical possession does not arise, and the technology is fully prepared to manage applications in a secure and efficient manner from any location.
Regardless of the area of IT, or the degree to which the company decides to embrace Managed Services and what type they choose, we can identify some common benefits for companies which opt for this solution.
Again, I will refer to the experience of JCommerce, which offers support to its clients through the management of various IT platforms. Using the Qlik application (which is a Business Intelligence tool supporting reports and analysis) as an example, we can illustrate the complexity of the operation and maintenance in the smooth operation of the given IT solution. How? Well, Qlik gives users the ability to scale and to create a wide variety of reports for all the company’s departments and facilitates the customization of the tool to the individual needs of users. Any large-scale expansion of the functionality of the Qlik platform therefore requires constant monitoring and development. By opting for Managed Services supporting this type of application, we can gain the following benefits:
- Increased efficiency of the system, applications, and the IT department itself, which has the possibility of concentration, e.g. on the development of innovation in the company, or better support for the launch of a new product,
- High level of flexibility and scalability of resources, which the organization does not possess, with the possibility of expanding solutions in step with changing business needs,
- The possibility of accurate cost planning and accounting for a tangible effect based on the SLA (Service Level Agreement) conditions agreed with the supplier.
Based on the experience of our customers, the decision to cooperate with the Managed Services provider is influenced by several criteria, the most important of which is the particular area of specialization of the supplier, for example Managed Services for data centers, services pertaining to the management of ERP applications, Business Intelligence, website maintenance and technical support services in a diversified IT environment within the company.
The growing popularity of Managed Services in Europe
The Managed Services model is relatively young and just starting to gain the confidence of entrepreneurs. There is nothing surprising in this, because it results from the evolution of the use of outsourcing services. After the phase of outsourcing technical resources to support the implementation of IT, business is becoming increasingly ready for the next, more advanced forms of cooperation with external partners. The European entrepreneurs takes an ever bolder approach to the possibility of transferring control over a given area of their business to an external provider, despite the objections and doubts related to this process. In this case, a few key questions may help in the decision-making process:
- Do you control the increase in IT costs in your company?
- Do you engage an excessive amount of internal IT resources in tasks which can be classed as maintenance, rather than development?
- Do you observe a seasonal increase in your use of IT professionals, or can you not predict the need for their involvement?
- Does your IT system require development, frequent repair or performance monitoring?
- Are unusual competencies, not readily available on the market, required in the maintenance of your IT system?
If reading this article has already raised similar questions, it may be worth taking a closer interest in Managed Services. It is worth remembering that the model of cooperation which we have described transfers the risks and costs of managing IT systems to an external supplier. In order to improve efficiency it also assumes the responsibility of IT system management, freeing up the customer’s internal IT resources. Another advantage is the fact that it is the customer that specifies the expected effects of cooperation together with the supplier, and indicates the critical parameters.
In summary, Managed Services are not a new tool as such, but in some countries it is visible that significantly growing number of companies have started opting for this form of IT maintenance solution. As with anything new, it involves some uncertainty and risk; however enterprises looking for new solutions and optimizing management costs are increasingly turning to the outsourcing model. Of its many advantages it is especially worth mentioning that this is a bespoke solution, and the enterprise has the ability to assign the most problematic issues in the area of IT infrastructure maintenance to external specialists.
How Not to Come Unstuck When Implementing a Business Intelligence System – Part 2
So how do you avoid mistakes in the process of implementing a business analytics system?
Identify your needs
Even during the pre-implementation analysis, it is vital to determine the specific problems and questions to which Business Intelligence systems will help us find the answer. A failure to clearly define these issues may mean that the system will contain all the data, but in actual fact will be of very limited use. Each company has different characteristics, different issues which must be dealt with, and analytical reports must respect this uniqueness. To make this possible, the system must be implemented so as to optimally fulfill the needs of a particular customer.
Make sure that the correct needs are identified
The incorrect identification of needs is also a major issue in implementing a BI system. The most common reason is the desire to have all the data and analyze all the areas that are redundant (in a previous article, I wrote why having all the data available in the BI system is inefficient). A faulty analysis means that in theory all the data that we wanted to have is available in the system, but in practice we are unable to gain full benefit from it.
Give yourself enough time to analyze
Business and pre-implementation analysis is one of the most important stages of each implementation of Business Intelligence. Customers may seek to reduce the time for analysis to a minimum or accelerate the individual phases. Unfortunately, errors or omissions at this stage can be very costly in later phases, and often result in delays in the completion of the project as a whole.
Get to know the tools
Each new system is useful insofar as the people who use it can derive benefit from it. If the end-users are not able to use BI reports and analyses effectively, the system will be of limited use. Unfortunately, customers often overestimate their knowledge of the tools and sacrifice time spent on training, which ultimately means that the system is not utilized to its full potential.
Above all, the final results of the implementation of Business Intelligence, from the perspective of the end-user, are the reports and the managerial cockpit. Due to the huge number of different specialists (even within a single company) who can reap the benefits of BI tools, as well as the diversity of their tasks, we cannot ignore the fact that they have different reporting needs. Any lack of appropriate visualization methods, tailored to the needs of specific groups, means that although reports show the correct data and the desired information, they are unattractive or ineffective for end-users, who therefore use them reluctantly or rarely.
Use only the essential tools
Depending on the choice of technology and software provider, some systems offer a wide range of different reporting tools, data presentation methods, and access points to information in the Business Intelligence system. However, there is a risk that too much equipment can cause a sense of distraction or confusion among end-users. So use only those tools you really need in choosing a certain, proven, developed and scalable solution to last “for years”, because changes are expensive and cause confusion, reducing the efficiency of the company as a whole.
How Not to Come Unstuck When Implementing a Business Intelligence System – part 1
The problem of “dirty data” refers to virtually all Business Intelligence implementations, regardless of the size of the data. In every natural environment, every computer system, there are errors and omissions in the data. This includes the problem of so-called dark data, or data which is not used, both due to the fact that it is useless, and because it is poorly organized and therefore cannot be effectively processed. It is therefore important to devote sufficient time to eliminating inconsistencies and to determining their origins, as well as to the arrangement of the data that is valuable in the analytical process. The “cleansing” of the data is very important, because all incorrect or incomplete information will affect the quality or even the correctness of the results of reports and analyses in the BI system.
Too much data
The amount of data stored and generated daily by companies is very large and constantly growing. However, this doesn’t mean that all this data will be useful for the implementation of the BI system. A difficult but necessary task is the selection of appropriate data – even at the stage of pre-implementation analysis. The integration of other data will result in prolonging the analysis and implementation processes unnecessarily (and thus also increase the cost), but does not bring any real analytical or business benefits.
Nobody to take responsibility for the processes and data
During the pre-implementation analysis it often turns out that there is nobody who is clearly responsible for some of the key processes. This just goes to extend and complicate the analysis and the subsequent implementation of the system, due to the fact that these “orphan” areas are very difficult to verify, clean and implement.
Differences in data during migration
During the implementation process, within which the migration of a current solution to another tool takes place, it often turns out that the data in the new system is different in relation to the previously used solution. This is a fairly typical situation and results from changes made to the system during use, and as a result the guidelines connected with the starting point and adopted for the migration may differ from the existing condition of the system. In such situations, cooperation between the developer and end-users is vital to identify the source of the problem and make it clear that the new solution is trustworthy.
Lack of openness to change
Even the best system would barely be worth having if there were nobody to use it. A Business Intelligence system must be based on real needs and the actual interest of potential end-users within the company. In a situation where employees are resistant to change, it is essential to ensure that they come to trust the new tools, and that in turn their needs and objectives are met in full.
Qonnections 2016 – how Qlik Has Changed Strategy to Become More Customer-centric
All this means that Qlik will be focused on a strong definition of the market, starting from a shift in centricity in the areas of development, data, buyers and analytics. Developers will no longer be “just” consultants, as their role will shift more towards web programming technologies; data will be moved to the cloud, outside of the organisation, and Qlik Sense will offer multiple opportunities to mix diverse sources of data; buyers will act in a more agile manner and more as ‘self-service operators’ as the latest Qlik Sense is about enabling customers to modify reports on a daily basis; and finally the shift in analytics means looking beyond the BI data pond and involves a greater dose of embedded analytics. It was clearly indicated during the general sessions of the conference that, as there is more and more external data, there will be a greater shift to analysis and data will be discovery driven. The future (and maybe this is the path Qlik will take) is about smart data discovery solutions. Qlik also focuses strongly on business, not procurement, as it is business that cares about the data and uses the results of data discovery.
Qlik Sense – seeing the whole story
The story of Qlik for 2016/2017 is about seeing the whole story that lives within the data, enabling agility for business users at the same time, but keeping the sense of trust and scalability that comes from IT. Another important aspect for the new Qlik Sense will be the shift from non-linear to associative visual analytics probing all associations within the data.
In terms of product positioning, Qlik will maintain its two-product strategy. Qlik Sense shall be more than a self-service product and QlikView remains a strong base with the platform approach. An important factor for improving the self-service aspect is the fact that there is no need for technical skills to create reports. An easy drag-and-drop approach is used for any user wishing to see the whole story in terms of data stored e.g. in Excel spreadsheets. A unique feature is that the latest platform is free-to-use for a single user, which means that even personal data such as household income and expenditure can be visualised after just a few clicks. On the other hand, there are more functions and possibilities for custom analytics, from non-standard designs to reporting and collaboration including data streams, data stories, sharing and exporting and printing.
Qlik Sense – what is your story?
The new Qlik Sense is also about design and proper UX/UI. It focuses heavily on storytelling, simplicity and comparability. It seems that it will now be crucial for Qlik partners to have in-house UX/UI designers together with web development capabilities to face new challenges and the customer-centric approach used by Qlik, as it is now up to the buyer to customise their reporting experience as much as possible using any device from a regular laptop monitor or mobile device to a properly arranged PDF printout. The reporting possibilities offered by Qlik seem to be endless, limited only by the needs of customers and the technological abilities of BI consultants and web developers.
The Qonnections 2016 conference was definitely a success in organisational terms. The number of events, a few hundred technical and success-story sessions and energetic morning meetings with key Qlik representatives, topped up with a final hour-long conversation with the renowned astronaut Scott Kelly, confirmed that, as Gartner’s magic quadrant shows, Qlik is the leader in the modern Business Intelligence world and will most likely remain so in the years to come.
Watch some highlights from Qonnections 2016
Quality Assurance and Testing
How to build an expert nearshore mobile app development team, part 3
Nowadays, quality assurance is essential for publishing high quality apps, and with a plethora of devices on the market, it isn’t an easy task. The possibilities and challenges of testing in mobile worlds are slightly different than those in desktop/server development. So, what are the best practices for this?
Ongoing mobile testing process
With the complexity of current software, the old model of testing the software at the end of the development cycle is long gone. Testing should be done throughout the development process – for every functionality added, there should be testing (both manual and automatic) to ensure that the functionality actually works. Automatic testing is also essential to ensure that further development of the project, and changes in the project environment, don’t damage any previous functionality.
Unit testing is a classical approach to automated testing. In this approach, each code functionality is tested individually in separate unit tests. This can ensure that each code unit works when it should, and behaves as planned in the case of errors. Unit testing works particularly well when testing business logic.
However, many mobile applications are written in the ‘thin client’ way, which means that most logic is on the server side, and the application’s only role is to download data from the server and present it to the user. This is often the preferred model, because one type of business logic can be implemented on the server and used on every platform (each mobile platform, web and desktop).
However it makes unit testing slightly less useful – unit testing is not the best tool for testing UI, and there’s not much business logic to be tested. Unit testing is still useful in testing the technical aspects of UI – proper initialization, handling of screen rotation, saving user data, maintaining the correctness of data downloaded from web services, etc. – but unit testing is not an effective tool for testing the entire application from the user’s perspective.
Of course, this changes when application is built in the ‘fat client’ way – in this model, the application has its own internal data model and business logic that is partially or fully independent of that which is on a server. In this case, unit testing is essential for making sure that each use case and each code flow behaves correctly in numerous possible scenarios.
UI automation testing
UI automation testing constitutes an answer to the problems inherent in unit testing. Instead of focusing on individually testing each part of the code, it tests the application as a whole (black-box testing). Contrary to its name, it doesn’t only test UI – it tests the entire application, but from a user perspective. Instead of testing which code is executed, it tests the results of user interaction. For example it tests that results of pressing the button are as expected. This allows the entire application to be tested – both UI events, internal code for web service communication, and server-side code that responds to data. At all times, it also tests to make sure that the application doesn’t crash or execute properly.
An additional advantage of UI automation is that it is much better suited to testing device-dependent problems, such as problems with layouts, specific custom behavior on some devices that needs to be handled differently, etc. Running the same tests on different devices ensures that the application will work correctly on a wide array of devices, and may find unexpected errors that can’t be detected with unit tests.
Testing mobile application on a Device Farm
Every respectable mobile application vendor has multiple devices by which to test applications – both manually and using automated tests. This is a good foundation during the development phase for finding the most common problems and correcting them as soon as they are found. However there are so many devices on the market that this is impossible to test on-site for even a noticeable fraction of them. Android has more than 11 000 device models at the time of writing, and that number is constantly growing. Samsung alone has more than 1000 device models that are sold worldwide (including local variations for selected markets). iOS and Windows Phone have a slightly smaller number of devices, but they still come in different variations and system versions. That variety makes it unrealistic to have real market coverage of testing, when testing is only undertaken on-site. Luckily there are providers that offer device farms – remote services that allow companies to run remote tests on a large number of device models in a short time. Device farms are inexpensive, because you only pay for the time used on devices, and tests typically proceed rapidly. It saves the vendor the cost of buying hundreds of devices for testing, and also makes it possible to test the same device with different OS versions.
Device farms allow for the undertaking of most tests – unit, UI automation, and others, on multiple devices. Those tests make it possible to see detailed results, which in turn enable developers to find problems even if they only arise on a small subset of devices.
Additionally, aside from automated testing, device farms also make it possible to take screenshots of every screen in the app, which then allows for manual (human) checking to spot potential UI problems.
Beta testing and automatic crash reporting
Even a perfectly tested app may still have potential problems – new devices and versions of mobile systems arise every day and some of them change important behaviors or hardware features. So before final release, it is wise to first release the application in beta test mode. The app may be available to everyone, but the reviews and scores from the beta test are removed when the full version is released. Using the framework for automatic crash reporting, every time an application crashes on the user’s device, developers get a detailed report including which devices it was on, what version of OS, and when the application crashed. Due to this, it is possible to fix all the potential problems that weren’t spotted before going public, and allows for the release of a “final” version that is bug-free.
Automated crash reporting is essential even after full release – this mechanism makes it possible to fully monitor the market and spot potential problems even before users report them. For example, if the new OS version makes the app crash, developers receive instant reports of such events and are able to quickly pinpoint the reason and fix it.
Quality Assurance and Testing summary
Testing is essential for the ongoing quality assurance process, and should be done throughout the development process, not just before releasing the application. Combining unit testing and UI automation testing allows for a sufficiently acceptable initial release, while beta testing each version and monitoring crash reports throughout allows developers to make sure the application works well throughout its lifecycle.
Agile Process & Team Setup
How to build an expert nearshore mobile app development team, part 2
The Agile process of development is the preferred way of developing mobile apps. With Agile, we use the so-called sprint – it’s a set period of time during which specific work has to be completed and made ready for review. The length of the sprint is fixed and chosen at the start of the project – for example 2 weeks. Then, at the beginning of each sprint, we set goals – what we want to implement and function – and, after the sprint, that part is ready. After the sprint we can evaluate the current state of our product, and can redefine priorities or even the design of the application. Each sprint is designed to have relatively small, but fully working functionality added or modified. Thus we make use of Agile methodology to maintain the flexibility to make changes after each sprint. There is freedom for the client to make changes during the development to react to the market, user opinions or changing business priorities. Changes can be made at the beginning of the sprint (planning phase), but not during the sprint itself (development phase).
The above description is true for all software development, but is particularly important in the mobile world. Current distribution platforms (App Store, Google Play, and Windows Marketplace) make it very easy to publish an early version of the product, and even easier to update it often without any effort from the end user. This, along with the agile development flow, allows clients to publish the app early, see user reviews and reactions, and iterate functionality with each sprint, publish new versions and get feedback from the real market. Feedback from real usage makes it possible to set priorities that benefit users the most, and to alter the original vision so as to make the most attractive product. Agile, along with the frequent publish model, makes it faster to iterate toward a polished, functional product.
Product owner in the Agile development model
The product owner represents requirements in terms of software development. The client should select a single person for this role, who will be the main contact responsible for providing a vision of the product from the client’s side, for cooperating with the team which will transform this vision into the product design process, and then for implementing this design. The product owner is not responsible for the technical details of implementation (unless the client so desires), but is responsible for understanding target audiences and desired functionalities, answering questions about projects, and the ongoing process of selecting the priorities for the next sprint. The product owner doesn’t need to have programming experience, but it’s good if he has some understanding of the market, knowledge of similar solutions and possibilities, as well as a basic level of technical knowledge. The product owner should have enough time to be available for communication with the development team throughout the process.
Scrum development team
The Scrum team is responsible for executing the product owner’s vision and requirements. This team creates the technical architecture for the application, implements it, and tests it. The Scrum team is in constant communication with the product owner during development. At the beginning of the sprint, the product owner is responsible for selecting the most important tasks to implement, and the team is responsible for estimating how many of those tasks they are able to do within the confines of this sprint. They consult on the details of requirements with the team owner throughout the sprint process, and the results of their work is tested, then submitted for review at the end of each sprint.
Depending on the cooperation model, the entire team (except the product owner) can be from the service provider, or composed from among both the client’s and service provider’s specialists.
Setting up the team can be done after defining the requirements and scope of the project, as well as defining the expected deadlines for project development. The typical composition of such a team is as follows:
-> Native development
Team leader/Scrum master – responsible for managing the team, tasks, and overseeing development
iOS/Android/Windows Phone developer(s) – at least one developer for each platform, responsible for the implementation of mobile apps
Server developer(s) – responsible for integrating existing data sources or creating new ones
Testers – responsible for testing the app, finding and reporting quality issues
-> Cross-platform development
Team leader/Scrum master – responsible for managing the team, tasks, and overseeing development
Front-End HTML/JS developer(s) – responsible for the implementation of the mobile app for all platforms
Server developer(s) – responsible for integrating existing data sources or creating new ones
Testers – responsible for testing the app, finding and reporting quality issues
The exact size of the team depends on the scope and complexity of the application, as well as deadlines, and should be determined after consultation with the service provider.
Setting the requirements and the final team are important when starting a project. After that, the next step is to set the testing strategy, which we will dive into in the next article.
Setting the Requirements for an Expert Nearshore Mobile App Development Team
How to build an expert nearshore mobile app development team, Part 1
The mobile app development market has exploded in recent years, but it still takes careful effort to create and manage a perfect team to accomplish your business goals. ‘Mobile development’ can encompass a wide range of products: from a 1.5” smartwatch screen, to smartphones, tablets, cars, up to 100” smart TVs. Whatever you want to develop your app for major smartphone platforms like iPhone and Android smartphones, or to use the mobile market to its fullest, it all starts with business requirements.
Client needs and requirements
The first part of the process is always to define the needs and goals of mobile development. Those requirements have a variety of details – some clients can define exactly what system they want and can create a detailed specification of their expectations. Other clients only have more general business goals. That’s ok – there are appropriate models of cooperation for each of these cases.
The process of creating and updating project requirements is often split between the client and service provider. If you have a detailed requirements and want to directly control your development team – use the team extension model and use the provider’s developers as your own team. If you have requirements, but want to make use of the experience of the service providers to improve and refine them – use a development outsource model to have the analysis, design and project development done by the service provider. If you only have business goals – use the project outsource/managed service model, in which the service provider will take over the entire process – starting with designing a business model and proposal for your project(s), refining it, implementing it, and continuously supporting and further expanding it over time.
Read more about cooperation models.
To start defining the project requirements, we need to answer a few questions. The first one is about platforms – does the client want to release the app for iOS, Android, Windows Phone? Depending on goals, you can pick all of the above, if you want to have almost 100% market coverage, or only some of them to save on expenses. Every platform is different, and each one requires a slightly different approach to designing certain features. This is specific to the mobile world – projects typically have exactly the same requirements, but the resulting apps are slightly different on each platform. They are customized to the UI standard of each platform, tailored to services offered by each platform owner, and designed to be familiar to the target audience of each system. Those differences lead to the biggest question in mobile projects: Native or cross-platform development?
Cross-platform development makes it possible to create apps for every platform in one go, so typically it’s less expensive and requires smaller teams. But this technology often creates problems relating to implementing features, performance, stability and quality. It works great for apps for which the primary requirement is to present the user with information; but features like GPS, camera, advanced use of maps, layered animations etc. can be problematic.
Native development allows the team to achieve everything that is possible on each platform, offer the highest quality and level of performance, as well as perfect customization for the UI and design patterns of each platform. Native means that each platform has its own team of developers (at least one per platform), so there are more developers and the cost is higher, but it yields the best results.
Your service provider should always help to decide between cross-platform and native, because this impacts both technical implementation and limitations, team setup, and the budget.
If you only need the app for one platform – for example you are making an application for internal use in your company, and you only use iOS – always choose native, because there won’t be any difference in cost, but the quality will be higher.
Mobile apps are rarely stand-alone. Usually the data in the application is downloaded from the Internet – by means of a mechanism called API or webservice.
The client may already have some system and database which can be integrated with mobile apps. Alternatively, the service provider can design a web-based CMS (Content Management System) that makes it possible to easily edit mobile app content in the web-browser.
Defining app logic and functionality
After setting the baseline requirements and deciding on the external webservice, it’s time to define the core of the application – features, UX and UI. Depending on the cooperation model, this can mostly be done by the client, or the client can just define the business goals and the overall idea, and the service provider can design the exact features, UX and UI.
These are the typical phases of app design:
1. Functional specification – defining what should be in the application – which features are essential and which are optional. ‘Target audiences and devices should be kept in mind throughout the process..
2. Interactive mockup/wireframe – this stage defines UX and the overall layout and screens of the application. At this stage, the UX designer focuses on designing screens, transitions, and placing UI elements like buttons, images and text etc. However this stage doesn’t include the final look – only the layout. Preparing this stage allows the client to click through the prototype, and see how the application presents data, whether it is sufficiently intuitive etc. Making changes at this stage is far less expensive than making them after the application has been finished. Therefore, iterating the design and gathering feedback from potential users is essential.
3. Graphics – when the mockup is accepted, the next stage is to design final graphics for the designed mockup. This defines the final look of the application.
Having functional specification, the mockup and graphics concludes the requirement-setting phase. The next step is to define the team required for the project and the process of development, including quality assurance and testing. We will describe all this in the following articles. So stay tuned!
Formalising IT Contract Details
Knowing the rules of how to play chess does not make you a world-class chess player.
Working on the Client’s initial request
There are many types of requests that the software Vendor receives from the Client. Some of them actually provide little context, whereas other ones are context-rich messages. Depending on the prospect’s input (materials, requirements, business knowledge, etc.), we are able to prepare our initial feedback.
Here is an example of a context-rich enquiry:
I am the VP Technology at …
We are looking for ways to expand our development capacity and I have been tasked with identifying near-shore and offshore opportunities to outsource development. I look forward to opening a line of communication to discuss this further.
I look forward to hearing from you to discuss the requirements and our potential business relationship in more detail.
On the other hand, a low-context enquiry example is as follows:
We are an established medium-sized Internet business, operating for x years in the y industry.
We wish to rewrite our website using the latest Z technologies to make it more stable and flexible, as well as to add new functionality.
We are looking to outsource this, in part, to a team of nearshore developers who can work with us using the SCRUM methodology. This would involve rewriting all layers of the application (the core solution to use as a starting point has already been created), using the following technologies:
.NET, C#, MVC, some AngularJS, Entity Framework, Identity 2.0, HTML5, CSS3, bootstrap.
Let me stop for a while and focus on the crucial word: Feedback.
Feedback can have several dimensions. Let us focus on just two of them for now.
First: Feedback as an immediate reaction to what has been submitted to the software Vendor. It is not about what is our answer to the Client’s initial request. It is about showing our potential partner that we take care and are ready to talk about the idea – that we are committed and supportive.
Second: Feedback as a relevant info based on the Client’s request, which includes all the necessary info /the so-called: material pack/.
Third: Hybrid – as a combination of First & Second.
I am not here to judge which of the presented types of feedback is better and more effective. I am trying to make you aware that both of them are important and, in most cases, Hybrid (the third one) should be a kind of habit when approaching the Client’s initial enquiry.
We all know that first impression is crucial (and it does not matter if it is fast or slow). But what is more important (based on my observation I have made over the past years when approaching Clients with the JCommerce team) – is what happens next: When all the dust of the first contact has settled, all that matters is the quality of feedback, the quality of communication during the initial phase, the understanding of the Client’s needs, and being responsive and supportive.
How can we influence the quality of initial feedback?
Let me present you some practical tips below when approaching the first contact with the Client:
1. Arrange a direct follow-up call (Lync, Skype, Google Hangouts, etc.) with your potential partner.
2. When sending your calendar invite, please include a high-level agenda (this is a good moment to specify what you expect and what is missing).
Examples of high-level agenda:
– Introduction round (who is who)
– Overview of the Client’s organisation (business history, services, etc.)
– The Client’s expectations and current needs
– The Vendor’s overview
– Discuss the Vendor’s technical capabilities and references
– Discuss software development approaches
– Discuss the Vendor’s Human Capital Capabilities
– Discuss the Business Model and the Ramp-Up Phase
– Plan the next steps (a direct meeting, a formal arrangement, etc.)
3. During the first video call with your prospect, listen carefully and make relevant notes (it is highly recommended to use Microsoft OneNote when using a Lync connection), as you will be able to send all of the notes and the agreed further plan of working together right after your call. One of great habits is to make notes in real time – and show them on the conference panel screen to your Partner – this definitely builds trust and keeps your communication at a very professional level!
4. Right after the initial call, send a note to all of the participants (include roles and plans for the next steps).
5. Based on the agreed steps forward – keep your promises (deadlines, materials you promised to send, etc.)
Formalising the collaboration – Contract & Procedures
If we are lucky 🙂 and we have managed to convince our potential Client to go ahead with us, the next big challenge is to formalise the collaboration – before we finally start to work on the software project together. And because this is not as simple as it may seem, let me share with you some practical insights into how we, at JCommerce, handle this process smoothly.
As reaching a formal agreement between the parties should not be a long and exhausting process, I would like to present here a high-level concept of a contract proposal that I think is clear and efficient when formalising the co-operation between two entities.
For the purpose of this paragraph, I have focused exclusively on a contract template for outsourcing, when the Client decides to build a dedicated software project team in the Team Extension Model. I have consciously omitted standard paragraphs in the contract template, such as: Parties, Confidentiality, IP, etc. My main goal is to outline and focus on things that matter the most to Clients approaching outsourcing Vendors, especially when forming an initial co-operation flow and setting up the procedures.
1. Defining the development approach (team extension, development outsourcing, project outsourcing, etc., as well as the methodology of working, e.g. SCRUM)
2. Explaining the pricing model (Time & Material, Fixed, Hybrid)
The Developer’s full name, experience level and rates (hourly, daily, weekly, etc.) – all in
Alert! It is very important to explain what the all-in rate of a developer includes:
– A company notebook (including necessary software licenses),
– A Lync-compatible headset,
– Usage of the Vendor’s office facilities, including meeting rooms and an Internet connection,
3. Defining the resource allocation (we all should define in advance the scale of utilisation of a developer engaged in the Client’s project)
4. A detailed explanation of the seniority level
Alert! It is extremely important to explain what we mean by, e.g. Senior .NET Developer, Professional .NET developer, etc.
5. Alternatives when replacing developers (defining the warming-up phase, shadow resources, etc.)
6. The period during which the rates are ‘frozen’.
Alert! Most of the companies forget about the fact that the rates are valid for a certain period only. It is good to define the from – to duration when a given development rate is valid and it does not change.
7. The issue of the exchange rate index.
Alert! Nowadays, a lot of vendor companies have issues with fluctuations of the exchange rate index. For that reason, when presenting the hourly rate to your Client, try to think on what basis you have calculated it, i.e. if you offer your British Client a rate of GBP 30 excl. VAT per development hour of your employee, then you should always refer to the value of your local currency index (in my case it is Polish Zloty), which keeps your business healthy. There are several solutions to help both parties weather the fluctuations of the exchange rate index. At JCommerce, we develop a very simple Excel formula that allows both parties to adjust the hourly rates (in a critical situation). I will be more than happy to share this solution with you in a separate, private email.
8. Additional costs of working on-site in the Client’s country
Alert! When the development is done in the Client’s country by an Employee of the Vendor, additional costs are involved, such as:
– Daily allowance.
It is also important to define the on-site rate level as well as who will bear the on-site costs of development.
9. Notice Period
Alert! At this point, most of the vendor companies forget to specify what happens when the Client is in need of swapping/adding a new developer to work for them. It is crucial to outline this period in the contract as well.
10. The Client’s Employee Regulations
Alert! It is so important to introduce the Client’s standards and expectations among the development team that the Client is provided with by the Vendor. It could be something like:
– A standardised email domain,
– A dedicated footer,
– Presenting the Vendor’s developers to a third party,
Apart from that, there are also internal policies on the part of the Client, which the Employees of the Vendor should respect. It is important to set them forth in the form of a separate appendix to the contract and let the Vendor’s team read it carefully.
11. Evaluation & Rewarding (bonus) system
Alert! Some of the companies looking for long-term partnerships in the software outsourcing field define some kind of a rewarding system in co-operation with the Vendor’s management team in order to better control and motivate the quality of performance and overall commitment on the part of each employee of the Vendor.
This is one of the solutions owing to which [we can really influence the overall quality of the co-operation.]
For that reason, when signing a contract with the Client, JCommerce and the Client usually define the current team structure and performance as well as its future state. The parameters that help us to reward and analyse the Vendor’s team are presented below:
– Work quality (software/coding/documentation)
– Reporting accuracy (timesheet submitted on time, cases logged correctly, etc.)
– Communication skills (proactivity, taking initiatives, the quality of English, etc.)
– Productivity (meeting deadlines, expectations)
– Absences & being punctual (sick days, sliding hours commitment, etc.
– Telework Policy
Alert! It is important to include telework policy in the contract (which, besides, is not respected in many kinds of project engagement). But this is a part of the efforts necessary to achieve an optimum balance between the business interests on the one hand and the individual interests of the employee on the other.
Some of the practical arrangements in this area include:
– The request for telework must be made at least 2 working days in advance via email sent to the Team Leader
– Telework is limited to, e.g. 1 day a week
– The employee should be available online (MS Lync, Skype, Google Hangouts, etc.)
In my next post, I will try to share and break down the teams (Client vs Vendor) and roles (Client vs Vendor) during the first few weeks of collaboration (the most important weeks!) with international teams across different cultures. I will try to show you the mechanism, tools and practice that may help the Vendor and the Client gain better control over what is happening in the delivery process. More to follow soon!
The Onboarding Process in IT Services
Onboarding as the key process in the interaction between the Service Provider and the Client
If there is any phase of working with the client, which I could assess as the key one and as the one that is likely to radiate and influence every single element of the subsequent relation between the Service Provider and the Client, it would undoubtedly be the onboarding phase.
Given that the sales cycle and contract execution complete a certain stage in the negotiations with the client – the phase in question can certainly be classified as highly theoretical (as it involves assumptions, expectations, the planning of high-level activities, etc.). This phase is immediately followed by the most pivotal stage among all the stages I have already encountered and still continue to encounter on the entire map of interactions with the client. This very stage is the onboarding process for a new client because it taps into the pure practice of co-operation between both parties.
What is onboarding?
It is a representation of an internal project that transforms into action after completing the theoretical phase (of “prototyping” and setting the “rules of the game”). At the same time, this is the first opportunity for both parties to be able to build trust (the importance of which cannot be overestimated in any form of co-operation between two entities): it is when what was contractually agreed upon between the service provider and the client will now be translated into practice and reflected in it while the Service Delivery Team will be providing IT services.
Key roles and the scope of responsibility in the client onboarding process
The clear and transparent creation of roles during the onboarding phase is an element of critical importance. One of the critical roles that will be needed from the very beginning is the one which has been known in the industry as Customer Success Manager, i.e. a specialist who will be assigned to an existing client right after the completion of the contract execution phase. Such a person will be the “owner” of the onboarding process on the part of the service provider and will be responsible for guiding the new client through this phase successfully. The CSM will also be responsible for:
– holding meetings with the client (direct/online);
– documenting the roles present in the client’s structures;
– identifying the client’s key employees and defining their roles during this phase.
The CSM will be responsible for providing information on the scope of client-oriented undertakings in the onboarding process. Another responsibility of the CSM will also be to introduce the Project Manager (a person responsible for the technical course of the onboarding phase), who will directly take on the role concerning the allocation of engineers and the control over the key milestones in the project on the part of the provider.
What stages can the onboarding process consist of?
The key stages of the onboarding process may contain such key elements as:
– Defining the scope of the services provided;
– Installing and configuring the operating environments;
– Preparing documentation;
– Quality Assurance (QA);
Once these stages are completed, there is another very significant element that forms part of the onboarding process, namely the tuning phase on both sides: the Client and the Service Provider.
The onboarding phase is a bit like playing chess. The game makes sense and is satisfying on condition that both parties not only know the rules under which the pieces move on the board, but also strictly observe these rules under all circumstances. The client onboarding process shows in a micro-scale whether both the Service Provider and the Client are ready to co-operate with each other (and they get their only chance to verify it!). A properly created micro-culture of work and interaction between the Service Provider and the Client ensures success in the form of safe co-operation based on trust and quality. A properly conducted new client onboarding process leads to a long-term relationship and makes it possible to build more complex solutions or vice versa. If the service provider does not take care to guide both their own team and the client’s team through the onboarding phase properly, it may turn out that not only do they lose the possibility of developing their services on the part of their client (by implementing the project with a considerable amount of randomness involved), but they are also likely to be unable to expand in the market with their service portfolio for anyone at all (because such co-operation will pose considerable risk to both parties).
PS #1 You can find my article also in the IT INDUSTRY LEADERS Business Report that will be published by Gazeta Finansowa later on this week, concerning: “The key aspect of the new client onboarding process during co-operation in providing IT services”.
PS #2 Curious about JCommerce practical approach when onboarding new client? I’m more than happy to get in touch with you and share our thoughts & experience. Meet us at one of our offices in Poland!
Areas of Risk in IT Outsourcing Process
An outsourcing contract may bring the expected results only when a company finds answers to key questions related to an undertaking of this type in the first place, and then fulfils several relevant conditions, without which the purpose of making such a decision could not be economically justified.
One could say that making a decision to implement outsourcing projects means that an organisation will soon face business risk. Putting an appropriate level of emphasis on the process of limiting such risk may determine whether IT outsourcing eventually will succeed or, conversely, bring about increased costs and create confusion within enterprise operations, thus constituting a barrier to its development.
Over the last few years, I have managed to gather the most important sources of the emergence of risk areas in the IT outsourcing process, which I have classified as follows:
The reason why a company wishes to pursue outsourcing and determines particular business areas to be outsourced
The poorly thought-out disposal of functions which may prove important for enterprise operations and then outsourcing them to third parties could result in a loss of advantage on the market. Too much involvement in corporate expenditure cuts may lead to the contractor operating on the verge of profitability, which naturally affects the quality of the service provided. In both examples, an inappropriate approach to the issue or, in other words, the bending of requirements that determine the success of using such a solution, constitutes a significant factor which classifies outsourcing as a dubious form of service.
Vendor (IT services provider) selection process and determination of the cooperation model
Human, technological and financial potential provides great opportunities, on the condition that it is used optimally (i.e. according to the needs and capabilities of the recipient). There are numerous selection criteria. However, in each case it is important to focus on issues related to the financial circumstances of the disposing party and their experience in the implementation of similar projects, as well as the possibility of providing services swiftly, the disposing party’s willingness to share the risk and a certain amount of flexibility in mutual relations. A number of emerging risk areas originate from a lack of comprehensive analyses and answers to questions that concern such issues as expectations and goals related to the project, determination of the optimum range of services, organisation of a Client’s internal processes, their financial condition and the expected forms of financing of an outsourcing service. It is equally difficult and important to determine the quality of services that the Client expects. Contractual quality parameters cannot be set too high (otherwise, the cost of the service would increase) or too low (if so, the continuity and effectiveness of operation of the Client’s organisation would not be guaranteed). The results of this analysis are of crucial importance to an assessment of the likelihood that the project will prove successful.
This vital area concerns the relationship between outsourcing and the company’s ability to attain its long-term strategic goals, as well as to build up its competitive position. These are, of course, correlated with the quality of services that the Client expects. Quality should be improved as a result of the outsourcing process. A faulty quality estimate will lead to overinvestment or may mean that the company purchases the service at an insufficient level. Well-organised internal processes on the part of the Client play a significant role in the successful fulfilment of the terms of the contract, whereas a lack of appropriate organisation in this regard may even render the contract void. However, it remains crucial to define business goals and expectations, find the best responses towards changes taking place within enterprise processes and develop and apply appropriate methods of measuring the effects of the project. Various factors can serve as reference points here, after all, including costs incurred and financial benefits gained by the Client, as well as the availability of IT systems, vendor’s response time in emergency situations, employee or Client satisfaction, or the shorter cycle of introducing new products to the market. This area also concerns issues related to departure from the chosen outsourcing model and the partner which functioned as service provider. The lack of an exit plan – for instance, taking into consideration how to utilise insourcing or in what way the substitution of one service provider with another should be done – may prove very costly.
An outsourcing solution should be prepared by a person who is at least “one rung” above the team involved in the process to be outsourced (such a person is able to take a look at the “big picture” and define key roles in the newly created outsourcing relationship structure). Nevertheless, management generally believes that its power within an organisation depends on the number of subordinates. Hence it is possible to observe that some managers are clearly reluctant to reduce the workforce through outsourcing. Therefore, finding someone to become a project leader constitutes an extremely important factor in successful implementation. You should choose a person who is counted among top level managers in the Client’s organisation – who exerts considerable influence on its operations and expresses direct interest in successful implementation. Most frequently, a member of the management board will be the right person. It is the specific character of outsourcing services that forces us to adopt such an approach. Even the largest project, after placing it at the lower levels of an enterprise, becomes fragmented and ends in failure. As a rule, it is impossible to perceive the totality of a company’s specific set of circumstances and its long-term plans from the lower levels. Moreover, information concerning the project should be given in accordance with a strict criterion – keeping it cost-effective and targeted at communication limited only to the circle of those most interested in the project. It is difficult for employees on the low and middle levels of an organisation, who are responsible only for a narrow section of corporate operations, to estimate the aggregate benefits which the company would gain from an outsourcing service. Therefore, they perceive outsourcing contracts as a threat which could result, for instance, in job losses. This may even lead to acts of sabotage as regards such projects.
Communication and knowledge transfer
This area concerns the process of outsourcing itself: using control mechanisms and leaving selected competences and implementation capabilities inside a company. Unskilled management of relations with an outsourcing company or companies at the level of drawing up and signing a contract, delegating tasks and, subsequently, conducting work quality tests, constitutes one of the main threats. The area in question covers the processes of both establishing cooperation and creating an appropriate definition of working relations (including the definitions of particular roles in the outsourcing process) at all stages of the project (from negotiations concerning the contract during its term through to its completion stage). At this point, both parties have to examine in detail and determine the areas and rules of cooperation which are critical to the success of the project. It may also prove indispensable here to use the TMS (Transactive Memory System) – a tool intended for planning the process of knowledge transfer in a newly created structure. The success of outsourcing depends on the very ability of our partners to define and negotiate mutual relations (what is crucial here is the mechanism of developing a common glossary of terms which will be used by persons directly involved in the outsourcing process). It also depends on the effectiveness of cooperation methods developed under the terms of the contract. Active interest in the success of the undertaking provides both parties to the contract with a basis for earning profits.
Regardless of whether you are an entrepreneur who uses IT outsourcing, making informed choices (maybe for many years), or a person who still doubts a business model of this type (and perhaps doubts concerning the justifiability of such a solution are unfounded) – please share your experience and reflections in this regard.
This article served as a component of a lecture which I delivered at the University of Bamberg on Friday, 23 January 2015. For several years, the University has successfully implemented a system of student exchanges and internship programmes in cooperation with JCommerce. The topic of my speech was the broadly understood principles of the security of outsourcing cooperation between recipients and IT service providers. The ability to define sources of the emergence of risk areas in cooperation of this type leads to a better understanding of the mechanisms that influence the finalisation of the outsourcing process and obtaining the highest possible quality of security of business relationships established in such a manner.