Introduction
It is very common to assume that when a project fails to deliver on time, it is either the client's fault for changing scope during development, or the development team's technical inability to deliver the scoped milestone in time.
Even if the above assumption may at times be partly correct, in this article, we will cover techniques and management tricks that are aimed at removing or minimizing the risk of failure.
I am a strong believer that the way the project is managed is key to a project's success, no matter its scope-creep or difficulties. This article will focus on a specific area of project management: Ticket Management.
The article will cover multiple areas of Ticket Management, from "Project Breakdown", to the definition of MVP, until exploring the very fine art of ticket writing.
Disclaimer
Before we jump into the main content of the article, I want to clarify that what I am about to share in the article below has helped me for years on multiple projects, but it is not a rule, and things may be adapted and work differently for different people and management styles.
Break the Project Down
There is no better way to start our little journey into project management technique than by discussing project breakdown.
There are multiple videos, books, and posts that cover this topic and mostly all of them will refer to the definition of MVP (minimum viable product) as the starting point and first delivery milestone for a project:
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. https://en.wikipedia.org/wiki/Minimum_viable_product
As a project manager (or a tech lead taking over PM responsibility) you will be asked to work with the client to define the first milestone for a given product. This as defined above, will include the minimum amount of features to make the product "usable".
On multiple occasions in my career, the client's expectation of an MVP has included more than a real MVP should. This is normal, since the client always wants to make a good first impression, and removing features may, at times, be seen negatively for the product.
As I mentioned at the start, this post is going to focus on what YOU can do to make sure it is delivered successfully, and it will not focus on how to deal with difficult clients as that is outside the scope of this post.
You may probably be wondering how, if we are not going to discuss MVP definition, are we going to change MVP delivery?
Your MVP May Not Be the Client's MVP
Well, this is actually where the magic begins. I call it magic, but as you will read in a few sentences, the method I use is pretty simple, but I can guarantee you to be very effective.
The first step that we are going to take is to sit down with our team and define what you really would expect to see in a real barebone MVP. I usually find it simpler to address this by calling it Alpha. The idea of this exercise is to start from a very basic workable product, and then add small features to it as you and the team may seem fit as the MVP.
NOTE: Instead of starting from MVP requirements and trying to remove things, start from the basic technical implementation and build it up to the client MVP.
The expectation of this exercise is a set of milestones that are smaller than the client MVP. This should not only be achieved by removing features that may not be seen as required (for example a newsletter integration), but also by proposing a basic version of agreed components (eg. Removing complex shadow from a card, or removing animation on client interaction). A reduced scope should also be associated with a quicker delivery.
It is important to understand that this MVP does not have to be shared with the client, but should be visible within the team and actively used as the first and more important delivery milestone. The client (and all communication to them), will still work toward the MVP feature set and timeline. But internally, the team is working toward a faster delivery and a smaller feature set.
You may be asking yourself, what are the reasons to add extra work on your shoulder and how can this help the delivery of a project? An effective breakup of MVP and Alpha will produce the following results:
- It will provide early insight into project delivery: If you fail delivery of Alpha, you will quite probably fail overall MVP.
- Reduce the complexity of the first iteration: As we will see later, removing unneeded complexity helps the team to focus.
- Remove the stress from the team and you: Working on your deadline helps manage internal team stress and work with them.
- Prioritizes what is needed: A successful Alpha delivery will deliver the client's working version very early on, and will also reduce the "consequences of failure".
Failsafe for Missing Delivery
Before we move forward to the next topic, I want to share a few more words about the "Alpha MVP" and its benefits. We are going to focus on missing deadlines and how the above methods, can act as a failsafe.
As we all know, projects never go to plan. Many things can happen in a project that could affect its delivery. This could be a team member being sick, a delay in hardware delivery, a slow client, a change of scope, and more.
Knowing that missing q deadline is more possible than actually hitting them due to unforeseen circumstances, it is just expected to create some guardrails to support our project.
The first thing that comes to mind is probably adding a buffer to your project, and this is amazing if possible. But as experience shows us, extra time means extra features and scope creep from the client (Of course there are techniques to avoid this, but this blog post is focusing on what you can do without involving the client).
I am not proposing anything extra for you to do to ensure you have an emergency exit in case of late delivery. All you need to know has already been shared above in the previous section!
I have delivered many projects on time, but I have also failed others. What needs to be learned from the failure is that even if we "missed the full delivery" in many cases, we still went to production and the client was still happy.
Defining an MVP that focuses on what is needed and not what is nice to have, not only speeds up development, but it will also mean that the tasks left at the end of the project are just nice to have, and issues that can easily go live after a few days and do not require immediate intervention.
Just to provide more context, these are a few examples of things that have "bleed" outside of the project delivery, and the client was ok with it as we were still able to go to production.
- Progress bars attached to client scrolling of the page
- Renewal emails and cron for an e-commerce website
- Complex page transition
- Image zooming
- Past event page
The ones above are just simple tasks that we sometimes add to our tickets, without realizing the complexity and extra time that they may bring. Let's analyze the first point "Progress bar". This was initially expected to be developed as part of the main navbar ticket. As much as the feature seems simple, it takes time to test and develop, so we moved it out and delivered it later in the project. This allowed us to use those extra hours for actual changes to the data that happened right before the deadline.
Creating an environment within your team where "saving a couple of hours" is seen as something important at every stage of the project, will eventually help you deliver faster.
Sometimes we think of a simple few hours of saving as superfluous, but it just takes a few of these changes to make a difference between delivery and failure.
Write Just a Few Tickets
In the previous section, we defined our MVP and Alpha milestones, and it is now time to write the tickets to achieve this delivery.
My second suggestion is: Just write enough tickets to fulfil a couple of days of work and no more. As you may be aware, writing a ticket is a complicated matter and it can take quite some time- time that can be very valuable at the start of a project.
Let's assume two different scenarios. The first is where the PM will focus on writing all the tickets, and the second is where we just write a few to get the team going and then analyze the key differences.
Write All the Tickets
This is a very common scenario. The PM has been given a project and asked to start it asap. At this stage, the PM will spend his first few days writing all the tickets that have been defined as the MVP and will share them with the rest of the team. He will probably join an onboarding meeting, but most of his time for the first few days will be in writing tickets.
The backlog at the end of this exercise is going to be nice and full and the PM is going to feel ready to start.
Write Just a Few Tickets
Also in this case, the PM has been asked to task a new project, but instead of writing lots of tickets, the PM will just write enough for a couple of days. The Backlog looks empty with just a few tickets.
Many Tickets vs Just a Few
I know that you are probably thinking that I am mad to suggest writing fewer tickets, but I suggest you read below and probably even ask your team and you will be surprised about the answers.
Let's compare the two above by using a few metrics: PM, Team, and Project.
PM Time
The first is PM. In the case of many tickets, the PM will have to spend a few hours writing tickets. Want or not, this is a lengthy operation that takes time. I usually take around 5-10 min per ticket to write them well with all the acceptance criteria and links required. So writing 20, 30 or even 50 of them can take days. In the case of a few tickets, the PM will regain valuable hours at the start of the project. This can be spent on many important tasks such as defining MVP, client communication, setting up procedures within the team, and actively spending time with the team to ensure they have a full understanding of the project and the product to be delivered.
WIN: Write just a few tickets
Team
We are now changing perspectives and looking at this from the team side. As we have seen before, we have two possible examples. In the first one, the time will come in the morning, and have an onboarding meeting with the PM. After this meeting, they will have the ability to start a project. The backlog is nice and defined, and they have lots of tickets to work on, so they can put their heads down, and get on with the work.
In the second, the PM is going to introduce the project and share a few tickets that they should accomplish within the next couple of days. The PM is going to be actively involved, and can get the team feedback on the tickets. For example, the team may prefer a Figma screenshot instead that the link or the team mentioned that would be nice to define Accessibility requirements within each ticket.
Even if you would probably think that active cooperation can be achieved also from the first iteration (lots of tickets), I have learned from experience that this is not always the case. When the team has lots of tickets available, they just go on with the work and do not think of changing things as they are already set. Making fewer tickets forces the PM and the team to cooperate, they will all know what they are working toward and make adjustments very easy.
WIN: Write just a few tickets
Project
In this last point, we are going to analyze the advantages and disadvantages that the above methodology would produce for our project.
In the first method, the project is going to be fully scoped. The PM is going to be able to easily track the burndown and see the progress of the project. This can also be useful for the client as it will have clean visibility on its "MVP". In the second scenario, the PM has surely lots of extra work to do to maintain the project. She will have to be able to track projects using her milestones and not tickets, and she will have to fill the communication gap produced by the missing tickets.
At this stage, you probably think that having more tickets is going to be better, but here comes the best part. Even if having fewer tickets will require the PM to work harder, it will produce a more flexible environment that can easily adapt and or change.
Small changes in the way ticket are written can benefit the team's velocity, defining a small chunk of work help understand velocity and productivity, and having fewer tickets allow the client to change the scope and re-imagine his product without creating many obsolete tickets on the board.
I agree that having fewer tickets and a dry backlog can be complicated to manage, but the benefits, in the long run, are massive.
WIN: Fewer tickets if managed well! :)
Note: I may have been a little biased in the above comparison :P
Conclusion
Project Management is an art and it can be accomplished in many different ways. My management technique focuses on flexibility, but most importantly, team engagement. I think the success of every project is not held by the client's ability to stay on course with its initial idea, or by PM micro-managing the team to complete all the tasks to create the perfect burndown. I am a strong believer that the project's success is helped by the team working on it. If they are engaged, and all work together to accomplish the project, the project will have no issue.
Please note that I am not saying that, if the team can complete their tickets, the project is going to be a success, but if the team is engaged in all aspects of the project, the project has a big chance of success.
If a developer has a forum to help you define the technical flow of MVP, the project will be delivered faster. If a developer has the forum to express his/her idea on different breakdowns and execution of a task, the project will gain speed and momentum. Remember, you are not always able to change the client, but you can change the way you deliver the work to them!
