Deadlines & Plannings
A series of best practices to deal with the anxiety of your team, customers and managers
One of the biggest challenges in software development is not the software development itself, but defining due dates to them. In this post, we are going to explore the different project types, when you do not need to fight against deadlines, how to manage team and resources without knowing the details about the project definitions.
The Different Project Types
We need to start the conversation about deadlines and planning understanding that are different project types, and each one has it's best ways to be handled. Projects are, in general, in one of the groups below:
Closed scope projects: those ones are common in software houses. Usually, they already born with a deadline because they exist to attend specific needs: a hot site, a brand campaign, a lead collector.
Products: those projects are owned and developed by their own companies. As a best practice, they are in continual improvement. Examples are the products for big tech companies like Airbnb, Dropbox, Ingresse, Nubank, Uber, etc.
Prototypes: they are small projects, with few or almost no definition. Used to test an idea or concept. They born fast and die faster.
Each one of the types above has its characteristics and must be managed in a way the fits their needs.
Every Project is in a Chain of Value
Before discussing the details about how deadlines can be defined, it is important to know one of the best tools to help you discuss the project scopes, that is the chain of value: speed, resource, and quality.
The trick here is to understand that all these three values are closely related. So, if you pull a string to one of its sides, it affects the other ones.
In this way, every time you get in a negotiation about deadlines, they probably will be like that:
Projects with a small budget mean that you will spend more or less time based on the selected scope.
Projects with a high-quality standard or large scope mean that faster a project needs to be released, more money needs to be invested;
Projects with short deadlines mean more money or less scope.
When The Project Borns With a Deadline
In general, projects with closed scope, or prototypes, have their own preferred dates to be released. It is because it's their characteristic to be related to something happening in a time base, for example, ad campaigns websites, apps for a festival or specific hype.
In those types of projects, the best you can do is not fight against the deadlines, but understand the dates are real and help the client or manager to choose what is best using the technical knowledge you have.
It means that those conversations must start talking about the dates, not just avoiding them as many of us try to do usually.
Start asking the preferred release date
So, once we agree that you must get ahead in the negotiation and you ask about the dates first, making it not a big thing, the possible answers are:
A reasonable deadline, from where you are going to filter the scope based on the available resources.
An impossible deadline, to what you can respond with a reasonable reason.
Clients will be always focusing to get the most similar result to their original ideas they can. You will not be able to remove features by trying to create reasons they are not useful or don't apply. Instead, focus the discussion around the resources needed in order to make the project real.
They will always try to spend less money as possible, so you are going to use that in your favor to balance the scope to achieve the deadline. Try, for example, split the budget into features or blocks so he can choose what to remove in order to achieve the date with a specific money investment.
What About The Projects Without Specific Deadlines?
For companies that are creating and maintaining products is usual to be asked about the release date for features in the pipeline, instead of receiving a deadline from outside. It happens because many projects in those companies are planned thinking in the medium and long term improvements.
If you are working in this type of project, your strategy is not to negotiate around the chain of value, is about keeping market traction.
There are two main reasons why a release date is demanded in product companies:
For budgeting reasons. Common for companies that split the resources between teams, goals or branches.
To address management anxiety. And, believe it or not, it is the most common reason.
Invariable of the reason, everybody feels that they need a release schedule as granular as in days. Truth is it is not what they need, and a lot of times, it is not what they are asking for. At the beginning of projects, it is recommended to explain project duration in months like 2 months or 1,5 months.
Allocating Resources Wisely
Tech leaders who know their products from inside are always able to give an estimation of development duration in months.
Bills, people and whatever other financial transactions related to project developments are discussed in months. Measuring team and money required for a project based in months gives what managers need for provisioning.
With the tech and finance teams speaking the same language, it is easier to bypass the need for a day detailed schedule. More accurate in those months you are, more confident managers will be for the next projects.
In the beginning of projects withtout a deadline, no one is worried if the week day the project is going to be pubished.
Managing anxiety
In my past experiences, the most common cause of schedules being demanded is anxiety. And this anxiety grows up for some reasons:
market pressure (like when the Snapchat is hyping and everyone started to create a "stories" version of itself),
customer demand (when new features claimed by users may represent a revenue growth or protection),
competitive front (when competition launches a new feature, and you need to keep up)
The reasons above are commonly seen in different formats but directly address them is not the way to go. Remember we are talking about projects that do not have a specific deadline, so the rush is because they (whoever they are) need to feel moving forward.
I suggest you to try following the flow below:
breakdown the project in small functional parts,
set a release date for the first part, because even if it is just the first part, with the correct prioritization, you will solve the problem major parts,
present delivered parts as close to the release date as possible, it helps to feel that things are happening (if the deliverables are no visual, create something visual in order to show the progress),
go back to step 1, re-evaluate the next functional part and repeat steps 2, 3 and 4 until the project ends.
The first contact with this workflow is going to be hard but a soon as you achieve step 3 for the first time it starts to feel functional and more natural. In product development, everyone prefers to see results as earlier as possible, with fewer expenses as possible.
Applying the techniques above will always be a challenge inside companies with a strong micromanagement culture or more structure project planning practices. Changing culture will demand soft skills like communication.
Improve those abilities. Read about it, or bring closer to you people who can help you convince others. A great read is the Dale Carnegie book "How to Make Friends And Influence People". It is a short book, simple and easy to read.
Project management is a 20% technique, 30% experience, and 50% ability to communicate and to speak in a way the other side of the table can understand and value. It is an exercise that requires time and practice.
It is not impossible to work in a company where deadlines are not the major rule for projects. It is a culture that can be grown. At the end of the day, what we must be all looking for is not the release date, neither the pressure but the results.