This post is a followup to my tweet on possibly scrapping projects. This post is particularly aimed at those who want to engage a team in software development project work for them. It may also be of value to those who do the work.
What is a project? According to the PMI website, this is what we find:
It’s a temporary group activity designed to produce a unique product, service or result.
A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.
I want to focus on the “temporary” and “defined scope” part of the definition as I believe this to be center to the conversation. Scope is the amount of work/features/functions/etc that we agree need to be completed in order for the project to be done. Fixing the scope inherently makes the project temporary as at some point, the scope is met and the project ends. In non-product development disciplines, the defined scope most often equates to what is required for the item to be usable. On the surface, this seems simple and straightforward enough but its important to note that in these disciplines, usable very often also means finished. For example, the scope defined for building a bridge would include the fact that bridge is usable (it can convey people from point A to point B) and to be usable, its needs to be finished . By and large, very little to no additional work will be done towards its original purpose. The product is not finished until the project is finished. There is no use for unfinished bridges except for pretty pictures.
This behavior does not necessarily hold to form in software development. In fact, (largely) unfinished software is used every day in many spheres of life and we have no problem with it at all. Think of all the software you use, personal or commercial and all the updates you or others make to it. It doesn’t matter whether its some application you created to help automate some personal activity or business software that you are involved with. It doesn’t matter whether its software for internal use or to be distributed to a mass market. Software evolves and evolves quite rapidly. We are continually adding stuff. The only time it doesn’t is if its a class assignment or the software is no longer being used.
Why does it evolve so quickly and often? It evolves because in spite of our skill and adeptness, we can only see so far into to the future as to anticipate our needs. Even when we enumerate all the user stories (if that’s what you do), we still end up discovering as we go along. Software development is by and large an exercise in discovery. It is critical to gain a true appreciation of the nature of work one engages in to fully exploit it. In addition, the software development tools available to us allow us to make changes to our systems faster than we’ve ever been able to and this only going to improve as time and technology progresses. Unfortunately, we still rely on (industrial age) methods that predate software development to manage how we actually do the work.
So why does this matter to you dear client? Because I believe that you shouldn’t be ignorant when working with those in my profession. You can decide to kick-off a project with some defined scope upfront and then lock it in but we’ll charge you for every change request you submit, tell you “it’s out of scope” or pull something out to put what you want in. When we’re done, you’ll have a product that is usable but unfinished because you’ll realize that there were things that you missed that you now want that may be even more important than what you have. Those of us who have done this for a while knew this would be the case, but you wanted a project didn’t you. Because you are human you are going to feel unsatisfied and disappointed but we’ll remind you that this is a project and that you (not us) determined (fixed) the scope. Because you really need those features, you’ll decide to kick off another project with us. You’ll make subtle changes to the contract with us to protect yourself and the cycle will just repeat itself. The cycle will most likely repeat itself a couple of times. I hope it doesn’t lead to low-trust and a contentious relationship between us but in many cases it does. But hey, you decided you wanted a project.
On the other hand, you can decide to break out of the project mold and just decide that you are going to continuously invest in your product until it no longer makes sense for you to do so. We’ll work together as partners to identify what capabilities are needed first. We’ll develop and deliver those. Then we’ll identify what’s next and repeat the same process. We’ll change priorities as we go because we didn’t lock ourselves into a plan that no longer makes sense. We won’t waste time arguing about fixed scope, we’ll just get things done. We won’t spend hours having our lawyers review the contracts so that no one feels cheated. We’re in this together and for the long haul. You’ll still have usable unfinished product(s) as we go along but I think you’ll feel differently about things, in fact my experience strongly suggests you will. But hey, you decided not to do a project.
The choice is yours, I just want you know that you have options. Choose wisely.