Since the dawn of project management, the process has gone something like this: someone "draws" the end state of the project, lists all the actions needed to get there, and the team goes to work, dutifully checking off the tasks in order. It's a process that sounds so simple and straightforward that no one ever questions it. So much so that it's become ingrained in the way we work.

In technology, this is how most project management works. How a waterfall project is usually done. If you have important, long projects, this is the gold standard. Plan something at the beginning and carry it forward for months. Agile, as a movement, pushed back with the idea that you cannot commit that far in advance. It brought the idea that we should only do waterfall for two-week stretches (I'm only half joking here).

In the past, I have shared some criticisms of Agile and its accolades. How often a movement about user focus and flexible planning is blindly shoved down the throats of organizations. To be fair, “true” (whatever that means) Agile practitioners already recognize the state of things and are the best allies in a software project. Still, I think a lot of Agile is built on ideas and assumptions from "classic" project management practices. I would argue that we've got it wrong, focusing on an exact outcome and tracing our path to it is counterproductive, there's another way.

In project management, there are two fundamental concepts that you must keep in mind: scope and time. These are essentially the core dimensions of any project; what you want to do and by when. Despite what we are led to believe, these two factors cannot coexist harmoniously. You can either have a clearly defined scope or a clearly defined delivery date. Trying to have both is a recipe for failure, especially when dealing with complex projects that involve numerous variables and changing contexts. It's the failure to recognize this fact that leads to so much frustration.

How many times have you, as a team, finished what you set out to do, by the time you set out to do it for?

This should be a familiar story to many of you. In the traditional agile approach, teams start a sprint with a fixed scope and an estimated timeline. As they get deeper into the work, they realize that things are more complicated than they thought. Deadlines are missed and customers are left frustrated and empty-handed. So you add sprint after sprint to try to get the promised product across the finish line.

Instead of deciding on a fixed scope, it is better to prioritize the schedule. What would that look like? Pick a direction, a general idea, e.g. "add a new calendar to your application". Set a time by which you want it done, 4 weeks. Then start working on it, refining what the calendar looks like and how it fits into the broader context of your product. After some time, think about what you can accomplish by the end of the 4 weeks. Maybe you need to drop the import functionality, time zones, color tags, etc. Maybe you should just import the entire calendar as a widget. The urgency of the deadline pushes you to find a solution. 

Let the scope come from the time limits. Do not set a time based on the scope.

This approach requires a change in mindset. Both from a leadership perspective and in how you communicate change and set expectations with your stakeholders. Managers need to let go of the need to micromanage every detail and instead provide direction and allow the team to take ownership of their work. This not only benefits managers by saving time and effort on those long and boring sprint planning sessions, but also empowers team members and promotes a sense of ownership and autonomy.

Huge caveat. I'm aware that not all companies can adopt this approach due to contractual obligations or other constraints (such as regulations). However, most companies in the digital space, especially in the consumer space, have this flexibility. Digital products can be easily deployed, modified, and adapted, making it not only feasible but optimal to focus on time rather than an inflexible scope.

Traditional project management practices may have their place in certain industries, but when it comes to the world of technology and innovation, it is time to re-evaluate our approach. By shifting our focus from fixed scope to fixed time, we can avoid sprinting to nowhere and instead achieve predictable and satisfying results. Let's turn things around, stop obsessing over process and instead embrace a more flexible and time-focused mindset.