Read my book

I wrote books about Webpack and React. Check them out!

Wednesday, June 11, 2014

Projects Are the Antithesis of Projection

It is a well known fact that software projects fail more often than not in some way (ie. Chaos Report). Either deadlines are missed, objectives are not reached, budget goes beyond allotted, you name it. If you are a software developer, you have likely blown up a project at least in one of these ways.

Essentially a project is a control mechanism. By definition it is something performed by a temporary organization that should reach the project goal. Once the goal is reached, the project is done and closure is reached. The organization may disband and move onto other projects.

What if there was some other way? Who says software has to be developed within projects always?

Projects Are the Antithesis of Projection

Compass by The B's (CC BY-NC)
Projects might work for one-off thing that you can implement and forget. This is missing one key point, however, software evolution. A project might reach its goals on time and on budget but what about the future? The way I see it projects are an antithesis to this kind of projection. They encourage to focus on short term while forget about long term.

That said maintainability concerns can be taken in count during project. It is just that by definition they don't encourage to take the long term view. As projects are performed by temporary organizations there might not be commitment to reach for the best long term result either. And what is the best long term result even? What looks good for the project/product owner might not look good for contractor.

The tried and true engineer's triangle applies here. You always have to make a compromise between good, fast and cheap. It simply isn't possible to get everything at once.

Alternative Control Structures?

Control structures by Martin Fisch
(CC BY-SA)
Given projects are about control can we organize development using some other structure? Projects by definition lead to side taking. There must be some product owner and the people that actually implement the project (ie. contractor). The goals of these two parties are often different and can lead to conflict.

Let's say we build a project based on a fixed set of requirements, fix the cost and schedule. After that it's up to the contractor to implement the project within those constraints. The problem is what if the requirements change during the project? If the cost and schedule are fixed and the product owner is not willing to compromise, this could lead to serious issues. Something has to give in.

What if instead of pushing and fixing we did something different? The product owner likely has a good idea of the product goals. An alternative control structure could be developed based on those. Rather than fixing everything upfront and then trying to find the cheapest company to do the work, something else could be tried. How can you achieve this without taking sides so clearly?

What if you tie the destiny of the product owner to the destiny of the contractor somehow? Instead of aiming for something as cheap as possible to maximize short term gains you would think long term. One possible solution is to treat the contractor as a business partner. In product development this might mean something such as profit sharing.

You could also build something on weekly basis (ie. charge per week against results). Make the arrangement so that either party may fire the other after each week. If either party is disappointed for some reason and wants to move on, let it happen. This forces both parties to focus on building trust if they want to keep it going on.

There are still sides but at least they are aligned better than in traditional projects. There is a clear continuum and it is in the best interests of both parties to maximize their efforts to gain trust. That is essential for maintaining a long term relationship and minimizes some of the risks. Now that you can think forward even projection becomes possible and you can think about future.

Conclusion

I think it is very interesting to follow the current #NoProjects discussion. It feels like we might be onto something here. I am not saying projects could not work in some contexts. More often than not it feels like a construct that has been developed to maximize the wrong things. It's hard to project with projects.

This post was inspired by Allan Kelly's post on the topic. Also the comments on the blog were very insightful so I recommend checking that out if this sounds interesting!