Delivery best practices – Pre-sales

It’s a hard decision for a company to turn to sub-contracting. Having realized that they don’t have in-house expertise and don’t want to/can’t staff the new development properly, they turn to another company that they have probably never worked with. The lack of trust is tangible from Day 0. They have the business plan secured, write the tender, requesting for company information (RFI), asking for delivery proposals (RFP), reviewing them, making a decision carefully.

Let’s now examine the other side!

A common approach

The very first thing you can do is gathering enough information to give an insightful proposal. You’ve got to learn a lot of things and must thus study your future client:

• Read about their background,
• Check latest news about them,
• Learn about their leaders,
• See who are the people you’d be potentially working with,
• Which technologies are used,
• Etc

One may ask how the last one can be done: you’d be surprised how much information can be retrieved simply by e.g. visiting a web site. When I did this the last time, for example, I could find traces about used front-end and back-end technologies, CRM system (including marketing), analytics, integration with social networks, user management, security methods, etc. This will help a lot to find the constraints you must be operating within in your proposal and on the project later on.

There’s usually a chance to ask questions and get answers from the client, either in written or on a conf call. Sometimes these calls are exclusive with the client, other times you’re together with other tendering companies listening to each others’ questions and the answers provided. You must focus on the top 5-10 most important questions to ask that are really crucial for your proposal – otherwise you’re wasting a precious opportunity and may also look less professional.

Get aligned internally in the organisation before finalizing the proposal. Don’t win for your bonus/promotion only and then vanish when the project starts saying …

I saw projects where the sales did like this, leaving the account manager and the rest of the team in a massive trouble. Ultimately, these folks should also be accountable for the success of the project to some extent, no? Perhaps, even financially.

Make sure the knowledge transfer from pre-sales to delivery is as efficient as possible. Lot of organisations have an A-team specialized in making proposals and the actual delivery is done by another team. I’ve already seen clients so much impressed by the “A-team” and deeply disappointed by what was following afterwards. Having different teams specialized in different areas is not the problem per se, provided they’re both competent and aligned – latter should follow from the former, actually.

The proposal will probably describe:

• Identified needs, stakeholders in question,
• The solution and how it satisfies the needs,
• Team structure,
• Schedule with dependencies,
• Cost breakdown,
• Etc.

It’s easy to forget about the following two topics, however: risks and assumptions. They both reveal more context beyond the afore-mentioned major areas, make the overall picture more complete. Also, they may become important arguments in your hands, when things are turning to serious. Don’t think, though, that merely calling out risks and assumptions will solve problems automagically – ignoring or forgetting about them will just hurt back on both sides.

Sometimes (often?) tendering companies don’t possess deep domain knowledge – they may just have technical people (e.g. developers) or developed a general-purpose product that now needs to be customized to a specific need. In any case, we should all calculate with a learning curve at the beginning of the project, when making/evaluating proposals.

Did I miss anything? I’m sure I did. Above list is just a collection of best practices that one may not find easily anywhere around. Please share your hints, they’re more than welcome!

This article is part of the series of related posts about delivery best practices. You may find other useful hints at https://gabortorok.wordpress.com/2019/10/08/delivery-best-practices-proven-methods-for-it-project-delivery/.

Best,

Gabor

About humility

I participated in a conference over the weekend that EPAM arranges twice a year, this time in Budapest, Hungary. This is an engineering conference, which we call SEC, a short for software engineering conference. Even though, as we like to say,

engineering is in our DNA

we speak more and more about topics that are not strictly about engineering, such as delivery management, user experience design, etc. Which is good and understandable given the trend of EPAM having stronger and stronger foothold on areas typically creative agencies and consultancy companies excel in.

I’d like to talk a little on the last presentation of the day that, I must admit, I expected the least of. It was given by William Benko, a Hungarian speaker whom I had never heard of previously. He’s not even from IT, had no idea why he was there at all. But as soon as the presentation started I soon understood it and to my biggest surprise the essence of what he spoke of still resonates with me very well. Basically, he built a presentation around three words: smart, hunger and humility, which he talked about through a few examples, all completely unrelated to IT. The message of his presentation was like if you combine humility with [wanting to become] smart and hunger [for success] one can make the most beautiful impact – may sound like a cliche, but so true.

The very reason for this blog post is not about smart or hunger, which should come natural in our profession. But as for humility, it’s not something we talk about quite often. Unfortunately. You know, no matter who you work with, what you work on, we’re all human. As such, it’s irrelevant how smart you are, if you’re higher ranked in the org chart, whether you’re a teacher or a student … stay humble. If you’re right, that’s why, if you’re not, that’s why. Not just because “you’ll get what you give“, but simply because giving respect to the other doesn’t cost a dime, but it immediately pays off: you feel better as well as your relationship with the others will be more and more built on trust. Even though our wishes and aspirations may be quite different, the need for being treated as a human is equal and not related to any profession. It starts with as little things as waiting until the other finishes the sentence, through feeling empathy with each other to not telling the other off or yelling at them. And the list goes on, of course. For example, I was once told by one of my teachers that the strongest people show their muscles the least. This is quite a visual example, but I quickly understood its second meaning, too.

EPAM is in the services business, which means we help other companies to build their own products, solutions. We continuously strive to win new deals with clients we have never worked with, which means we must build trust from scratch very-very often. In another presentation, which was a panel of senior delivery managers sharing lessons learned, one of the panelists said:

At the end of the day people work with people, humans with humans.

Sounds like a cliche, but it can’t be said enough times. It was kind of a coincidence that these guys talked about the same thing, but i’m so happy it happened. The importance of mutual respect must never be under-estimated and forgotten about.

Let’s be smarter, stay hungry, but above all: be humble.

Gabor

Cost of overtime

"We just need to work long hours and the feature will be ready."

"Can you drink a few more coffee to finish this task?"

"I don't care how much work it takes for them, they promised this."

 

Hi,

Have you ever heard similar sentences like the ones above? The more I hear them the more convinced I am that people saying them are not fully aware of the consequences of their request.

I’m sure many are familiar with the following diagram.

*courtesy of Price Systems

When doing any sort of delivery, fix all three of scope, cost, time and you’ll probably face with huge issues later on. Put it in other words, if you fix two of these three factors, leave the third flexible to avoid major risk:

• If you fix cost and time (“it must be delivered by date X and shall not cost more than Y”), let’s leave the scope flexible and focus on an MVP (Minimum Viable Product) first.
• If you fix cost and scope (“all of this functionality must be delivered for up to this amount of money”), let’s be less strict as to the deadline of delivery.
• If you fix scope and time (“this must be delivered by date X”), let’s cost be the moving part.

This is kind of the basics of project management. Experience shows, however, that there’s a fourth factor that is correlated to ALL of the afore-mentioned aspects: it’s quality.

*courtesy of Steve Draper

Above diagram tells that you may be as restrictive with scope, time and cost as you wish, it will surely affect the quality of the deliverable.

But let’s stick to the topic of overtime. A team will do overtime if at least time (from above factors) is fixed and delivery must be accelerated. Quite often, other factors are also fixed, most typically cost, but it’s not rare to see all three being fixed. The effect of overtime seems quite intangible, it’s kind of hardly measurable. This gives the illusion to some that it doesn’t exist at all. Sadly, it does. Overtime may work short-term, it may even bring the desired quality, but it will surely not work long-term. And for long-term, we don’t have to go farther than a few months. Couple of thoughts:

• When people do overtime, they get exhausted. They may recover successfully short-term, but chances are they won’t long-term.
• When exhausted, they make mistakes. The more overtime they do, the less productive they will be: their overall delivery speed will decrease, the chance they make mistakes increases.
• When exhausted, they become less tolerant to stress. Being less stress-tolerant, they’re less motivated. Being less motivated increases attrition. Becoming famous of attrition makes your project infamous, more difficult to staff, i.e. more costly.

A Product Owner must never underestimate the cost of overtime. They might win a short-term gain, but it comes at a price. Eventually more features will be delivered by the set deadline, but quality will suffer. The end users will use features with bugs, which hurts conversion, retention, lead generation and it may lead to churn. Now THAT is the price of overtime.

Product Managers must notice overtime as it’s clearly the sign of wrong assumptions, estimations, expectations. This is the time, when agile delivery comes in handy: find the root cause of overtime and fix it before issues pile up. But even if the delivery method is not agile, risk and change management are very powerful tools here. Continuous risk management helps to monitor issues coming up, classify them and find proper mitigation actions. Change management, on the other hand, helps to schedule these actions, adjust plans, allocate time and resources and in general keep delivery at a healthy level.

The delivery team and the Product Manager are all part of the same team, they share success and failure alike. They must work in symbiosis, depending mutually on one another. That’s why their sustainable good performance is key to success.

Any thoughts?

Gabor