It’s often suggested to me (via Twitter, LinkedIn, work – thanks Karen), that I’m anti-project managers in Agile (or Lean). This is incorrect (although I am opposed to the way many project managers (and managers in general) actually work but that’s a post for a later date). I do however, have strong opinions on our usage of “projects” in software development. It is the project approach that often leads to the engagement of project manager. These feelings are right up with my thoughts on the usage of the word “resources“.
In the loosest sense of the word, a project can be anything. It can be driving to work, taking a shower or entering time at the end of the day. But we all know that’s a bit silly, we just call those activities. The PMI institute has a definition for project which I like but then uses a software development example that muddies things a bit.
So what is a project? I answer it this way: Is the scope (outputs) needed to achieve the outcome and end investing known – to a large degree – upfront? If the answer is yes, then it feel project-y to me. I’ll admit that this is probably incomplete, but it get’s me started in my assessment of what I am working on. For example, if I choose to remodel my kitchen and largely establish what done looks like from the onset, then I believe I have a project on my hands. How about porting a database from Oracle to SQL Server or moving from Java to J++ to C# (yes I’ve done those things and they are not pleasant)? What about upgrading servers from one operating system version to the next or developing an integration pipeline with a partner so that they send/receive files to/from a system? How about developing and delivering a software solution based on defined scope as is practiced by custom software development shops – and is probably the example PMI is referring too.
These all seem project-y to me as the outputs needed for outcomes to be met and investment to end are known upfront. The decision to stop investing is largely driven by the fact that certain outputs have been delivered. Hopefully outcomes are met as well. This doesn’t mean that discovery doesn’t happen during the process (a good reason to leverage Agile and Lean techniques) but the path is largely charted.
On the other hand, what about building out a supply chain solution or a personal health monitoring platform or a tele-medicine platform (my latest project er I mean startup)? What about starting a blog or having a family (ok now I’m stretching it)? Are these projects? Maybe if one takes a very liberal definition of the word yet I think not. These endeavors are journeys where the end is in often vague and obscure. In a weird way, we actually hope there is no end (at least not soon). We may have some ideas of the outputs needed but we also accept that we are (hopefully) going to spend a lot of time learning about more outputs needed to achieve our outcomes. This is exactly why I spent over a decade at one organization developing a single product. Tell me what’s temporary about that!! We stop investing when we are no longer learning (or making money or having fun).
Should you be approaching your work a bit differently? Are projects your only option?
PS: The project approach to software development can lead to a bunch of bad (organizational) habits but that’s for a later post as well.