Customers, Digital transformation, Entrepeneurship, Innovation, Practical examples

Don’t know where to start using design in your digital products? Here’s a suggestion

January 3, 2020

Design is one of the base investments for digital products in many industries (DMI 2015; Gartner 2018; McKinsey 2019). It should be used to foundations like understanding your customers and putting him at the center of your plans, and also on the other edge to help you find differentiators. As a continuation of the article from Jan 2019, this article describes some achievements some clients had during 2019 after a simple first step: mapping the user journey.

$150k savings with IVR

$150.000,00 yearly savings after micro changes to the IVR (Interactive Voice Response) of a bank. The exciting part here is that a very short user journey mapping process achieved it. It all started with the standard order to reduce costs on the chain. A UX Researcher was designated to make an evaluation of the entire set of channels used to communicate with the client.

During the first week of work, he noticed some reports on the IVR records shown that around 25% of calls redirected to a support position were regular questions like “what is my balance?”, “what is my pre-approved credit limit for a new car?” and “where is the closest branch in my neighborhood”? This scenario is one of the shortest journeys we can draw for a user: he just wanted to know his balance! The main pain point for the phone channel was that he was taking more than 2 minutes to do so. But there was also an opportunity to optimize costs.

The UX Researcher knew those topics should be answered without needing a human anymore. He delayed his initial researches and told the story to leadership. After a week of work, he and a developer were able to address two critical questions from clients on the IVR. They pulled questions that would be redirected to a human to answer down to the automatized services. 

Decreasing around 25% of the need for a human to attend a call at that time has been saving $150k/year.

15% more sales after remodeling one node in the supply chain

This one goes the other edge in the complexity of changes in the process after journey mapping. Another client, which works with heavy machinery for farmers, found out that one of the pain points for them to upsell more was the bureaucracy of their field representatives. The farmers wanted to buy from their upsell strategies because those products were directly related to more productivity and more profit.

But the pain point was that the representatives were slow in crucial activities of the chain: purchase and delivery processes. The purchase and delivery used to depend on much manual work involving taking the machine to a different facility to receive the software upgrade.

As an output of the journey mapping, entirely new software is now working and replaced the many old ones. This new system allows the farmers to buy the upgrades way faster than before, just like in e-commerce. The delivery happens at the same time they buy, counting the machine is connected to the internet.

The light start

As the examples above show, mapping the journey of your user is an exciting way to start using design thinking methodologies in your company. After mapping the journey, many other tools may come like: workshops, more research, data analysis, prototyping, drawing screens, etc.

Avoiding problems, Customers, Practical examples

Coding is the easy part

December 30, 2019

I realized I often tell this sentence whenever I’m internally coaching my colleagues in the company. But what does it really matter? Of course, coding is not easy, otherwise, anyone could do it. But what about the soft skills? As soon as you get more experience in a developer role, more responsibility comes. The new responsibility will pass through talking to other people for sure. This is when things start getting difficult.

Internal discussions/guidance

Let’s say you are a senior developer and is also one of the tech leaders in the company. You also want to help other people’s careers to evolve. Then you start helping to develop the junior guys on technical skills. This is simple: make them do hundreds of POCs, demos, exercises and etc, and have the concepts in mind. No matter how long it takes, it’d be easy to see if that person is making progress or not. It is zero or one. They either did or didn’t. Simple.

During the same path described above, you will notice some behavioral soft skills needed for that junior guy. I’ll try to help with some questions to ask yourself:

  • Do they behave properly in meetings?
  • Do they stand his point? But also be flexible to listen to other people’s opinions?
  • Do they listen to other people? Listening is more than hearing
  • Are they humble when talking about his accomplishments?
  • Are they humble when talking to other people?
  • Does the team like them? Is he a pal?
  • Do they stand like a person or do they easily compromise for almost anybody else’s opinion?
  • Are they open to discuss feedback?

External relations

In IT we are always providing service. Doesn’t matter if your clients are internal or external, you are providing a service. This is the most complicated and the one I see always as the source of problems in all projects.

Everything starts like a heaven relationship, but eventually, somebody will miss something in the process. The other part will try to help and will accumulate that load of work. The load will be like a pile and eventually will fall. These are the crisis we solve every day and those soft skills are so needed. Some questions to help thinking:

  • When talking to clients, does your mentee listen? 
  • Does he clearly know the boundaries of everybody’s work?
  • Does he understand how to tell people to do stuff without being arrogant? (Serious)
  • Does he think he’s better than the clients? (Serious)
  • Does he have a posture of helping people to solve problems instead of trying to be the center of everything?
  • Is he a problem solver or a procrastinator?
  • Can he understand the difference between problems, and solve those more important first no matter their size?

Process boundaries

For my experience managing several projects in many methodologies to develop software, I can tell that roles are often overlapped and misunderstood. It is someone’s responsibility to perform a task. Like in a volleyball game, if nobody puts the ball up, it will fall. Many balls falling and a new crisis arises.

Sometimes telling the other side they have to do something or they didn’t do something is the hardest part. But is also the most important. And in fact, the hardest part is bringing the problem, show the owners and how to fix it in a way it doesn’t occur again. But everything in a way that the final result will be a bonded relationship. On the time you give the news, arguments may happen and people might leave feeling bad. But once everybody cools down and recognize the good for the process and the final goal, since you passed the message in the right way (not being arrogant, not just throwing the problem to the other side but in fact bringing and discussing also the solution) people usually have the maturity to reunite and keep working together. Here are the questions for this topic, but now for both the mentor and the mentee:

  • Are you backing up your coachees/mentees when they have to have hard conversations?
  • Do you encourage them to have those moments?
  • Do they have the moments? Or do they run from it expecting you to solve their situations?
  • Do they prepare themselves for the moment prior to it?
  • Do they talk to people to get other opinions on how to deal with the hard moment before going for it?

All the items above are part of a developer regular work. They are very hard to develop and also take time. None of them are related to code.

Career, Practical examples

6 steps for the best feedback you’ll ever give

November 19, 2019

After some years leading IT teams and dealing with many different scenarios, I’ve been refining the techniques for giving a good feedback. A good feedback session usually has just the last 4 steps written here.

But something happened last week and made me add two obvious steps that are often forgotten before the actual feedback session. Just because giving good feedback is way easier, here I present the steps to give feedback when you need to talk about behavior, a mistake, or even to have a regular talk to help somebody with their career progress.

1 – Build trust

A trustworthy environment is the base for a good feedback moment. There’s an exchange between the one who gives and the one who receives feedback. Who gives it learns and gets experience. Pretty often understands how and why things are going the way they are going, and then has the opportunity to adapt and evolve together (this is part of the leader mission btw). The one who receives the feedback is thirsty for evolution and progress on their career. Usually seeks feedback for improvement constantly. But what if they don’t trust each other? Who gives feedback gets afraid of self-exposure. Fears not being enough to make things happen and help to develop the other side. And who receives feedback easily dives into an ego that will make the suggestion for improvement sound something unreal.

The trust between the two parts is crucial. Do you have trust within your team? Is talking to each one of your team individually part of your routine? Do you enjoy to stay together? Does your team come to ask you a point of view or advice when something goes wrong? Do you back them up when things go wrong or do you expose them? Do you feel like you accomplish stuff together? If the answer is no to a few of the questions, my guess is you don’t have a trustworthy environment.

2 – Set the goal

Since now you have trust, it’s time to together plan how far, how, and why the feedback receiver wants to go. What do they aim? This is the core of what will motivate them. The side missions can be something close to the goal, but the big missions must always be something clearly pointing to the individual goal. As a leader, it’s your duty to understand even if the individual will evolve more with another leader than would with you.

The key to this step is to always have a plan to follow. There is always stuff to be improved. What are the short, mid and long term goals for the one you are giving feedback? Does the feedback make sense when compared to the goals? Once you have the macro plan, SMART activities might help people see progress happening, depending on the team you are leading.

3 – Start with a good point

Ready for the real feedback moment? Why should you start telling something good? Starting by mentioning something the individual does well is a good way to start and to create empathy. You will be showing you recognize the good job being done besides the feedback you are about to give. It will increase the chances of the feedback to be received in a positive way, deeply understood and connected with real scenarios to help you explore the subject even more than what was planned.

4 – Show the FACT

Just show the fact. What happened? Was it a bad posture during a meeting? Was it a delayed task? Did they offend a colleague? Show the problem without judging. Do not make comments about what happened. Just say what has to be said looking in the eyes. It’s something important and has to be understood as a message. Straight.

The fact cannot be something you suspect. If you are not sure, it might be unfair. If you suspect and it’s a reality in your team, just pay more attention and you will see the thing happening. Go back to step 1 and get closer to your team if you don’t see it.

It cannot be something somebody told you. If you go for this way, there’s a huge risk of creating an environment of gossip. And then you’re back to the 70’s leadership style.

5 – Show the impact

Often people who commit mistakes don’t see or don’t want to see the impact. People don’t want to be seen as they are pulling the performance down. Why was the goal, delivery or whatever compromised by the FACT?

Was the fact a lack of commitment? The impact can be the delayed delivery and a bad relationship with your client (internal or external).

Was the fact an argument during a meeting? The impact can be damage to the team relationship.

6 – Build the action plan

You can create the action plan once the fact and impact are understood. What will prevent the same thing to happen once again? What happens if the situation occurs again?

For the action plan, you have to set SMART (specific, measurable, achievable, relevant and time-framed) goals. When you will check again if the issue was solved? If it’s not solved, another feedback session will occur, but if it was solved, it’s important to note and recognize the progress made.

Practical examples

The 2 main challenges of managing a project 5.1 thousand miles distant

October 27, 2019

Recently I finished managing a project 5100 miles distant and all I can say is that I learned a lot. The team I managed directly had 9 people for some time and finished with 6. I’m sharing here two of the biggest challenges I faced during the project and how we overcame them.

1. Language

Part of the team, which lives in Porto Alegre, speaks Portuguese as their native language. We speak English as well, but it’s not the same as a native language. The rest of the team, speaking English, were 5.1 miles distant.

Portuguese is a broad language, and English is way more straight to the point. Also, culture and context make a difference. Using Portuguese, it’s natural to talk about a point without reaching the point itself (using passive voice). If you want to say no for something, you can say no without using the word “no”. This is one of the traps I fell inadvertently.

Sometimes I even realized a bit of an ego holding part of the team to ask questions. I could tell they were not 100% sure of what somebody told but they wouldn’t ask to make the information clearer. It’s something small, but all the points not understood 100% eventually had to be clarified and time was lost. Sometimes bad decisions were taken and rework was the consequence.

The language is a barrier. We cannot avoid it. Ideas and complex scenarios are tougher to explain.

2. Sense of lack of communication

During the project, I kept conducting regular ceremonies for communication, but I was always feeling a lack of communication. Sometimes I thought the team should have more autonomy to reach the client more often, without relying on me as a proxy (bad practice found here). We tried and started to improve. It did start to work from the 7th month on.

At the end of the project, we traveled to the client headquarters to validate the system faster than we were doing. This trip was crucial to creating a good relationship with the entire team. It decreased dependency on key stakeholders and it was easier to see each one’s potential.

What were the problems and how we overcame them

For practical activities, it’s hard to split the language and the lack of communication because they often seem to be the same. They are not. How did we overcome these two challenges were the most important part:

Language

Naturally, team skills in English improved. In just those few months of the project, it was not enough to have everybody’s English on the state of art. But we improved. The week we spent on the customer headquarters was also a divisor in terms of language. All the team got to understand better each other also considering the different cultures.

Communication

Status report

since we had a mix of waterfall and agile practices, the status reports were part of the plan. Few of them were sent. Many of them were missed. What makes me sad here is that they were missed. What makes me happy is that nobody missed them. They were just a group of information being discussed daily. Different formats of “status reports” could have been used. At the end of the project few short and summarised emails were used for the same intent. Both had the same impact.

Daily meetings

We started with daily meetings. They worked just in terms of high-level catch-up. The big mistake here was not having the business representatives on them. From the middle of the project on, the daily meetings were just a quick and superficial report of what people were doing. No one was actually taking care of the project using the daily meetings. From a business and practical standpoint, they could have stopped at some point and not much would have changed. Besides, they were important to create a team and a collaborative environment.

Emails

It’s unbelievable how easy it is to fall into the trap of sending an email and throwing an invisible package of things to solve to the other side of the wall. We made this mistake. And the team fixed it as soon as it realized the emails were actually creating friction instead of solving problems. We didn’t stop to send emails. But we stopped using them isolated and always had a quick catch up meeting parallels.

Bi-weekly demos

The demos happened always as planned. The good and bad part is that they created a lot of discussions about what was being delivered. They were bad because highlighted our lack of alignment in terms of business decisions many times. But they were also good because highlighted our lack of alignment in terms of business decisions many times. Then after the demos, the project used to have new turns to put the requirements back on trails.

By demand meetings

Every time we had meetings, we found solutions for the problems. No exceptions. Every time we got to talk, we solved problems. The meetings that started to happen after some business decisions lack of alignment were crucial for the project’s success. Here I’m talking about both long meetings to detail requirements and short meetings to synchronize small decisions.

I shared some of my key learnings in this project. I hope it helps you guys in similar scenarios to overcome your current project challenges.

Entrepeneurship, Innovation

UX is the new black

October 27, 2019

Annually, Gartner presents its most recent findings during the October event in Orlando. During a financial panel last week, the thing that impacted me the most was the UX topic being discussed in 2019 (actually just one year after being introduced) in a more than natural way. That sounded like “what are you doing in financial if you don’t have UX as a base in your strategy?”. The analyst didn’t even dive in to show more numbers and companies that adopted. It was so easy for the message to go out.

The event

Gartner introduced the big concept called “embrace the power of the AND”. In the same event, they present technology trends and industry standards for a selection of around 10 industries. In past years I’ve been attending this, which is the biggest gathering of IT executives in the entire world, and you can find some videos on this LinkedIn page with a few of the content shared.

UX subject

Just a recap about UX here: we are close to 2020 and just a few banks around the world actually invest and have UX as a key point of their strategy. Even inside Gartner, it’s something new. The UX subject appeared for the first time in Gartner’s agenda as one of the main topics for the event just in 2018.

This term and practice/focus started to get stronger and stronger on software recently. UX is all about understanding how your customer behaves, understanding his needs, trying to solve their issues as quickly as possible and give a memorable and delighting experience. It can’t cover just the software. A good experience floats over all the channels you interact with a brand. If you have to give them a call, the support must be delightful. Or using an app, same way. For physical interactions on the brand store (or branch for banks, or any other facility), also chatbots, and everything else must be remarkable.

Wasn’t that supposed to be basic?

But isn’t it basic? If a cosmetics company wants to release a new perfume… Don’t they go to the field, understand how people feel about the existing ones, what is their opinion, test, retest, discard something eventually, and then they launch. When a new toy is launched, doesn’t it goes under the same process? But what about software? Why do we still have initiatives, led by few heads inside companies that believe (for real) they already know everything their user needs and how to solve it?

Doesn’t it sound crazy to create a new product (software) without asking people at least what and how would they solve the problem before anything?

The analyst approached the UX subject in such a natural way that it made me feel good! He stimulated the thought of if you are in the financial industry is unacceptable to start any initiatives without looking for UX. Good! We are heading the right way. We will get there eventually! But what about the other industries? Their time will come. No doubts.

Avoiding problems, Practical examples

Software architecture to scale business

August 25, 2019

Software is present in every organization that wants to grow at some scale. The software helps the company’s employees to be more productive and to reduce manual and repetitive works. The software can have the best possible interface, turned 100% to people productiveness, but as a basic item, it must work when it must work. When vital software to an organization fails, the difference between regular software and good software is discovered. And here I talk about its architecture.

When the architecture makes the difference

To talk about this subject, I’ll cite two real cases of two clients in the media area. They are close to me and had their business growth held for some while due to bad quality software.

Please, no more load

The mentioned software was a portal to Brazillian population access to a known TV show. With that portal, people used to register themselves to be part of the TV shows, donate money for good causes, interact with their favorite characters, and some other activities. Under normal circumstances, the portal used to handle everything. But when one of its TV presenters mentioned something about the portal when they were live in national network, it was deadly. We just had to count time and few minutes after, the portal was down. It could be simple stuff like saying live “access our website for a chance of winning a prize”. Or “access our website to talk to the actress X”. And the problem that repeatedly happened, taking the portal down, was a technical problem related to its architecture. It was not prepared to receive so many access like it did in fact. In this example, we see a powerful trigger to an entire population being wasted because of a software malfunction. The population (customers) already convinced to look for something, was frustrated with the malfunction and lost interest automatically. The TV show image was affected negatively, and he failed at enhancing its brand, increasing its overall engaged public and eventually losing some revenue.

Let’s integrate!

The second example is about a scenario when the software was a big aggregator of information coming from many different sources. It was responsible for some important transactions related to the company invoices. It operated fine for many months after its first release. But when the database went over some load, it started to behave slower than it used to. Also, a big project or renewing the entire UI was undergoing. But it would be a big failure if something beautiful was released without actually working. The loading screens were too slow and were forcing the user to wait for many seconds for some feedback. The impact on business was quite relevant because the selling process for a few of their products was also affected.

Solutions and business relief

For both of the scenarios, a new architecture was implemented. The first one focused heavily on caching. The second focused on shortening the times to get information. But both passed by a deep architecture remodeling.

Nowadays the first one counts with millions of users reaching their portal to interact with the brand. They also count with a stable portal, which allows the decision-makers to make wiser decisions than when they were under pressure. The second was able to release the new UI, which enhanced the relationship with B2B demanding customers, and no more transactions are lost. Now the roadmap is welcome again.

Entrepeneurship, Innovation, IT is business

Have you already tried to buy software per sprint?

June 28, 2019

Lack of understanding of business by IT and of IT by businesses may still be one of the main issues when building software. 

Main issues on buying fixed scope/price software

The main common thoughts when somebody starts to think about creating some software is that it will be something similar to any other stuff we buy. How much will it cost? And how many time will it take to be done?

I’m trying to demystify the bad comparison between building a house and building software that commonly takes places during these conversations.

Software is a baby

We tend to think that building software is similar to building a house or a tower. But this parallel/analogy is impossible nowadays. For centuries, houses have been built and the process has reached a maturity that it’s possible to put all the information in 2 or 10 blueprints, and everything the buyer said he wants will be there well described.

Softwares have been created for less than 100 years (since the 1950s) and until today there is no way to put all the information on a document that can be followed from the very beginning to the end. Invariably, the documents have a macro vision of what is wanted with the pages described. But, as an example, what should happen when I hit the button “notify user”? Does it send an email to one user? Or does it triggers a background processing involving AI looking for all the users that match the current data and send them a push notification on their phones?

PMI addresses this scenario writing huge documentations with plenty of details following the PMBOK. But only some software have this level of detail. For the entire rest (the biggest majority I’ve seen during 10 years on IT) companies can’t afford the investment for having this level of detail.

Different complexities

Back to the analogy of houses. When you are building a house, the level you reach when designing the architecture (similar to the requirements document in software) will be the walls, plumbing, electricity, network and etc. But at that level, you don’t describe how the house will be decorated (the UI on software). How many paintings will be there? Which will be your sofa? How many inches will have your TV? Your kid’s room will be Superman or Batman’s?

Obviously, this is not described because people will have different opinions on how to decorate the house. And these opinions change from time to time. When talking about software, sometimes these UI behaviors are just not described at the level they should be.

The migration to agile

Given the scenario above and after severe issues developing software, eventually, companies start the migration to agile. Currently agile is the fastest approach to address the issues that come when a scope is not clear/detailed enough. Gartner (ID #G00325642) says that the main barriers for the change from fixed scope / fixed price to agile are:

  1. Sourcing and finance:
    • Sourcing: It’s hard to tell how much the software will cost. In organizations structured like having a hard sourcing process, this will be one of the main challenges.
    • Finance: the organizations have their financial operations structured as price per project. Budgeting for treating the software as a product instead of a project can be complex in some organizations;
  2. People’s routine adaptability / culture / mindset:
    • Be prepared to face challenges on people behavior when migrating to agile. It’s a new way to work, and everything new creates resistance.
    • As one of the key features of agile development, the ability to adapt your software alongside its development is essential. When applied to organizations changing, some issues will arise:
      • Since the scope can be changed at any time, people may fall on the trap of keep trying to reach perfection on some requirement and spend too much time on it, instead of moving to next requirements, making the entire cycle slower.
      • In some times, it’s easy to lose the UX pattern, as the features that have already been delivered may have functional or design differences from the next ones;
      • Managing people will have different KPIs to measure performance and quality. Finding the right ones to your project won’t be quick;A

A hybrid approach

The more flexible the scope is, the bigger the risk is for the client. The more fixed the scope is, the bigger is the risk for the vendor.

A good hybrid model between fixed scope and 100% agile can be the purchase per sprint/phase (Gartner, 2017 – ID #G00325642). You will need a big picture of the project to use this model. Starting from an initial internal estimate of price and time, the client will be able to go for the market and call vendors to produce the software. The software production will be done sprint per sprint. Every new sprint beginning has a new deal. What will be inside this deal is:

Anatomy of a per sprint deal:

  • Start and end dates (2, 3 or 4 weeks are good to start);
  • Price for the sprint;
  • The stories to be delivered;
    • Every story must have a clear DoD (Definition of Done);
    • Every story must be detailed enough for the team to work on without blocks.

For this model to work, the product owner has to have the autonomy to sign. This cannot involve an entire cycle of procurement.

The benefits

Developing projects per sprint puts the risk balance somewhere closer to the center. And here I list some key important outcomes of the change: 

  • For the client:
    • They can stop the work whenever they want without long term contractual strings;
    • The client will be able to apply new business decisions whenever he wants;
    • The client will be able to respond quickly to market and competitors changes, without having to wait for the current project to finish and then start an entire negotiation once again;
    • If something is delayed from one sprint, it will be the vendor’s responsibility to solve without generating new costs;
  • For the product (software):
    • One of the key benefits of flexibility is the possibility to involve more people that are experts in some specific process. Then the product will fit better what the users want, and not what a group of people (like the old project manager and system analysts) think they want;
    • The product will be flexible to respond fast to business decisions and users feedbacks;
    • Practices focused on finding innovation can be turned into a routine. Running design sprints, inceptions, usability testing, and user interviews are some key practices that would be done without affecting the project continuation;
  • For the vendor:
    • The vendor will have clearer information to work with. Less double understanding of requirements will happen;
    • The vendor will have more flexibility to turn into more like a consultant, bringing knowledge from many different projects. Both technical practices and business decisions will benefit;
Avoiding problems, Practical examples

4 Minimum artifacts for an IT cascade-agile project conduction

June 2, 2019

Whenever we are running an IT project, if we already have a deadline set before the start, no matter what, this project will turn into more a cascade than an agile conduction. Besides this status report, I’m listing the minimum artifacts to have a successful project being delivered.

The scope

The scope is basic. It is the base for everything to come. You will extract everything from the scope: the schedule itself, the pace you have to go to keep the schedule, and the team to reach everything. The key information that must be in scope are:

  • The requirement list;
  • The details of each requirement;
  • For who is that requirement applicable?
  • Who has validated the details?

Optional:

  • The time estimates to reach that deliverable;
  • Who is needed to perform the technical part (strong dependencies only);

You don’t have to hold the fanciest document. You just have to hold a document that everybody involved can understand. I’m suggesting this document model.

The schedule

As soon as you have the scope, you will be able to start taking operational decisions. What are the restrictions you have for your schedule? What team is enough for you to reach the given deadline? Can you beat it earlier than planned? Always plan to finish the project before your schedule says, and keep some margin for the problems to come.

The key information that must be in your schedule is:

  • When will you deliver each requirement;

That’s enough. I strongly disagree with going anywhere beyond this point. Otherwise, the project manager will dive to an endless cycle of micro controlling everything. Issues will come with simple or complex documents. Go ahead and create your own model. List the requirement and the date to be delivered;

The status reports

The status report is a weapon and should be used wisely. It can be used to mark milestones for the project and also to create a sense of urgency for some scenarios. It is a powerful weapon. Do not avoid using it. Here you can find the model I’ve been evolving for years. Some of the key inputs:

  • What changed from last status report to this new one?
  • Who are the responsible people for taking decisions on this project? At least one on the delivery team and other on the client (internal or external) team;
  • Where are we in the schedule? Do use percentage here.
  • Major executive items (green/yellow/red) like scope, people and schedule;

Still in the status report. Always remember: if people are asking you for a status report, it means a huge problem. Not sending or wanting it, but the act of asking for it. If they ask for an email to get to know how the project is going on, it automatically means they are not involved as should be on the project. If the status report is green, everybody knows it. Or if the status report will have bad news, everybody must already be feeling the bad news.

The scope changes

Since you are running a cascade project, be prepared for scope changes. I haven’t seen a single project where they didn’t happen. When I hear a scope change, I know I’m walking the wrong way. But it makes me happy because I’ll have the opportunity to put things back on track before the end of the project. Keep track of all scope change requests coming from all the team involved. Make it very clear those already approved and those which won’t be pursued for any given reason. A scope change track document will have the following information:

  • The new requirement OR requirement changed;
  • The description of what’s changed;
  • What’s its impact over the schedule;
  • Is it included in the project or not?

You can use this model to track the changes. Once they are approved, they must be listed as a new requirement in your original scope document.

Others

Few other activities will require you to have a kind of formalization. Using email for that is enough. Some of them will be:

  • Deliveries approval;
  • Changes approval on scope and schedule;
Digital transformation, IT is business

Cultural change in IT 1/X

May 3, 2019

Recently I had once again the privilege to join an international. It gathered decision makers of global IT leaders from companies like Caterpillar, Wells Fargo, Delta, CVS Health and many others.

People like them are always in a rush. When they decide to invest their time spending days out of the office, these moments must be very productive. These leaders always look to enhance their knowledge, and did so in two different ways:

  • Experiences exchange with their industry peers;
  • Watch really relevant content brought by authorities on some subjects;

I’ve been in touch with this audience for few years, and no matter what is the season or the new IT acronym brought to call attention, the biggest difficulty for all the leaders, to make their businesses thrive, always is culture. It’s getting more and more evident.

(With culture I refer to the need companies have to change the way their employees operate, how they think, manage their resistances and expectations. The companies have to develop them. Not only through practical and technical courses that can be done in a week or two, but also through more abstract scenarios like their behavior).

A way to make progress

An excellent panel from a former Gartner Vice President approached the subject. He gave his suggestion on how to lead this cultural change in an organization the right way.

At that moment he suggested people will have more adherence and will give credit to the change once they are exposed to and actually find themselves in three clear aspects:

  • Purpose
  • Autonomy
  • Ambition

People must have a clear purpose in front of them. This purpose must make sense. It can’t be evil. Nor be only make money. It must do good to something: maybe the environment, maybe someone else, etc. After that, they must have their ambition clearly known by their leader. It’s something very personal and some people might not enjoy talking about it. Everybody has it in some way. But purpose and ambition, without autonomy, is useless . If people see something that is not right, they must be able to fix it by themselves. Period.

A beautiful example of how it’s given to people on production lines using an Andon cord (from SixSigma) was shown. But how to achieve it on IT? (On the original speech, the author suggested the IT managers to give it to their technical teams by implementing DevOps).

This moment was very meaningful, and the connection between theory and reality was immediate. The only way to develop people having the three items above in mind is through individual development. Be close, instruct, direct, suggest. Persuade people in their personal development, through weekly or biweekly evolutions. This is the only way to keep expectations of the company’s goals and the three described items. It will ensure no misunderstanding is created and no interferences between those who think on strategy and those being developed will occur.

Entrepeneurship, Practical examples

Successful negotiations

February 20, 2019

When we talk about services industry, unless you are in a niche not explored or own an entire market, it’s hard to show trustworthy credentials and proofs that you should be the one chosen (showing you are better, you deliver in time, your quality is world class, etc). Almost everybody can say they are good at doing what you do, even if they have never done anything like that before. This affects sales directly in a market where the competition is huge like the US. Getting into scenarios where we have at least 3 competitors, and some times more than 10, is pretty common.

In 2018/2019 I’ve been successful in the biggest part of sales negotiations I got in. For those which we didn’t win, at least we figured in the final shortlist. They all have different stories like where we met people involved, the percentage of how much the negotiation was done physically or not, how many steps each one of them had, the client’s size, and many other things that influenced on the results.

The common thing for winning all of them, from what I’ve seen this far, for sure passes by how much you can show of your technical quality not using technical stuff. The one who signs the check usually is not someone technical, but wants to feel comfortable on choosing us. Making them comfortable someone appropriated is going to handle the situation is the key.

But after winning, a feeling, or even a testimonial, comes about why did we win each one of them in specific, I mean the strongest reason in particular for each of them. Below I listed some of those main reasons for some companies, described a bit the scenario involved and shown how we prepared for some of them.

Speed and coherency in communications

Being fast and coherent on your communications is something decisive. If you go too slow, your client will end up thinking they are just one more in your list. Some studies say that your first answer must be within the first hour the client contacted you. For the next steps it may vary a lot. Being fast brings the feeling that you are dedicating energy to them. Beyond that, the speed with coherency creates trust between the parties. By coherency here I mean saying NO when you have to do. When you say no for something requested you are creating anchors of truth (that you will have to proof they are true in the future), and also is decreasing the strength of vendor-client aggressive relationship that some partners try to proceed.

Dedication on understanding the scenario

Do dedicate yourself on understanding the scenario. For sure this is the step that will give you inputs for everything mentioned here. If you don’t know the partner’s scenario, you simply are not up to help them. Dedicate on understand what is the business scenario, what you really have to deliver, but also spend at least 30% of your time understanding the consequences of each scenario. Why is that company buying from you? Do they have a strategic move related? You will know that and get more information to look even more trustworthy just knowing your client’ situation.

Be flexible. Give alternatives

For many of the negotiations I got involved in, there was a mental clock running out of time for something to be solved on the partner’s organization. If your client is under pressure, he needs alternatives. Period. He needs something he can realize is better for him so he will sleep comfortably at night. If you go for a negotiation with one scenario of purchase, you are losing the opportunity of being 2, 3 or even more alternatives inside one partner at a time. If you go for the scenario with more than one alternative, you will show empathy with the situation and also will show flexibility. You solution and your knowledge may always be the best in world, but sometimes it’s more than what the partner needs. He just needs to solve a problem, not a rocket.

The setup for the moment

Unquestionably, my favorite part for every single negotiation. The moment at the round table. The table must be round. For all of those I got involved and I remember while writing this article, we wanted the long term approach. We didn’t want just to have a deal and never show ourselves again. We want that deal to be successful, because we want more deals and also referrals for more deals. A lot of techniques can be applied for this moment, but it is a matter for a single article and I will resume here in three steps:

  • Preparation – know everything. The scenario, the people involved, the implications involved, etc;
  • At the table – prepare for that. Plan ahead each move and each question that might arise at the table. Be prepared for a money negotiation;
  • After the table – you went so far, let’s now miss the deal with small mistakes;

Use credentials

For every moment of contact you are allowed to use credentials. Credentials can be a lot of things like telling a story about a project your company delivered, for how long the company exists and handle challenging projects like the one you want to talk, even cheap chat can show credentials for some unformal scenario. The goal for a credential is to increase trust in something that will help the negotiation move ahead. But the one who got my attention and was not in my speech at the beginning of my journey was telling how many years I’ve been working in my company. The perfect scenario happens if the customer ask you that, because will show he’s interested. But you always can mention that to leave one more strong anchor.

Decisive factors exposition

In long-cycle sales like my reality (having more than 6 months between knowing a company and signing a contract), it’s close to arrogance to think that what you heard for the first time when you met your client as his business goals will remain exactly the same 6 months later, when you are at the round table negotiating. Whenever you have a chance, ask key questions to check if you are delivering what the customer expects. Be straight on that. That’s simply the reason you are being hired. Ask that and double check whenever you can to check if nothing has changed. At the right time make it visual to create a mind-contract between you and who are signing for your services. This is the only way for you and the partner have the same feeling that you are going to deliver what they need and want.

I hope these thoughts I gathered during 2018 and 2019 (this far) help you to be successful in your upcoming negotiations. Use the space in comments to ask questions if you want. Let’s talk!