My Life is a Project?
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
In all seriousness... I don't quite take it that far... but I do tend to see things through a 'project' lens.
Earlier this morning I came across a great post by Scott Berkund titled 'Everything is a Project'. I liked the post so much (for obvious reasons) that I sent it out as an 'Interesting Post...' over Twitter. Several folks re-tweeted my tweet and a few folks commented. One of the comments came from Bob Marshall, aka @flowchainsensei. Here is what Bob had to say:
@flowchainsensei Way too many things are projects - especially projects. Projects are dysfunctional, wasteful and anti-flow. Let's put an end!
And my response...
@ mcottmeyer I think that the project metaphor can be useful when we don't have level investment across product lines.
Clearly this was way too deep a topic to explain in 140 characters, so I wanted to share my thoughts around projects and where I think they are useful... and where I think the concept is overused.
First... the simple definition of a project goes something like this... 'a project is a temporary endeavor, with a defined beginning and end, that is created to achieve some particular goal or desired outcome'. I'm pretty sure that definition came from the PMBOK, but I lifted the language from Wikipedia. Pretty basic and seems to make sense, but does it fit the way that our organization really does work?
Here is another example where I think projects are misused. If I am a small company that is developing a single product, and my primary mission in life is to keep that product updated with new features and defect free... is the work I am doing project work? I may be inclined to have a "UI redesign project" or a "Revise the login and authentication project". Are either of these projects? They could be, but because of the nature of my environment, what we are really doing is ongoing product development.
These kinds of work would probably be better considered product development or operations.
But... what if I am building a custom solution that will be handed over to the customer at the end of the contract period. I may provide ongoing support, I may not. In that kind of environment, it might make sense to have a project manager and a charter... a formal risk mitigation plan and at least a high level schedule... even in an agile environment. I have touch points with my primary stakeholders (no, not my wife) and they have certain expectations about how their money is going to be spent. This sounds like it could be a good place to have a project.
Let's consider another example... What if my product company grows up and now we are supporting 20 different products and have 40 to 50 teams. Your product sets are not all the same level of maturity. Some are established and don't need incremental investment.. some are less mature and require new features to be added to meet market demand. The point here is that the investment in each product is not level and the business is making strategic decisions about where it will spend its money to get the greatest return. I think that projects make sense here too. We are making an increment of investment, over a pre-defined period of time, to get some desirable outcome.
So... do I think that projects are overused? Yes. Am I willing to say that all projects are bad and that the entire metaphor is outdated and always inappropriate? No. Like most everything we talk about here... you have to understand your context and not apply concepts blindly where they don't make sense. If your work is more operational and ongoing... that is not the sweet spot for project management. If your work is well defined and discrete, and it lends itself to the problem that project management is designed to address... I think the concept is valuable.
It is not a one size fits all world. I look forward to the conversation.
First posted on Mike Cottemeyer's Blog