“Action is the foundational key to all success.” ~ Pablo Picasso
The traditional way of approaching new projects in companies has always been performing a comprehensive planning of all stages which will form the project. This is done in such way since many times you have to develop a budget that someone else has to define as acceptable; otherwise there’s no project. It’s also important to be clear about all the resources that are going to be needed in order to reach the goal.
Big projects have strong cost, time, quality and scope constraints. As a consequence, defining all the milestones, tasks and sub-tasks, estimating the time each task is going to take, establishing due dates and planning all the necessary resources becomes something apparently necessary.
This is the theory. In practice, it turns out to be that a high number of projects end up failing to fulfill the date of delivery, the established budget, the expected scope or the needed quality, if not many of these at the same time.
So, what do we need so much planning for?
In my opinion, for very little. Indeed, it serves to justify the project’s manager work and the service bought by the costumer, as well as all the future anxiety and arguments that will arise as soon as the deviations over the planning start to happen.
In view of this, some years ago new approaches of project management appeared. They were based on a higher collaboration with the customer and on the capacity to respond to changes, instead of strictly following a plan (Agile Manifesto, 2001).
Similarly, if you create a company, a long-term business plan is usually a fantasy work. There are many factors out of your reach in order for things to turn out as your business plan states (competition, world economy, new laws, customer’s behaviour, etc.)
There is a misleading assumption that it’s possible to rightly plan big projects. But in this type of projects, most of the requirements are not obvious until you have progressed to some point. Before starting, there is usually an enough amount of uncertainty which makes the planning have no sense.
Moreover, many times we assume that when there’s a plan, we have to follow it as if written in stone, and this in some way blinds us to new opportunities and better approaches.
It makes much more sense to start a project planning what you already know (that can be very little), obtaining the first results and incrementally iterating over them until you reach the desired outcome.
Instead of waiting to have a perfect final result, something which never happens, you can quickly produce an imperfect result and, in successive stages, keep improving and shaping the product or service until you reach an optimal result.
GTD comes up with the Natural Planning of Projects, in which you only have to establish the very next actions for each part of the project that can be in motion at the same time.
When you find yourself facing a new project, in which you aren’t aware of many things, be agile. Decide what you can do now and do it. Start as soon as possible. Take brave decisions, without waiting to have the perfect solution, and move on. Put the car in gear and, little by little, start steering direction until you get to your final destination.
Act more and plan less. Enjoy the trip and learn a lot.
2 comments
I was born and raised using the Waterfall approach, which worked just fine until I started taking on the responsibilities of a Project Manager. When you are only responsible for one portion of the project, you need only be concerned about making your dates, what you are dependent on, and who is immediately dependent on you. As a result, not only were requirements and outcomes necessary to document, but we had to use Gantt charts and sometimes overly complex schedules to get everything done. One mess up and things became very difficult. There was very little room to learn, grow, and expand on the original idea once you had it.
This type of environment made it impossible to work on what you could given the time you had available because everything was dependent on something and timeboxed to a point where free-thinking and creative actions were not part of the plan.
In contrast, I have found Agile and the use of Scrum to be a perfect fit for GTD, as it focuses on goals and a project is nothing more than a group of related tasks. In the end, everything is a task with some tasks needing more time and attention than others.
One function I could use, but is not currently in FT, is the ability to indicate if one task is dependent on another task. For example, a parent and child relationship. If I attempt to start the parent before the child, FT would notify me that I cannot complete it until I complete the dependencies below. By the very nature of this relationship, children have a higher level of importance to be completed because the parent cannot be completed before the children. Makes it real easy to see where I should put my focus and get things done.
I was born and raised using the Waterfall approach, which worked just fine until I started taking on the responsibilities of a Project Manager. When you are only responsible for one portion of the project, you need only be concerned about making your dates, what you are dependent on, and who is immediately dependent on you. As a result, not only were requirements and outcomes necessary to document, but we had to use Gantt charts and sometimes overly complex schedules to get everything done. One mess up and things became very difficult. There was very little room to learn, grow, and expand on the original idea once you had it.
This type of environment made it impossible to work on what you could given the time you had available because everything was dependent on something and timeboxed to a point where free-thinking and creative actions were not part of the plan.
In contrast, I have found Agile and the use of Scrum to be a perfect fit for GTD, as it focuses on goals and a project is nothing more than a group of related tasks. In the end, everything is a task with some tasks needing more time and attention than others.
One function I could use, but is not currently in FT, is the ability to indicate if one task is dependent on another task. For example, a parent and child relationship. If I attempt to start the parent before the child, FT would notify me that I cannot complete it until I complete the dependencies below. By the very nature of this relationship, children have a higher level of importance to be completed because the parent cannot be completed before the children. Makes it real easy to see where I should put my focus and get things done.
Hi Cyrus,
Thank you so much for sharing your experience and thoughts an Waterfall/Agile/GTD management. I totally agree with you.
As a Project Manager I understand the importance of defining task dependecies. At the moment, we've decided not to include that feature because it adds complexity for the average user. However, we reconsider everything from time to time ;)
Hi Cyrus,
Thank you so much for sharing your experience and thoughts an Waterfall/Agile/GTD management. I totally agree with you.
As a Project Manager I understand the importance of defining task dependecies. At the moment, we've decided not to include that feature because it adds complexity for the average user. However, we reconsider everything from time to time ;)