What Engagement Manager Should Remember During Each Pre-Sale or 17 Useful Tips

What will take you to make your pre-sale phase successful? 

When it comes to pre-sale of some it-services, there are  many challenges to get each pre-sale from first/initial contact to contract signed phase. There are several factors to consider. Get these 17 tips and learn some good practices which could help you to get to success. 

The specific of these findings/recommendations is related to Engagement managers working in offshore software development business.

1. Language is not a secret. You are an engagement manager, this means that you should have really fluent English. Furthermore - you should have 'rich' language. By this I mean using of phrasal verbs, idioms.

2. Try to avoid overloading of non-tech people with tech stuff.

3. Stop generating a lot of recommendations how you can improve client's product during pre-sale. You can do few recommendations, however you are there not to make a revolution! They mostly need you to solve some of their most critical issues and some particular problem, they need  you to simplify their life. Focus on this.

4. Stay positive and catch positive signs. You should be careful during listening and catch following stuff: "With you we need to change...", "You should help us with...", "We expect from you ...". This could help you to build some predictions on 'chance to win'.

5. It's not a good idea to keep silence while you are waiting for something/someone during onsite visit. Fill the gap - tell about yourself, what is your role/responsibilities, etc.

6. During presentation of the company try to be focused on client's biz domain and your expertise there. Clients are not really interested in your success stories within not related to them/their domain areas.

7. Even if you joined company recently - you should know all the history and success/fail stories. Use "we did" instead of "my team", "I..." - use WE.

8. Try to catch what is client's way of doing business, his preferences in management and be agile with your approach. I had a problem with some German(financial domain) client who doesn't really like US way of doing things. By this he meant - structured, well-organized approach. Per him west part of Europe prefers more informal/unstructured/not really "Boolean" way. But this doesn't mean that all German companies prefers such approach or all US companies are structured and well-organized. 

9. Be specific. Try to avoid general descriptions of company's track record.

10. Try to avoid judgment! Never tell anyone that something is "stupid", "wrong", etc. 

11. Tell them that you do the same! If you see something similar in processes, values, etc in client's organization encourage them with this.

12.Try to focus on covering of following: we have .... service for you. Using us and this service you should not care anymore about this, this and this. Allow us to take care about ....

13. Be calm and friendly as much as you can. But be prepared to protect your product/company. But not aggressively, with facts.

14. Stakeholders analysis - nothing special, really common step. But really often forgotten. Never forget about this. Define decision makers and try to figure out their problems which you could help them to solve.

15. Discussion of quality assurance should always take place during pre-sale. Try to cover how they ensure quality, using which tools, approach. Talk about possible approach of working with you.

16.  Go big by doing small. Pilot project. Balance between challenging task and something you could really deliver (due to the fact of different phases through which you should go with client's team - storming, norming, performing). Be honest - tell them that you don't want to screw up. However you wish to deliver something valuable. Due to the fact that there will be some storming at the beginning of the relationships you should consider something challenging however not really complicated (due to the fact that team performance is lower during storming phase). But it's important to explain that you are not trying to avoid something hard, you just want to produce right expectations. Which means that once this done and we successfully passed storming phase, we can switch to something more complex/complicated/challenging.

17. If you specialize on out-staffing business it's important to have kind of 'incubator' office for pilot project/discovery phases of development. This will be like going to restaurant/movie, having a date with your fiancee before getting married . Both sides should get to know each other in real life situations before serious and long-term relationships.

Great Idea and Zero Execution means = No Income!

Ideas are just multiplier of execution*

Hey Entrepreneurs, are you there? During doing of some routine (wod, driving, cooking, whatever) you definitely juggles a lot of ideas in your head. And yes - some of them are fantastic and could be 1m$ business. But in most cases they have no execution. 

After a while you see an article on techcrunch which describes amazing startup which someone has executed. And yes the idea of it is something you though last month during morning run. You are out of the boat :(

In order to avoid this, please remember Great Idea without Execution means Nothing. 

*Special thanks to Derek Sivers (sivers.org)

The picture was originally taken from http://sivers.org/multiply

How we screwed up or learned lessons

4 Great Ways To Screw Up a Project* 

*based on real life story

We've screwed up! And that is ugly truth, we just did it... Huge start-up with great investments is just closed. 2 years of work went down the drain.

No bla bla bla - just solid analysis what was done wrong!

Immersion in the situation

Project type - product start-up;

Software Development Methodology - Agile, Kanban;

Roles involved in project delivery  - System Architect, Team Leads, Developers, Project Manager, QC Lead, Configuration Manager, Build Engineer, Business Analyst; (Dream Team, isn't it?)

Total amount of people involved- 85;

External teams - ROI team, PR team;

Product lifetime - 2 years;

1st delivery to market - after 1 year of development.  

Why we screwed up:

1. Product idea/information about it  was a TOP secret information.

There was No User Acquisition strategy at all. We thought that we are doing iPhone or second Facebook: once it's done, huge presentation and !BANG here we are - millions of followers and users are already in turn to get an app.

Learned lesson-

if your'e startup which is going to be public service start doing some buzz as sooner as possible. Run facebook, twitter, instagram accounts - spread the information about the problem you are going to solve. Spread the information about how exactly you are going to solve this problem. Share first wireframes/screens in order to get first feedbacks! Don't be afraid to go to your end-users earlier. As much feedbacks you get at early stages than there is a bigger possibility you're doing the right thing in a way needed for your target audience. 

2. Software Development Life Circle (SDLC) - it wasn't agile at all! However everyone was sure that it's exactly agile. From the early begging we've followed SCRUM with 2 weeks sprints. However it was fixed price project. As you already guessed, requirements change was a pain in the neck. Just try to imagine - 6 scrum teams are located in different areas, stakeholdersare located in different areas (6 scrum teams  and stakeholders are located in different areas). And there was actually multinational team. It was a horror movie at early stages! Really painful process to change the requirements. But how startups could leave without changes in requirements from sprint to sprint? Nohow! They appear from time to time and SDLC should be adopted for this. We actually did it, however after almost a year of development.

Learned lessons - 

you're hired as consultant who should actually help customer to achieve his business goals. Don't keep silence if something goes wrong. They would say we need agile development however we need to assign fixed price contract. Is this a service with huge amount of users? Is there direct goto market strategy? Is there already defined ROI strategy?Does problem which software is going to solve exist? Was competitor analysis done? If most of answers to this questions are- NO. Don't be afraid to say to your customer: 'We are not ready to sign fixed-price contract yet. Your idea requires deeper analyzes and investigation. Which we as a consultants are ready to provide. In that case you would take part of responsibilities however chance of success in such approach is much more higher!      

3. Huge amount of Roles/People involved in project development - 85!!! Never do this, except you are doing space shuttle. Try to be small as longer as you can. If you need so much people in order to achieve some goals in some time-frames - two cases are possible: you are building spice shuttle or you have problems with Product Management. That definitely means that you don't know what your users exactly need.

Learned lessons-

Try to be small, simple and straightforward. Try to define what are the main features of the app you build. This should be done taking into account value you're trying to deliver to the market. Problem which your end user has. The best case - you're trying to solve something that  nobody solves. In that case, even if solutions are not perfect, users will forgive you a lot. Because you solve some particular problem which exists. You will never be perfect however there is always a lot of room for improvements. In case you are doing something which already exists - you should do it better than competitors, which is obviously. Otherwise there is no need for your product. 

4.  Technology stack. This one is one of the most important aspects of our fail. We used wrong technologies for front-end. Why? See item #2 in the list. There was no analysis at the early stages of the product development. We thought about one really specific feature for implementation of which SilverLight was the right choice.  That was actually mainstream - this feature assumed to be a main business driver. Unfortunately it wasn't. Just two technologies on front-end were needed: html + javascript (jquery) .

Learned lessons -

Be careful during technology analysis. Migration to another technology stack after certain period of development is expensive and painful! On early stages: Try to define requirements for load, scalability. Take into account requirements for performance and user experiences. Also think about your target audience.  In case your target audience are people above 45 years this means that most of them would use IE and install some third party software(SilverLight or Flash) or some plugins will be a big problem for them. And as a result you will lose your users before they actually try the product. Entry point is - think about people who would go through it and how would they react on different scenarios.  Only after this try to figure out which technologies could help you to achieve this goals.  

I would highly appreciate your feedbacks and comments. It's worth to hear some stories from you. Let's discuss problems you've had! 

BA on startup, Part 3: How to deal with hipster guys?

As I promised before - next part of BA on startup delivered! So part 3 - effective collaboration between BA and UI/UX experts. 

You've got highlevel requirements or detailed specification from the customer, you understand the value which should be delivered to the end user. You also understand why end user needs this functionality. The main question there is- how user should interact with a system in order to get it? That's why - your next step is a brainstorm session with UX expert. 

Main tips in order to achieve most effective collaboration and !results ever:

1. Most of them are bad organized*. You should be a glue between them and other stakeholders.  

*most of UX guys I worked with were not organized at all ;)

Probably for someone that is not critical, but for BAs (I bet) it's really important. We need to have full picture and clear-cutted requirements. Don't try to push on them, just use your best communication/professional skills in order to achieve great results.   

2. Try to have LIVE brainstorm sessions for new functionality - keep arguing.

It's not enough to send a specification and  ask about UI flow. You will never get good solution in such case. Try to use live meetings on early discussion sessions. Try to deliver all needed info for them, once they come up with some solutions try to analyze it and destroy immediately! Why - there definitely will be 'wholes' where logic might not be achieved. Keep arguing, keep generating stupid ideas, keep collaboration - until they wouldn't have questions without answers. Once you get a final approach and there are no white spaces - you did good. You both did good.     

3. Listen carefully to their ideas - probably it's time to change business logic

During brainstorm sessions arguing you might catch yourself thinking that- Hmmm, these guys are right. We add complexity in place where it shouldn't exist. You should re-think logic. If the main value is still achievable, than good compromise is to change business logic in order to make UI/UX more intuitive and simplier. 

BA's - Try to avoid the formality in collaboration with UI/UX team. Forget about processes while interacting with them. Be result oriented as much as you can. Doing this you will get best UX & UI possible for functionality you need.  

P.S. UX experts - sorry for the hipsters analogy. That is how most of people imagine you :) 

BA on startup, Part 2: Meet the Parents

We keep going, and the next episode is about BA and Customer relationships. Your first meeting, your strategy, your communication skills and negotiation. Here we going!

Meet the Parents

You should always remember your first meeting with your boyfriend's/girlfriend's parents. How was it ? Definitely you spent a lot of time considering what to say, how to behave, what to wear, etc. Amazing time, isn't it? However once you've met them - most of you realized that these people are really cute and good-natured. And the only thing they care about are your fillings to their son/daughter. They hope you to be a person who really cares about their child (however that happens only during the first meeting :)

I'm pretty sure You had already done an analysis of stakeholders before you made the first call with a customer. That means you are aware who you are talking to and what is this person responsible for (on the high-level). For most of customers their product is their child and they want to be sure that you as a BA really care about the product. And that is a part of your BA skills - you should care! Not just to make them think that you care but to be really care. You should build really strong/good relationships with a customer - namely relationship of trust. However you must always remember about -

"Even when the project and enterprise goals are aligned, different stakeholder needs may arise. Enterprise and project goals can be accomplished in various ways, and different stakeholders will have different ideas to accomplish them. The BA’s role is to listen very carefully and work to understand each of the different stakeholder issues. The first step in resolving a conflict is to clearly understand both sides. This will often be difficult because you may personally agree with one side and have a difficult time being open minded about the other. Work hard to maintain your neutrality—a BA is Switzerland! If the differing groups have difficulty discussing the issue together because they are emotional or impatient, talk with them individually. Work to really understand their perspectives and their motives. Don’t try to change their minds or convince them of another way until you can completely see their side; use the win-win approach (Covey, 1989)."

 Quote from:'7 steps for mastering Business Analysis'

BA's- you should be a Switzerland, however the Switzerland that really cares. Do everything possible to build strong relationships with customers/stakeholders.
    

BA on startup, Part 1: Don't be an alien

Nice to see you again! I'm going to write a story line about BA's most common problems and ways to solve them on startups. The main idea of this series is providing for you cases from real life with which I faced in my practice. To make an analysis of each problem and suggest the best option to solve.

And the first one story is:

Don't be an Alien. Shave the mustaches! 

The project is going to be started soon. Stuffing is almost done. Most of the team is already defined. Time to introduce the roles. And PM says - 'So team, please welcome our business analyst!' Once everyone hears that we're going to have a Business Analyst on the project, they examine you as an Alien, an Alien with mustaches. 

Known situation isn't it?

Most of dev team can't even realize what is your responsibilities are, on which side you are (customer or team), will you control them or think how this guy can help us? And that is truth. You are an Alien for them and this Alien has mustaches. It's clear why an Alien, however why mustaches? The reason is a role name "Business Analyst". For most people it sounds 'official' and probably 'frightful'- and I think that mustaches is an attribute of 'formality'. 

First of all remove this layout of formality between you and the team - Shave the Mustaches! The best way for this is a presentation of requirements management plan. I think that it is first thing with which each Business Analyst should start. Try to avoid formality on this presentation. Do not show a lot of diagrams, complicated flows of interaction. Focus on people who are listening to you. Analyze target audience. For most cases everything they need to hear is who you are and how you can help them. Let them know that you are a normal guy, and your goal is to help them in understanding of customers needs. That is the best chance to Shave your Mustaches. 

So the mustaches are shaved however you still an Alien for most of them. Team perceives you as a person who is responsible for all project activities (I was surprised to realize that on some of my projects). And that is a main problem - they may ask you about anything and more important thing, that they expect to get answers from you. Never say - that is not a part of my job. Try to figure out who (if you are not able to solve this problem) might help them and forward the question to appropriate team member. You know process, project life circle, main stakeholders, etc best! You are Business Analyst and you know how effectively collaborate, communicate and interact - help other team members on early project stages. Doing this you will bridge the gap. And an alien will become an insider!

After all this team see you as - 

However without mustaches. Awesome movie, isn't it? Exactly dialog with this guy (Office Space).

BA's - try to bridge the gap between you and team on early project stages. Do not avoid any assistance which teammates might require from you. You are the Business Analyst and you know how effectively collaborate, communicate and interact. You know processes, project life circle, main stakeholders best. That is your chance to shave a mustaches and become an insider!   

Links:

1.http://www.thousandtyone.com/blog/BusinessAnalystsAndTheMillionDollarQuestionWhatWouldYouSayYouDoHere.aspx;

2. http://blogs.orlandosentinel.com/.a/6a00d83451c3cb69e20120a605f1c7970b-popup

Good BA / Bad BA

Let's imagine you came to MCDonald's, and you think that you really want a 

Big Mac! 

You went to cashier and got from him:

MC - Hello, what would you like to order?

You - Hmmm, I think I would like to have a Big Mac

....

That is your own decision. What pushed you to make it? You saw an Ad of Big Mac, description of Big Mac (from what it is made of, nutrition facts), picture of Big Mac, etc. So in order to make a decision you as a customer had all needed info.

....

MC - Anything else? Coke? French fries?

You - No, I think that is enough for me.Yeah, I'm good.

MC - 10$, please;

MC- Here is your Big Mac, Enjoy your meals!

....

10 min later. You've tried a Big Mac, however - You are not satisfied with it. Now you realize that you wanted nuggets. And yes - with Coke and fries would be really cool! So what is the root of problem? You've got all needed info to make a right choise. If cashier would be a BA, you would got a nuggets with Coke and Fries. Let's see -

....

MC- Hello, what would you like to order?

You - Hmmm, I think I would like to have a Big Mac.

MC *!He is not sure*- So Big Mac is - The Two all-beef patties, special sauce, lettuce, cheese, pickles, onions - all on a sesame seed bun. 

You -Hmmm. So it's just a sandwich. And with beef.

MC - Maybe you want to try nuggets? They are awesome!  It's a small piece of fine ground white meat chicken that is fried in batter and flash frozen. you can also choose wide range of souses.

You - So it's fried peaces of chicken? 

MC- yes.

You - Yeah, I wish to try it.

MC- Anything else? 

You - Nope, that is it.

MC- Soft drinks? French fries? Trust me, I don't want to sell you more. I just 100% sure without soda and fries you wouldn't be so satisfied :)

You - Ok.... That makes sense. 

MC- 17$

MC- Here is you chicken nuggets, Coke, french fries. Enjoy your meals! 

You - Thank you!   

 ....

15 min later. You've tried all these. And you are really satisfied. You get exactly what you wanted. However you had some assumptions about what to buy. But you wasn't sure about your choice. And most important here - cashier realized that you are not sure. Cashier tried to give you some options with kind of feedback from person that tried such kind of food set.

....

So BA's -  in order to be a good BA - you shouldn't always give customers what they are asking you for. The main difference between good and bad BA - good one tries to realize customer real needs, provide with different options and pros/cons of each option. That is not enough to be just a liaison between dev team and customer! Think widely, there is no value if devs would deliver exactly what customer needs in time/budget, if it useless and no one needs this.

You can actually do the same in order to be a good cashier :)