When it comes to software development, product teams are better than project teams. I’ll explain why.
Seen This Before?
Have you noticed a pattern that most organizations use to build software? They assign a project manager to prepare the project charter that broadly defines the scope, cost and schedule. Senior management approves the charter, and then they assemble a team. Developers, analysts, QA testers join the new team even though they may be winding up other projects. Management assigns an architect. They might also assign a DBA, network and middleware experts on a part-time basis.
Figure it Out
Now let’s suppose this is an existing application where the team is adding some new functionality to it. The team begins by figuring out how the application works in its current state. They review the system documentation, requirements documents, test reports, etc from the last project team that worked on this application.Typically it’s a collection of MS Office documents on a file share. Systems analysts give a demonstration or two to the team to demonstrate what it does.
So the architect and the developers then try to match what they see in the code base to what they saw in the demonstration. “Pradeep wrote most of this, let’s ask her.” “Oh we can’t. She’s fully committed on another project, and we can’t get any of her time.” The team burns through several days and thousands of dollars just trying to come up to speed on the inner workings of our application.
So eventually they make the changes, do all the QA testing, and get ready to deploy. Finally they deploy, wrap up, and the team scatters to the four winds to work on their next assignments. Sure, there may be a 30-day warranty period where they may need to break off from their other assignments to fix a bug. But that’s about the extent of their involvement going forward.
Some months later, more work needs to be done. Assemble another team, appoint another project manager, and repeat the whole process. It’s a very costly approach.
What About Ongoing Support?
As part of project closeout, the team transitions their work over to the application support team. The problem with this approach is:
- Support does not, and cannot, have the innate domain knowledge that the project team has accumulated through the life of the project. Oh sure, you can document everything, and conduct all kinds of handoff sessions. But inevitably a problem comes up that was not specifically documented. Who knew you can’t predict the future?
- Moreover, if the team did their job really well, and with a bit of luck, the system doesn’t break. It runs just fine for months until the support team gets a ticket. Any guesses as to how long it will take support to read the documentation, find what they’re looking for, just to begin troubleshooting? Oh, and if the system uses new frameworks or technologies that they don’t see elsewhere, it’s unreasonable to expect support to remember their training sessions from several months ago to figure out how it works.
The Problem With This Project-Based Approach
It dilutes the domain and technical knowledge. Team members don’t have enough time to develop deep expert knowledge of the application. At best they’re trying to remember how it works from when they last worked on it a year or more ago. Each time the organization decides to work on the application, a new team of people need to learn or re-learn the application. Any experts are few and far between.
Organizations typically use a waterfall approach with enterprise software projects. Changes are hard to incorporate because of commitments to a scope, budget and schedule that were established months ago. So much time has passed that the business case has changed, making those constraints out-dated.
The result is it’s hard to adapt to change. Sure, a good project manager will have established a change management process. But it means the team cannot keep what they promised in terms of scope, time and/or cost.
Projects are temporary by nature. The very definition of a project is:
A temporary endeavour undertaken to create a unique product or service.
Project Management Institute’s PMBOK (Project Management Body of Knowledge).
There’s nothing temporary about a software application. It’s always going to be there and require curation long after the project manager obtains sign-off.
Project managers are taught to worry about three things – scope, time and cost. They are usually assigned to two or more projects at the same time. How many times have you sat in a status meeting, waiting for the project manager to show up. When they do arrive after leaving another project meeting that ran late, the first thing they say is “OK, I’ve been out of the loop, what are we doing?”. That sure doesn’t inspire much confidence.
A Better Idea: Treat it as a Product
A software product has a continuous life. It has persistent teams where you have the same group of people work on the application on an ongoing basis. You have the same group of developers, systems analysts, architect all working together. Over time this team develops deep expertise in the application and the business domain it serves. The end result is lower costs owing to shorter time and less effort to implement changes. The team does not have to go through the learning curve again and again. Sure, there will be some turnover of team members, but not much more than 10%. That’s far better than 80% or 100% with the project-based approach.
The leader of the team is a product owner. A product owner is someone from the business side who is a business domain expert. They are very knowledgable about how the business uses the application. This person sets the priority of what work gets done, based on technical input from the team. If it’s a smaller application that changes very little, then the same team can also be responsible for another like-sized application in the same business domain. Continuity is the name of the game here.
A huge benefit of this approach is it enables a regular development, delivery and deployment cadence. The team can adopt smaller and more frequent deployments. This reduces the risk associated with larger changes. In addition, it permits faster and more timely feedback from the business users.
Now the team is no longer concerned with implementing the finished product in one shot and closing out the project. Now it can iterate. It can release a small piece of functionality and get feedback on it. Did it work the way the business was expecting? Does it validate the assumptions we made a last month? Make changes, release again, and get feedback.
Final Thoughts
The problem with software project teams is their temporal nature. The domain knowledge is lost when the team disbands and moves on to other projects. The project manager is primarily concerned with the project deliverables. Once done, they move on to other things.
Product teams are better than project teams. With a product team, you have most of the same people on the team for the entire life of the product. You have a product owner who is from the business side. The product owner and the team are primarily concerned with business outcomes. After all, that’s what we’re here for.