Browsing Category

Customers

Career, Customers, Entrepeneurship, IT is business, Practical examples

Two main errors your agile project may have right now and how to solve them

March 12, 2020

Doing agile for software development is way beyond leaving the heavy documentation behind and produce more. According to an HBR study of 2018, 25% of enterprise companies are already using agile and 55% are in the process of doing the same. The data doesn’t lie: the masters of DevOps and Agile grow and are 60% more profitable than the rest. Agile brings many benefits, but it also brings new challenges built-in. The single point of adopting agile is already a major challenge. But after them, new challenges are still there and you might not have noted them.

1st – Involuntary blindness from POs

A day in the skin of a PO (Product Owner) is tough. They own the product! And are responsible for its evolution. Basically they are responsible for translating the company’s macro strategy for that product into the actual final product. It sounds pretty simple, but this process is where commonly things get fuzzy. A PO also:

  • Solves questions from the development team on their tasks;
  • Keeps feeding the backlog;
  • Helps the Scrum masters with decisions for prioritization;
  • Eventually, changes prioritization and delivery plans because of special requests from the management;
  • Monitors metrics of the product;
  • Is responsible for meetings with high management to discuss the metrics she’s been monitoring;

Many of the items above would require a person full time working to fulfill it successfully. But given this load of work, the PO often leaves behind one important thing: hearing what the market is saying and still staying aligned with the macro strategy. By that I mean the PO frequently doesn’t have time to think, judge and decide appropriately after a new demand came from a BA (Business Analyst) or high management. Due to lack of time, she leaves behind the most important task of his job, which is enhancing the product. Let’s go over one example to better illustrate:

A page never used in a hotel website

Years ago I was the SM (Scrum Master) leading a team developing a hotel website. I remember as if it was today. We had a big deliver at the end of 3 months and in the last week, my PO brought me the news that we missed one important page to showcase the hotel’s partnership with an entertainment channel. Guess what? We worked several hours more than planned and delivered just a small part of that page. Also kept working on the same page even after the deadline. We released the final page a few weeks later, and I was checking Google Analytics. I found out that that page had less than 5 percent of the website visits.

The summary: we spent at least one entire month of work on a page that less than 5% of our target public was actually interested in. We wasted one month of money for a team with 4 dedicated people. There was no regulatory thing and no contract binding forcing them to have that page live. It was just a request from a board member. In that situation, the PO SHOULD have argued about not doing that and going for the e-commerce system as a priority. This was actually something the users were asking strongly.

But why did the PO let it stay that way? The answer: she didn’t know that page was about so few accesses. She was so dived into the deadline and reports and monitors and tests that she just accepted the request without questioning it. If she had had time to think about it, with the appropriate information from her BAs, she would have taken a better decision.

2nd – Deficient hands-off of tasks from the PO/BAs to the delivery team

The second thing that often breaks plans is when the planning meeting is already going on and the technical team finds out a task is much bigger than the PO/BAs thought at first. When the PO is defining the next tasks for the backlog, she must be well aligned with the software architects. When a major feature (an epic) comes to the table, the technical team has to adapt the software to develop that new task accordingly. Let’s go over one more example:

The “just one more report”

This one happened during a project for one company in the manufacturing industry. The software had been running for months and was stable. We were in a phase of acting over bugs, security and small features. We were also generating some reports for gathering new metrics. When the planning started, our PO explained about the task of adding more columns and creating a new report with charts. The charts were fine, but those new columns were stored in other systems which we didn’t have control over. We had to talk to people on the other software to create an API for us to consume the data, and the simple report took more than a month to be finished.

The interesting part of this example is that the report was promised to be delivered after one week and took almost 2 months. The management had to wait for the new report to take new decisions because of the important information. The change from 1 week to ~2 months created an unneeded discussion between the project team and the management. All of that wouldn’t have happened if somebody with a brief technical vision of the project was involved during the grooming/prioritization of the backlog and had properly communicated with management.

If a task much bigger comes with no previous preparation, it generates delay. The way to solve it is to have technical senior people checking the backlog periodically and being closer to strategic decisions. This way they will be able to anticipate such moves and tackle big tasks little by little.

At last

Agile is not exact sciences. You will have to find your own set of practices that will create your own agile. These are the two main challenges I found are often hidden and people don’t actively tackle them because they don’t hurt at first, but yes have side effects that can turn into a big mess. And what are your main challenges?

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. Client 2 produces heavy machinery for farmers. He found out that one of the pain points for them to upsell more was the bureaucracy of field representatives. The farmers wanted to buy from their upsell strategies. 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 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.

Customers, Digital transformation

If you are not investing on design, you’re being left behind

January 9, 2019

In 2015, the DMI released research saying that companies having a design-centric mindset on their strategies grew 211% more than the average of the rest of S&P 500 during the past 10 years (find details here).

In 2018 Gartner, the biggest consultancy company in the world for IT decision makers added Customer Experience as one of the main subjects for its main world-class event (find details here).

Recently, a McKinsey research revealed that companies which invest in design grow, on average, 2 times more than the leading companies of its respective industry (find details here).

 

Design is already proved

Design, UX, CX, etc already proven itself as something highly valuable. Few years past, it was hard to find examples, but nowadays it’s getting easier and easier to find uncountable examples:

  • Netflix didn’t break Blockbuster. It was the need to return the tapes;
  • It was not Uber who broke taxis. It was the bad service and high prices;
  • Digital banks are not “stealing” large slices of the market share of the big banks. It’s big banks’ lack of transparency and bureaucracy loosing market space for competitors;

People want to interact and will pay more for that, with transparent services. Companies who used to make things confusing so their clients don’t understand are being pushed to change. The UX is the professional who points these issues and transforms the transparency and no-bureaucracy mindset into visible things. Companies are realizing that, and UX is the fifth most demanded profession of 2019 according to LinkedIn.

 
Why is it still hard for decision-makers to find value on design and afford it?

The same McKinsey report stated that 40% of companies still don’t listen the user’s opinions on their products. It’s like selling a cookie and not asking who’s eating if it tastes good. Isn’t the 211% (by DMI) or 2x (by McKinsey) convincing?

From what I heard this far, I mention these 3 points below as the main for companies to still decide to keep design outside their projects.

 

Lack of knowledge

Lack of vision of what design can aggregate and lack of eager to know is the main reason. There are plenty of people on IT and business departments still thinking that the old meaning for “web-designer” is the CX professional. Their skills are very different.

DeveloperOld “web designer”CX professional
Does codeDevelops code. Backend and frontend and layoutsDoes not code
Turns layouts into softwareCreates better screens than developersExecutes a long process of research before deciding something will be solved with layouts. Creates layouts that make sense
Commonly thinks about one single application at a timeThinks about one single application at a timeIs always aware of all the interactions the user will have with the product’s brand
Turns layouts into softwareCreates beautiful applicationsCreates applications that make sense to their users and are beautiful if needed
 
Costs

Closely attached to the previous item, if people don’t understand what the UX professional will do, they won’t give value to its deliveries. Then they tend to consider the UX are just more cost on the project to develop and activity that someone else could do.

Fear of innovation

Every leader likes to say they are innovating. But it may occur they start to fear when someone else close to them is innovating more. Since the design mindset naturally brings parts of innovation just because of its existence, I’ve already seen people sabotaging user-centric initiatives.

Customers, Practical examples

A good customer experience performance for sales at financial area

May 7, 2018

This article was written by me, Eduardo Diederichsen and Felipe Lindenmeyer. Me and Eduardo are managers of ilegra’s Software Development area, and Felipe is a senior account manager. We all are connected daily to clients demands.

 

Daily we do negotiate with a lot of clients. The hardest part is not giving them a price or conducting a good presentation with beautiful slides speaking buzz words. The hardest part is to identify if the potencial clients have a challenge for real and how its challenge can be approached by our company’s potential, language, market vision, and etc. When we find that out, that client will deserve our deep focus to make a good understanding and offer something that fits perfectly to its needs, even if he doesn’t understands it, but then try helping him understand it.

 

The experience

But what makes a experience as perfect as it must be so a client with sign the new contract? Impossible to tell because who buy from anyone is people. People lay on different things to evaluate their experiences everywhere, giving more weight to different points based on their personality and the influences they had during their whole life.

 

The scenario

This recent new client had a complete journey from the very beginning contact to signing a contract held by themselves in many companies. At the end he decided to buy from us.

The client scenario

It is a client from financial area, so he knows the financial area customers in Brazil are very demanding regarding the whole UX and the products flexibility. Brazil is the country with most developed User eXperience demand in entire world, so the competition and investments here are huge.

First contacts

What happened: the first contact happened in a casual party, not related to work. The subject on the crowd turned to work. We explored very briefly few examples of how we are helping some important companies in Brazil to be in front of their competitors. What really happened: The attention was caught and visit cards were given. Few days later they asked a meeting to talk about our portfolio and get to know their requirements and concerns.

The meeting

What happened: it happened at customer’s facilities. The goal was, as they asked, to talk about few scenarios we’ve been working and the opportunities we identify and foresee as experts at the market. What really happened: they understood we had the knowledge to be their partners and if they count on us they would have oppinions of a specialist in their market. So the next step will be send a proposal and everybody celebrates? Yes, but not so fast.

The challenges
  • FIRST! What happened: they are a very conservative Brazilian firm which still isn’t enrolled to digital transformation practices and doesn’t even want to get to. We are very used to work based on agile methodologies, Lean approaches, testing and discarding losses very quickly. They wanted everything predictable with very clear goals and steps. What really happened: they understood that their competitors don’t work in that way anymore and that working that way they would still be left behind in the competition scenario. Then we reached a mix of practices that would give them part of the control they were asking but giving the project part of the freedom that kind of work needs.
  • SECOND! What happened: they told us they wanted to be in front of their competitors knowing how much it would cost and how many time would take. Well, if I knew that, I would be one of the competitors. And that’s where the Lean and experimenting mindset gets the attention. The startsups bothering giant industries don’t have this kind of answers. They won’t have it too. What really happened: we decided to go for a first deliverable (We can call it an MVP) and a further evaluation after that to redesign the plans.
  • When things got warm: What happened: we had the steps above but it was taking too long for a decision and things got warm (bad news). Our decision was to invite them to come to our company’s headquarters to see with their own eyes everything we were discussing. They really got impressed with our office because it’s designed to give freedom to people think and innovate. This was a key step because they spoke to people who would actually work with their project. What really happened: the deal got hot again.

 

What is faced differently by everyone

There are a lot of subjective things in the explanation of the sentences above. I’m not exploring their body language, neither ours. I’m not exploring the sentences we told each other and how did we look during the meetings. So, I’m not telling how we created empathy here. Let’s get to things close to that.

The client scenario

Some companies can be afraid of innovate. It’s a whole new scenario. People fear the unknown. They don’t know what is coming and then they get afraid and just stop. For other companies, the unknown is exciting and they know from there the innovation will come. They will seek for it as a routine.

First contacts

Since it happened in a social event, the thing was easier. The focus was not evaluation. The empathy came easily because we spoke about our cases in a brief (not moving the whole night focus to work only) and humble way. If we were too thirsty about their needs it could turn into something boring and we could lose that guy’s attention.

The meeting

The meeting was all about showing our capabilities. With that being flexible to understand their concerns about models and what we were proposing. At that time we invested some time explaining and desmistifiyng software development practices like Dojos, Meetups, team management models, our concerns about quality (A/B Testing, Chaos testing, etc). And at that time a big thing happened: the empathy with one of the guys was so huge, he found so many value, that he started defending some of the approaches to the sponsors in a very enthusiastic way.

The problems

We had to use a lot of knowledge to tell them the differences between the way they were approaching the problem and where we see the market moving to. It was hard work to understand how they treat projects and mix it to a reality we could work being sure we would reach the results both of us were hoping regarding the new partnership. But the biggest step taken was the use of the experimentation mindset to go for the first phase. They wanted to give a shot at our suggested model. That’s the chance we had to keep things going well so we would build more trust.

When things got warm

It was the dangerous part. Calling and bothering client’s patience wouldn’t have been the efficient approach. Bringing them to a controlled environment was a good move. Sometimes people don’t get everything you say when you are presenting something. You will have to repeat it in order to get the perfect moment where your explanation will make sense to them and then their attention and interest will be caught.

 

Being more generalist here with a few more examples

One customer may like to hear to most recent buzz words all pronounced in english. Another client, coming from countryside may not like it because he thinks it’s something for bigger companies. The proposal: one customer may prefer a document with a set of beautiful images in a more abstract way. Another customer may prefer to receive a one page document getting straight to the point using just text. It’s unpredictable.

 

Good! How can I learn with this scenario?

The CX (Customer eXperience) gets more challenging to achieve when we are talking about B2B or B2B2C offers. When you have a B2C scenario you probably will have one person at the edge who you have to please with your offer and your advantages. It’s easier to ask him: “hey, did you like this new feature?”. Getting back to B2B or B2B2C the variables are countless, since you will have to deal with many people from the very beginning of the negotiation until reaching the final contract signed.

 

How to attack that efficiently?

Short answer: be interested. Long answer: keep the knowledge with people involved, get experience, and be interested about evolving in the process and the learned lessons. Try to understand things about body language and psychology, do know the one who is buying from you. Does that guy writes publicly? Does he give speeches? What is he speaking/writing/reading/hearing/studying that you can take in count to set up a moment for a fast approach?

Customers, Digital transformation, IT is business, Practical examples

Software buying process on IT evolution

February 14, 2018

The more different views you have about the same subject, the more information you will have to take your conclusions and make decisions if needed. This first article about IT evolution had a sight from developers and a very superficial business view. This new article aims to look from the perspective of clients buying software and how they are different even inside the same industries.

 

How software used to be bought

In past years, companies used to buy software like any other commodity: I want 5 cars with 4 wheels each, manual transmission and white painted. They didn’t mind on how their software is produced, or any kind of good practices to apply on the process. Yes, inside the software requirement documents were sections regarding security, protocols and things like that, but at the end of everything, the lowest price would win.

 

Old (not too much) decision matrix

The decision matrix (example below using a car buying process) were very simple when selecting the criteria. They were also superficial. The high level criteria were easily like: security levels, performance, proposed schedule, price, scope coverage, success cases, knowledge on selected technology, etc. With this decision matrix, the weights are given according to each project. But the price and schedule, after all the criteria evaluation would still determine who wins.

On the example above: what exactly is comfort and styling for this buyer? Safety can be evaluated using governamental public data. This is a parallel to show how none of the criteria is detailed.

Anyone saying that could cover the entire scope, under the asked schedule having a fixed amount of money could win the fight for the projects. If they didn’t have knowledge enough, it wouldn’t make huge difference. After everything, software was treated like any other product. It doesn’t matter how it’s made. It just matter that it works.

 

Recent decision matrix

Leaving behind government industry, and few others not affected even a bit by digital transformation, the reality has been changing.

What I’ve seen lately is an increasing spend of time on detailing the criteria. For each of the criteria, the buyers want to know what the supplier have already done, how they plan to conduct the solution and also want to evaluate alternatives for everything.

  • Security: ensure the information exchange will occur under a controlled environment? Tactics for code obfuscation. Platform natural security concerns. Cloud provider certifications, etc;
  • Schedule: from “a detailed schedule” (which is never achieved) to “a macro view of time and a mix of agile methodologies to be followed”;
  • Success cases: show where/when similar solutions were already created;
  • UX:  from “the system has to have good usability” (completely subjective) to “it must follow UX guidelines from Google and be conducted by a specific professional, not by developers”;
  • Performance: from “the system has to load under 10 seconds” to “each endpoint must answer under 2 seconds”;
  • Scope: from “do everything desired” to “let’s do the most we can inside the schedule”;

The companies want to know how their project will be conducted in details, and they also want to put their opinion on it. Since the digital transformation is making companies to turn their core into IT, the IT is not a support anymore. So now they are able to suggest things and to talk at the same level of the consultancies.

With this comparision and evolution scene, the MVP mindset is very clear. Also the goals to achieve faster time-to-market and faster revenues.

 

Different requests inside the same industry

The report above is true for 100% of companies on the most mature industries in Brazil. But for the rest of industries, using retail as an example, it’s not:

There are stores who are already evolving their ecommerces for security, performance, scalability, stability and the most important: user experience. But there’s also those who treat their online stores as something needed. Is common to copy layout practices from concurrents. Also, security is expensive. Then some companies have a budget to lose due to hacker invasions, instead of investing to security.

The good news is that the market is evolving faster and faster. Soon no industry will be behind.

Avoiding problems, Customers, Office, Practical examples

How to avoid suicide applications

January 29, 2018

Having the experience of managing many projects in many different methodologies and different mixes of them, recently I could notice some attributes that happen in all of them to make it to be a suicide project to manage. By suicide I mean a project that will face issues and go down until it reach an unacceptable status, leading to a client loss, or something extreme like that.

The items below were identified as something common to all of managing styles, and if any of them is common to you or part of your routine, it’s time to change something. Some of them regard people relationship and some of them technical parts.

 

No QA environment

A project which has only a formal Production environment. The development is made by coders on their own machines. There is no QA (Quality Assurance) environment.

It looks crazy, right? But it still happens. Usually it happens when who is paying the bill doesn’t understand how catastrophic not having a Quality Assurance / Testing / Homologation can be. When it happens you are dealing with your luck day-by-day like the image above.

The QA environment must be, ideally, an exact copy of the production environment. Routines of copy from PRD (production) to QA must be maintained from time to time. When it happens, whenever a problem on PRD comes, it will be faster to track and simulate on QA. If it’s faster to simulate, it’s faster to find a solution and fix PRD. When production is fixed fast, the client loses less money related to that failure, or its brand is less affected due to that stop.

There can be different ways or minimum-requirements to at least have a trustworthy test before sending new code to PRD. The QA data can be different of PRD current. The environments may have different hardware configurations and etc. But the more differences QA and PRD have, the more time will be spent to track down issues.

Talking about a different service, when you don’t have a QA environment, holding proportions, it’s the same thing as a doctor trying a new surgery method without testing it on mice or monkeys before. It can work. But there is a huge chance of going wrong. And when it works, its nothing but luck.

 

Zero Automation

The more automation you have, the less human errors will happen. People will fail. And it’s normal! Let’s let people to think on what really matters and not on routine tasks. Somehow it will happen in someday:

  • They will commit the last code to the wrong branch. Then production will have a break;
  • They will forget to run a script before deploying a package. Then production will have a break;
  • They will forget to run minimum tests before running a new process or service. Then production will have a break;

A good way to prevent those errors to occur is to automatize as many things as you can.

A good starting point may be automatizing the deployment activity. Many companies I’ve already seen still have issues with deploy. They plan 4 weeks in advance for a deploy. The deploy is done. It crashes. It requires one or two weeks to fix the code and get production running back again. Then it plans with 2 months in advance. It crashes again. If the deploy is a problem, why not turning it into something trivial? Try to make it everyday. A lot of things will be learned.

Automatizing tests is also a great initiative. Automatized tests is one of the best weapons for software stability. The more coverage of tests your app has, the more stable it will be. These two suggestions will require time to be implemented, but their benefits will be felt on software credibility trough the whole company.

Talking about a different service, not having automation is like loading a warehouse box by box, without a fork-lift. A lot of time will be wasted of course. Also some of them will be dropped. Some of them will be shaken too much. It will work, but a lot of risks are added to the project without a need.

 

Key-user displicence

The one responsible for testing your project is the main actor of your routine. They will be whose opinion will be asked about on going practices. This person must be committed and addicted to your project, helping and pointing fingers to anything that goes wrong. The best projects I’ve ever been enrolled had very picky people testing and giving their OK to delivered features.

If your project lacks this concern, many problems may come up:

  • Lack of perception of value. What you have been practicing/telling is not what the customer likes to hear/watch;
  • Lack of alignment of what is developed versus what really adds value to the business;
  • The worst one: Lack of knowledge about the system. This person should be the one who knows all the system. If they don’t, many problems may come up because of different conceptions of why something was developed in some way;

This example is like a mom who doesn’t care about its baby education. It will grow, of course. But it can turn into a time bomb.

 

Low judgement at technologies choices

Technology is something serious and can’t be treated as a fashion trend. Fashion trends come and go and are renewed from time to time. A programming language, framework, feature, cloud provider neither anything related to development can be elected because its fancy or is the thing who everybody is talking about right now. All of this decisions must be questioned by the development team and, if possible, count on help from someone outside the project to think together with the team and reach the best choice.

When wrong technology choices are made, it may cause some problems like the following:

  • Difficulties to find people who know that technology to work with you in your project;
  • Problems in the future due to incompatibility of that technology with the project requirements;

Using the parallel to other services, using a new technology which is not proved yet is like buying a hamburguer with vegan-bacon inside it. It can be good, but is not proved yet. It will be your bet.

 

Deficient communication/status

How is structured your routine of communication with your client? Do you have formal moments to share information? Or do you make it when a trigger come? At this point there is no right answer, like suggested on the article “The magical answer for software development project management“.

But you will have a process to share information and to tell what you are doing to whoever is paying you. It can sound strange, but sharing this information may be a serious problem in many projects. You must ensure the activities you are conducting make sense to the client, and they understand that what you are doing is good to the business. Will you have a weekly meeting? A daily? A status report?

When you don’t have a process to give feedback on what you are doing, is like investing money with an investment company that doesn’t inform you about your gains.

 

Why to attack all of this?

All of the statements above refer to practices that must be figured in your project. Otherwise they will mean problems on the relationship or on the app data. Whenever any of them happen, they mean losing money or at least weakening the system owner’s brand. It may be natural that the main apps of a bank won’t have large issues. But the user doesn’t like when the registration to that cashback program crashes. It means the bank is not serious about their user and marketing advertising.

Customers, Practical examples

Status report – A practical model and example

January 1, 2018

Status report is a very powerful tool used for many different subjects and intentions. This practical example brings a real scenario created by me few weeks ago and shows an approach to pass the message to people that matter.

The model is presented below, and all the sections are also described after it, showing what is the intention and why it makes sense to this scenario. It’s AVAILABLE HERE (english and portuguese) and is free to be used in your projects.

 

The model

 

Identification, project manager, objective and date

These four sections are very important to ensure everybody who opens your file know exactly about what project you are talking about.

  • Client X – What is the company paying and interested in your project? It’s important to you and any other people inside your company to understand;
  • Project Y – What’s the project name? It’s the identification to whoever may receive this file to understand its purpose;
  • Project Manager – Who is responsible for this project? On all sides that matter to you. In this case just my company and client’s were important. You may add other suppliers as an instance;
  • Objective – Your main goal. It’s important to keep focused. Since it’s a file accessible to everybody on the project, everybody must understand to what they are contributing and feel part of that;
  • Date – it shows the period the file regards. Keep track of your status reports! This will allow you to know your progress and things you have already tried to do, and how they are going;

 

Status, logos and deadlines
  • The overall status is an executive information and to where everyone will take a look. It’s a simple message showing how your project is going on. It’s not what you think is happening. You have to have numbers to set it. In this document we used 3 KPIs (explored below) and the rules are: if all of them are green, the overall is green. If at least one is yellow, the project is yellow. If anyone is red, the project is red;
  • The logos (yours and your client’s) have an important message about the partnership responsible to conduct this project. It passes a subjective message showing to the whole team how the two companies are engaged to reach the same objective;
  • The original deadline is the first planned date to finish the project according to the schedule;
  • The replanned deadline is filled only if you had to replan your deadline for some reason. The reasons must be shown on the updates (explored below) when a replanning happens;

 

Risks, changes and dependencies

Whatever happen to risks and changes must be checked by you, as the project manager in charge, to understand if it will require any kind of replanning. It can affect your schedule, your costs, people involved, external resources, suppliers, etc;

  • Risks is where you list everything that may affect your project and make something planned to change. It’s common to be something out of your control, so have a plan to each of them to deal with problems when something go wrong;
  • Changes must be filled when something relevant arranged was changed for some reason. A decision was rethought? Make it loud;
  • Dependencies section is used when you have tasks depending on someone else’s effort. It’s very important because if they are delayed, you will have to deal with the impact;

The example has a dependency with a strikethrough deadline. It’s meant to show that a planned deliver was not finished and was replanned.

There is also a dependency with a deadline painted red. It regards a task that must be performed by someone outside the original project’s team. It must have a person responsible and also the date when the deliverable will be available. If that task is delayed, the whole project can be delayed.

 

Updates

This section is the one which will have a high rate of information change from week to week. All of its content can be changed from one week to another. Here is where you list everything that happened, new people added, results of tests, deliveries from another suppliers, and etc. I also like to keep two sub sections: what was finished during the last week, and what will be done in the next.

 

Schedule

The schedule makes sense when you are dealing with a project with fixed scope, and also when not. You can use it to make things visible about the next important deliver, when talking about agile. You can show macro deliveries or show 100% of your whole planning process (as the example shows).

It lists macro tasks, and gives them colors:

  • When green, it’s ready to be developed;
  • If its orange, it depends on something external and can’t be started now;
  • For red, it means it’s delayed for any reason;

It also shows the tasks planned to be delivered during the current week (orange painted on the first line of the table). It’s represented by the X on the respective cell. And at last has the percentage of each one of the tasks;

 

KPIs

The things you decide to measure during the project. For this one, people, scope and dates were the main things. The table shows the metric and the status for each of them. Whenever you have something different than green, you have to write a reason telling why it’s not going well. Do not forget to add the costs to this KPI section;

Avoiding problems, Career, Customers, Practical examples

Communication issues? Maybe it’s engagement issues

December 24, 2017

I started thinking on this article as my self year’s end retrospective. And I realized the biggest thing I learned during this year regards engagement.

I’ve been hearing, for years, that “80% of the projects that fail, fail because of poor communication”. That’s a sad true, but this year I realized this is an easy but messy abstraction. When you say that communication is the problem, you are hiding many serious problems, not only in your project, but also in your organization. And after that eureka moment, a new one came: people do “communicate the proper way” if they are engaged and have support to develop themselves.

 

Some examples
  1. We have a contract to watch an online app. It’s not very critical, but we still have SLAs to accomplish when it’s down. Then one issue comes and the person from OPS forgets to tell the customer, during the first 15 minutes, that he’s looking for a solution. Beyond that, he takes one more hour to solve the problem, than the 4h regularly expected. It will cause an argument during a meeting between the managers and everybody will finish the subject saying that they had a communication issue;
  2. We evolve a very critical solution, that deals with money, to a customer. Then the developer didn’t create the automatized test and the app breaks when goes to production. It will cause an argument during a meeting between the managers, and everybody will agree that the QA guy didn’t communicate properly to the DEV guy about the missing test.
  3. The project manager tells the project is delayed, but doesn’t tell how much it is. When something goes bad and someone ask for it, he defends himself saying he told about the delay, and had an interpretation issue because those who read didn’t understand the message he wanted to say. Then after that meeting, everybody will agree that he haven’t communicated the right way;

 

Why these things happen

What I learned during this year, regarding engagement, was to identify why these examples happened:

  1. The person from OPS team didn’t tell the customer he was working at the first 15 minutes, and forgot to tell he would take one more hour to solve the ticket, because he was not well empowered of its position. He doesn’t understands his position. If he forgets to tell the customer about the down time, the customer won’t be able tell the users. The users will start calling the call center, and it will generate an overhead on the call center team. So at least 10 people will have more work to do, forcing the company to pay for that extra hours, because of one missing news. The person from OPS wouldn’t have forgot to tell anyone needed if he truly understood the scenario.
  2. The second example has nothing to the QA. The responsibility affects the developer. He hadn’t created the test because he doesn’t know that every one hour of that system stopped, makes the customer to loose US$ 10.000,00. Nobody, when old, will want to tell stories to their children like “hey, once I stopped the production environment, and screwed many people’s life”. So the developer was negligent about the test because he is not well empowered of its responsibilities and capabilities.
  3. The project manager will is not to hide information. He gets paid, essentially, to keep people informed. When he waits one or two months to say the project is delayed for 2 months, he doesn’t think the people from project will be needed in a next one, and it will cause a loss on the company. Since people won’t be available, the original project’s budget won’t be enough, and the whole company will spend more money to hire new people to the next one.

So if you are inside any of these examples, think on the other side as your true friend. Would you let, any of these examples to happen, if you knew how deep it would affect them?

 

Solving the wrong way

It’s easy to put all these problems inside one basket and label them as communication issues. Then, our technical minds will think about processes to guarantee that:

  1. The tickets system automatically send and email telling the customer we’re working to solve the issue;
  2. We will create an integration between the task acceptance tool and the code repository to check if all the tasks have at least one test designed;
  3. The project manager will always present the status report having the customer on it’s side, so no information will be missed again;

The suggestions above are not wrong and shouldn’t be faced as something to be avoided. But they must be the last alternative. They are all mending to lack of people engagement.

 

Solving the right way: build together

People tend to be good. When you share the right way their responsibilities and how their activities affect each other, they will feel inside the group and will always try to help everybody. So why not asking each one of the actors of these examples how they would solve the problem? Present the problem, tell everything that happened because of their behavior. How to solve? This is the most difficult part. Probably the first thing coming from them won’t be the perfect solution or the solution you thought. Then it’s time for to show a better solution and check if it makes sense to those who will put it in practice. A mix of the ideias can be a good start.

And now we talk about people’s maturity to solve problems:

  • If they are junior people with good potential, just letting them to know their responsibilities can solve the problem. They have good intentions! They won’t forget to tell anybody the next time about what’s happening;
  • If they are overwhelmed, you will advice about looking for self management tools. And also will help them to focus on what is important and not getting overwhelmed again;
  • If you realize its needed, why not using one of the process solutions described above as the wrong way? Take care because if must make sense to everybody affected. It depends on people maturity to not feel pushed;

 

The main goal is to look for a mindset of empowering and networks, as described on the image below:

 

Always have next steps

Once I was invited to join a retrospective. The goal was to help a team with an external vision so they could improve their processes. The first thing I asked was where the “next steps” of the previous retrospective were. For my surprise they weren’t.

Always keep track of goals and results. It gives you sense of improvement, and if it doesn’t it will be clear to find where new mistakes were made. Have a periodic checkpoint with each one of the scenarios above until it fits a track where the problems don’t happen again.

After that, when you have the whole solution, you will be able to share your good practice to other teams around you:

  • What happened; Why happened; When happened;
  • What did you do to solve it, what were the first trials, and what actually solved it?
  • What did you learn from it? Next steps;