1 HOW TO AID LESS TECHNICAL CLIENTS WITH ENTERPRISE PROCESSES (EN) AUGUST 26, 2015 Zoltan Gal

2 Table of contents Introduction and terms 1 Pre-project 2 Sunrise 3 During the project 4 Sunset 5 Conclusion 6

3 Tech client: a company/person, who has technical background, besides their domain knowledge Nontech client: a company/person, who is skilled with their own business, but they lack technical staff/skills, so they should rely on us in almost all technical matters The presentation will be (mostly) tech lingo free, to give general guidelines We will be focusing on approaches, and not solutions As we go through the typical phases of a typical project, we’ll cover both types of clients In the end, we’ll try to sum it up, and have some Q&A Introduction and terms TERMS INTRODUCTION

4 Pre-project / (pre)sales Tech They have a vision They have a relatively clear concept, just need someone to actually realize it We can assume some tech knowledge, but it never hurts to clarify Nontech They have a vision (sometimes), and practically nothing more They need us to come up with concepts, and architectural plans They have contacts, so they are likely to know buzzwords already We –always– need to make sure they get to know the real meanings of such words

5 Sunrise / initial workshops Tech They are likely to be somewhat skilled in estimations They usually have an idea about roles They can make better decisions about tech choices, defining the path on a longer term They are usually aware of the importance of regular face to face meetings Nontech They need to learn estimations, hands-on education helps, like planning poker cards They need to understand the roles, like PM, BA, designer, sometimes even TW They should be pushed towards optimal solutions, while informing them about the cons Even being expensive, workshops should be held frequently, to accelerate daily work, and build trust

6 Sunrise / estimations Tech and nontech Always show what is NOT in scope, not just what is Keep a list of epic estimations, and update, or clearly invalidate them As the scope and project nature changes, review the scope of the older estimations There should always be options to select from, even if one is exceptionally better than the others Having the actuality (or the illusion) of free selection builds trust

7 During the project Tech They usually have experts to rely on, in case a term or approach is unknown They still need to be reminded from time to time about limitations Nontech They rely on us, but it’s wise to use external resources, like articles and videos If other sources agree with us, client trust should raise Limitations need to be repeated frequently, so their expectations can be managed better This applies to both project, and technical risks

8 During the project / 3 rd party management Tech They usually have their own ideas in selecting their 3 rd party vendors We need to get involved in this process as much as possible Usually they are aware who is responsible in case of problems We should offer EPAM solutions, if a need arises Nontech Usually they have no idea about vendors, they don’t even realize the need for one We need to drive selection processes, sometimes even make the decision ourselves The lack of tech elaboration might compromise the whole project If we have a high trust, we have a chance to fill (almost) all vendor needs within EPAM

9 During the project / communication Tech and nontech We need to make them feel, we are one, for this, always refer to “us”, and not “us” and “them” We should maintain an open engagement, suggesting new areas to grow We need to keep in mind we play a lot bigger role in nontech client successes It’s okay to express personal opinions, even in tech discussions Always expose the true situation to them, it’s never a good thing to hide important things Avoid expressing needs only, always suggest action plans, or provide process descriptions Reporting is always a delicate topic, in case of nontech, it’s recommended to start with informal reports, and later move to formal ones It’s always beneficial to practice client lingo, tech people often have difficulties with it Choose the ones to lead client discussions who speak both

10 During the project / UAT and demos Tech If the have a skilled BA or equivalent, this might not be an issue Sometimes we only need to gather our needs, what we want to hear on demos and dry- runs Nontech We need to treat them as juniors We should hold the first demos, like if we were the client, and later transition The first UATs should be based on written scenarios, with reporting forms created for them They should be told about layered tests, like +/-/exceptional (edge)/intentional damage Later, written test cases should be exchanged for functional and thematic lists, or nothing

11 During the project / role of the BA Tech Don’t let them confuse PM, BA, TA roles Try to evaluate client-side BA before anything happens, and provide constant feedback Nontech Has an even more important role Aim to have a skilled one from the start Remind everyone B stands for Business, so the proper person should have not only tech and general BA knowledge, but also domain knowledge as well Client side, EPAM side, both?

12 During the project / growth potential Tech and nontech How to assess growth potential for the project? And for the product? How to determine growth direction? How to handle project shrinking?

13 Sunset Tech and nontech Sadly I don’t have any hands-on experiences, all nontech projects I know are still ongoing One important aspect could be the proper definition of the final project delivery package Be mindful if we are switched with a different vendor, they will look through the package, and inform the client if we screwed up anything

14 Conclusion Q&A Thanks for listening! Seek me out, if you have questions, comments, or feedback! via Zoltan Gal via Skype for Business zoltan_gal83 via Skype Or later today in person, likely in a local pub