The project should definitely be dead, long live the product

In this paper, I aim to demonstrate the benefits of a well-tailored agile framework combined with a product vision to enhance delivery within organisations.

The Traditional methods might not be suited to new business realities.

I have spent most of my career in the project management world. The first projects I took part in were conducted through waterfall model. During such projects, leaders came up with an estimate of the project duration, right from its start. Needless to say that these approximations are most of the time the result of guesswork than that of a scientific, foolproof method. A systematic way to calculate the length of the project is to:

1. Breakdown the project into milestones and tasks;
2. Ask subject matter experts their opinions about the length of each task.
3. Try to have those experts opinions converge to a desired value or compute an average, when opinions differ;
4. Create a Gantt chart including tasks and milestones;
5. Sum up the durations by consolidating overlapping tasks.

Seasoned project managers lengthen the duration of the milestones or add buffers between milestones, in an attempt to secure their estimates. More often than not, the estimates fall short of the expectation as projects take way longer than estimated. I have personally experienced only one project completed within the allotted time, with a caveat: the project scope had been reduced… to fit the projections.

According to the standish group’s chaos report of 2015, 60% of project failed to meet their time target. But why is it the case?

According to Daniel Kahneman and Amos Tversky’s research on planning fallacy, we humans, are not very good at estimating tasks duration. We are much worse at envisaging risks — let alone navigating through the fog of uncertainties — due to an optimism bias. Additionally, there are two laws that can help us rationalise our incapacity at making time predictions:

1. Parkinson’s law: “Work expands to fill the time available for its completion.”
2. Murphy’s law: “Anything that can go wrong will, indeed, go wrong.”

All this factors, along with others such as project fatigue, lead the waterfall model not being the best way to manage project. The waterfall has another predicament: a lack of adaptability to unforeseen changes in the landscape. Imagine the desperation of a project manager when an unanticipated event (i.e., an event that he had not cautiously logged in his project risks table with the pre-planned contingencies that must go with it) happens mid-project.

Agile methods might be a better fit for your organisation.

The Agile methods emerged at the turn of the millennium. Rather than a set of pre-planned directives, the agile manifesto lists values and principles. Those ‘rules’ emphasise on collaboration, quality and adaptability. They have been designed to contrast with the waterfall model handicaped by :

• The need to document items before implementing them;
• The need to follow a strict decision making framework;
• The need to execute a strict planning;
• The need to foresee risks and design contingency plans and their budget.

These measures are designed to provide leaders with a sense of preparedness and control over event and thus assuage concerns about unpredictability: above all, business loathes uncertainty. But let us face it: it is humanely impossible to predict with confidence all the things that can go wrong during a project; it is also taxing, in terms of time and effort, to list of eventualities and come up with imaginary solutions.

Agile acknowledges the uncertainty in new endeavours but does not try to predict all events. However, contrary to what is we can observe in practice, the best agilists do spend a fraction of their time risk managing although differently. Instead, through Scrum they manage risks by adopting a dual approach:

• ‘Predictive risk management’ similar to waterfall, but without excessively investing time;
• ‘Event discovery’ by carefully observing events unfold and analysing (e.g., during the Scrum retrospective meeting).

Agilists believe that it is neither possible nor efficient to try to fully master the scope of a product or foresee every aspect of its development. For example, business requirements nowadays evolve rapidly. So do risks. Scrum divides the product development process into short iterations (2 to 3 weeks usually), during which the team learns and adapt to the risks and uncertainties that may arise.

Agile, along with its popular framework Scrum, invites development teams to primarily focus on the features the business needs the most. The team focuses on the core functionalities first, then adds new features overtime. Initiating the development process with the core or most crucial product features offers several benefits for the business:

• A head start on its activities vs a competitor who would make the choice to ‘wait’ for the whole project to be completed before using it;
• An opportunity to explore functionalities and find out which are most valuable for the market before committing to much resources in their development;
• A embedded change management process, Since users have time to familiarise themselves with the product during its creation before it becomes too complex;

Which is less costly for the users: having to go through lengthy documentation in a short period of time to start using a software or learn while using it as it grows and features are being added?

• Heightened perception of ownership because users are, most of the time, integral part of the development team and their business needs at the core of the feature design, thereby reducing chances of resistance to change;
• Easier risk management while the product is not yet too complex to deal with.

There is another reality that Agility and product vision take in to account and that is not in the nature of the project: A software product is always in a state of ongoing development. Between new features and bug fixes, someone needs to look after the application in the later stage of its life cycle. In the traditional model, the project development team hands over a sanctioned application, along with its documentation, to a Run team to make sure the application is working properly. Ceding a fully developed system to another team is a risky and uncertain process in itself:

• Although skilled at maintaining applications, the new team almost always ends up overwhelmed by the sheer complexity of the new application;
• It usually takes a lot of time to the team to deal with new adaptations of the software and the ticketing statistics usually look grim at this stage.

To mitigate those issues, the product vision suggests that the application development team should take care of the application during its entire life cycle. This is why roles such as DevOps, SysOps and now MLOps have emerged to encompass the responsibilities of building and operating.

Also, when Agile is coupled with a product vision (instead of a project vision), the need to compute a project deadline vanishes since the product is never completed. From the practical standpoint, the agile model and a product vision, if implemented diligently, promise:

• Process improvements through mid-course adjustments.;
• (chances of) A better planning by dividing the product into small features for projects still requiring a timetable because they are bound to finite resources or are part of a broader program;

For example, in a program, a set of applications may require a common framework (e.g., API to function properly). These developments can be prioritised in an agile model to deliver the whole program in the most efficient way.

• Higher quality of product because the team is not pressed to meat a deadline and more focus on delivering high value functionalities in the first place.

As far as business managers are concerned, agility and product vision must bring two advantages:

• Insurance to deliver products in a timeline manner;
• Increased flexibility to shift focus to new features guided by business priorities. For example, seizing a new technology opportunity (i.e., the ability to implement a generative AI solution in a novel use case).

In a nutshell, agility can serve your organisation in many scenarios.

Contrary to project management frameworks such as waterfall, agile models (such as Scrum or Scaled agile) do not come as a packaged, one size fits all method. The technology leaders can tailor a robust framework by choosing the roles, events and planning that suit the company’s business priorities, culture and talents. The agile framework can also evolve through time. The best agility framework is the one that allows business agility and helps fulfill business objectives: answering market needs via new offerings; or reducing costs by improving processes. Alongside agility, a product vision ensures the long-term direction and purpose of feature development. The product vision provides clarity and aligns everyone involved by communicating the ultimate goal, the intended value it aims to deliver to shareholders (business leaders, customers, end-users, etc.). It is also a powerful guide to help products differentiate from the competition on the market.

The added bonus is technology leaders can customise agile methods in business scenarios beyond software development:

• Need to deploy a new OS to your entire organisation? Why not do so iteratively?
• Need to change a heavy process in the manufacturing? How about starting small and study through metrics what happens along the way and adapt?
• Need to create a new business line and hire a full team? What if it starts with a small core team and as an experiment?

Considering that many organisations still use the project management model, it may be time to phase it out, for most scenarios. But there is a caveat. Like every tool, agile, if not implemented correctly, can be more of a liability to businesses. In a next instalment, we will discuss how to adapt and supercharge you agile framework for optimal productivity.