The project-centric approach is the standard in software development. Many software developers have spent their entire careers following this methodology. However, just because it’s the standard for technology development, doesn’t mean it’s the best approach. (Read what we wrote in 2017 about projects vs products)
In fact, a product-oriented approach might be worth considering for your next software development project. Here’s why.
Defining the project-centric approach
Project thinking isn’t just pervasive in software development. It’s relatively ubiquitous throughout all facets of business. You can find it in everything from software development to home construction projects.
A project-oriented approach is all about delivery and output. The focus is on completing a project within the predetermined time frame, budget, and scope. There’s always a definitive beginning and end to projects, usually with a singular goal in mind.
The value proposition of project-focused software development is centered around setting expectations and delivering them within the predetermined boundaries (cost, timeline, and scope). Generally, companies are clear about what technology they want, and developers aim to deliver what they requested.
Another distinguishing factor of project-oriented software development is the people. With project-focused development, teams are formed on a per-project basis. Consequently, developers often work with people they don’t know, and jump to a new project before they’ve established much rapport with their current team.
It’s easy to see why this approach is so ingrained into business processes. A company tells a development team what they want, when they want it, and how much they want to spend. Then, a team delivers. So, what’s wrong with this approach?
The problem with the status quo: project-centric has to go
In project-oriented development, the output is often deemed superior to the outcome. There’s often very little room for flexibility and on-the-fly adaptation – which is critical in software development. Part of the project-oriented process consists of a lengthy analysis before the project begins in an attempt to mitigate all risks that could emerge throughout a project.
However, in our experience, things are never quite what they appear to be at the outset. For instance, when dealing with global insurance companies, legacy systems, and millions of customers, multiple parties interacting indirectly with insurance things are never foolproof. The rigidity of a project-oriented process can devastate end results because customer expectations are continually changing. Something decided a year ago might be obsolete now, but by nature of the project-oriented approach, there’s very little wiggle room to pivot.
A project’s success is defined by the deliveries presented at the beginning of the project – the most important metrics including staying within budget and delivering on time. Notably missing from these metrics is the actual value to your customers. Whether the completed project fulfills its intended purpose or provides bottom-line value isn’t the main focus.
Completion is the goal post, and once it’s reached, the development team will break up and move on to their next project.
The problem is that building truly functional software is a social exercise. How people interact can be the true differentiator. From the communication between the in-house and external development teams to the communication between leadership, stakeholders, and more – the ability to communicate effectively will unequivocally define the overarching and continual success of any technology.
However, a project-oriented approach doesn’t prioritize communication at all. In fact, it works to minimize it. Typically, there are conversations in the beginning and when it comes time to deliver, but the entire process is relatively antisocial, with developers each taking their own chunk of the project and working on it independently.
The product-centric approach to software development
The product-centric approach to software development is a fundamental paradigm shift. It’s all about outcomes and delivering long-term value to customers. With a product-centric approach, everything is incremental and completed in short cycles, so there’s always time to change course and alter the strategy to fit the current and evolving needs of the company and its final users. (Read our article on Customer-Centric Insurance Technology Lessons Learned from the E-Commerce Industry)
There is also inherently less risk involved in this approach because feedback loops and testing are integral parts of the entire process. Priorities can shift from cycle to cycle with ease. Learning about the customers’ needs is a natural part of this process. Thanks to ongoing team communication, a product’s value is tied to measurable profits and business objectives, like increased revenue, adoption, and productivity – not just project completion.
Instead of staying laser-focused on cost, the priority is getting the best ROI. To achieve this, keeping problem-solving front and center is critical. In a project-centric approach, problems are viewed very singularly. If there is a missing component in the app, the answer is to add the missing feature – no questions asked. However, in a product-centric approach, there’s always a level of problem-solving and investigation. The development team asks, “Do we actually need this feature?” or “What purpose is the feature solving?” or “Is there a different feature that better meets customer needs?” (Read our list of key questions to ensure the team is delivering a quality product)
Unsurprisingly, a Gartner survey reported that 69% of product-oriented developers agree that customer experience is a critical priority, compared to 39% of developers who work in siloed project-oriented environments.
Learning and improving is integral to a product-centric approach. Longevity is baked into the process because software development shouldn’t be a one-off activity. It’s an ongoing process. Since everything is incremental, it’s possible to scale with efficiency and continue to develop on the existing product with ease.
The backbone of the product-centric approach is the people, and this is where a unique approach to recruiting talent can make a world of difference.
Churn is an unfortunate, but expected reality
The project approach hinges on leadership. There’s no real camaraderie because teams are cobbled together on a project-by-project basis. Developers are focused on hitting deadlines and moving on to the next task.
At 13.2%, the technology and software sector has the highest employee churn rate of any other business sector. In high-pressure tech environments, churn can reach as high as 30%. A lot of this has to do with burnout and project cadence. A developer who just finished a sprint on a project shouldn’t have to immediately jump into another. Yet, in a project-oriented environment, this is often the expectation.
In the same breath, developer churn is inevitable and part of business. As a result, companies and projects shouldn’t hinge on the shoulders of a single developer. However, tasks are often siloed in project-oriented environments. What happens when the only developer working on a critical component of the project decides to quit? If no one is equipped to take over, it can lead to stressful and unsuccessful transitions – and lackluster results.
Cultivating lasting teams with a bench
At S4N, we’ve developed something we call “the bench.” Similar to professional sports, 10-15% of our developers are on the bench waiting to be called in to play. If a developer needs to take a break or step away, there’s always a prepped developer ready to tap in. This allows us to maintain momentum on customer projects without burning out our developers.
We also create psychological safety for engineers through ongoing training and development and keep psychologists on staff. This helps ensure our engineers aren’t bogged down by outside problems and can focus on their job with ease, establishing a predictable cadence and seamless product delivery. (Read How The Principles of Sports Psychology can Help Teams Build Great Software)
At S4N, we proudly adhere to a product-oriented approach and value teamwork and collaboration as fundamental tenets of successful software development.
When we start on any software development product, our team implements a feedback loop from the start and sets up groups of engineers to analyze the data and begin development right away. Our teams prioritize core functionality and the needs of the business and align the product with the business objectives.
The outcome is the creation of an internal engineering process around predictability and a steady cadence of product delivery, which provides stability and reliable expectations. Our product-oriented approach allows us to build a team that continually injects knowledge into your organization and enables us to adapt strategies and software to meet real customer needs as they evolve.
Choose product over project for measurable results
The mindset shift from project-oriented to product-oriented isn’t an easy one. Project management and completion are hardwired into almost every facet of business. However, software development requires adaptability, and a product-centric model provides that.
In our experience, our global enterprise clients have a far better bottom line and measurable results when they adopt a product-centric approach. If you’re interested in this approach for your next technology project, let’s have a conversation.