A project begins with an idea and if the idea sounds promising, it can be initiated to make it into reality. Intriguing as it may sound, the word “project” used to mean before (pro-) acting (-ject). In the 50s, project management became more acceptable with the introduction of various techniques within the manufacturing and defense industries. This extended the definition of “project” to include both planning and execution and has since transfigured hundreds of techniques across many other industries.

Don’t worry, this is not a project management lecture. However, an understanding of the current state of project management should provide some context for why I wrote it.

Results are always measured against accepted criteria. Successfulness is ultimately perceived as how closely the project manager follows the initial plan—scope, time and budget.

This seems perfectly reasonable—at first.

But what about those projects that fall at par with timeline and budget, and within the scope, but still does not succeed?

The objective is not to deliver projects but to deliver value through the products

Recently, I was employed to manage a Learning Management System, that was contracted for development by our agency, while parallelly supporting the client business needs. The project was scoped, budgeted and a tight timeline was proposed for phase-wise deployment. The application would be serving dozens of schools right after the reporting system was done, while the quizzing platform would be developed parallelly. Needless to say, our gusto for LMS began with a verve. However, the evolving requests from the stakeholders to make the system better and at the same time keeping the release date unaffected became a challenge. The team was struggling with making informed and product-centric decisions. Eventually, client satisfaction deteriorated and it negatively impacted the product-business goals, stalling the project as a whole. While retrospecting with the team, I realised most of the team members were focused more on moving tickets to the ‘Done’ state rather than thinking qualitative against a feature for failure and/or edge-case scenarios. It could have been more fruitful, had we thought around the feature and what difference it would make to the end-user. We failed terribly!

Project thinking is fairly all over the place. People especially in information technology, have spent a huge chunk of their career focused on projects and project management. Large organizations often have PMO departments, exclusively on project management. It’s not incomprehensible, because project management has been in business for a very long time. And it's a natural human tendency to think of Project as: things we need to get done.

Service-based agencies often find it tough to introduce the product-based thinking in teams.

The project mindset defines success from within, using internal measurements that are more around task management and how accurately the primary plan was followed. The focus of project thinking is ‘delivery’. This could be the delivery of really anything, a specific feature or software as a whole or from rockets to food. And since the only aim is delivery, the primary parameters to gauge here are the schedule and timeline. Project management is specifically driven on the output​, and is evaluated by how precisely we were able to predict the timeline and then deliver the specified output on the contracted schedule. Success is largely defined as taking the specs of something beforehand, setting up a schedule with milestones all along the way, and then hitting those milestones.

What do your customers value? Projects or products? The objective is not to deliver projects but to deliver value through the products—products that ultimately lead to higher revenue and lower costs for the organization. Products that are so great that your clientele grows and existing customers are retained.

Transitioning from a project to a product mindset demands a shift in thinking long-term goals rather than short-term. Instead of focusing on timelines and dates, teams with a product mindset focus on outcomes rather than output and create a strategic vision and roadmap that maximizes the ROI.

We stick around the goal we wish to achieve or the job that has got to be done. Because we’re concentrating on the outcomes rather than the outputs, it becomes more challenging to put time constraints around the delivery items, at least beforehand. Primarily because we don’t necessarily know how we’re going to attain the goal in the first place.

Service-based agencies often find it tough to introduce the product-based thinking in teams. People believe that they are working on short-lived software applications that could range from a few months to a year and when it’s done, they can move on to another project. The application is hardly managed as a 'product', that needs to live inside production for several months, once the project is brought to a conclusion.

This kind of thinking can be quite the shift, especially for those who have spent a lot of time focused on projects and project management. Generally, people are not comfortable with the uncertainty of not having structured timelines and schedules which can be monitored on a daily basis.

The raison d'être of product development is to deliver value to users and customers.

So how do we do that? How do you inculcate a product-centric approach?

Almost every product involves some level of project management process. We have to keep things moving along and it is (unfortunately) unrealistic to assume that we can work in an environment where our stakeholders and partners won’t expect some dates or commitments.

The key here is to make project plans and commitments only when we can do it with a high degree of confidence. So, instead of adhering to a singular path beforehand, we only commit once we have validated what we are really doing and have a chance to fairly understand how it will impact the end-users. Ordinarily, you are already a sprint or two into the work, when you realise the broader picture. This may feel surprisingly late in the process, but it is at this point where estimates, plans and commitment can actually mean something.

Learning from the previous experiences, the team now realized what drives the project, is the product and not vice versa. Fortunately, we were given another opportunity of building an LMS for a US-based educator. The team aligned themselves with the product-centric approach, critically examining each assignment before giving out the estimates. A proactive consultation around the envisioned product allowed the stakeholders and scrum masters to foresee most of the snags, enabling them to make business-decisions on time. This helped avoid having any serious repercussions on the business operations.

In a nutshell: Let the team do a proper discovery and research before asking for commitments.

It is equally important to help others understand the benefits of product-based thinking. There is a reason many people ask for dates and timelines- part of it is because of old habits, but there are times when it is of utmost importance for the sake of business and allocations. So, we need to comprehend the idea of timelines in these cases. If it is to promote the sales for a product, the focus should be on the higher level story rather than specific features. If it is to mitigate risks, maybe we need to help people understand that the real risk isn’t missing a date, it’s missing the mark completely on what values we are striving to deliver.

When all is said and done, the raison d'être of product development is to deliver value to users and customers. Often, we don’t know what exactly is going to deliver that value though. To think that we can come up with the right solutions up-front, sometimes a year in advance, is pretty unrealistic.

Ping us at [email protected] to know about how we can build an innovative web property using Drupal 8 and our efficient project management techniques.