Thoughts on Words: Project
Thinking is shaped by the words we use. Management thinking is shaped by the words managers use and are used to. If we want people to change their mindset, we must stop to use words that carry a history of bad meaning with them. Let’s start to create a new language to talk about development that explicitly avoids mistakes made in the past.
Project
Project as a concept was devised in a time when management still thought they could execute an endeavor according to a detailed plan. This worked in the times of Henry Ford, when employees were glad to be paid, and customers accepted that their cars were black. Both is not true anymore. Employees seek mastery and purpose, and request autonomy instead of detailed plans. Customer value today is rather discovered than simply produced. Uncertainty is the only thing you can be certain of.
A project is a temporary organisation formed by people working on a sufficiently identified goal. As long as projects were few, changes infrequent, this paradigm had its use. Now, changes are the norm, and every enterprise runs multiple projects. These don’t function as temporary organisations anymore when each member is belonging to multiple organisations at once. I don’t see the concept adding any value anymore, yet it brings this whole history of misconceptions to the table…
- The idea that costs and benefits of development work could (or should) be calculated in advance.
- The notion of an end date when a product will (or should) be finished.
- The early commitment on scope, decoupling demand from delivery.
- The idea that one could calculate the resource usage of people, summarise the data for some resource management, and even do that for multiple projects…
- This list is not complete.
To briefly sketch an alternative:
- Instead of costs, we should talk about incremental investments. Instead of benefits, we should identify our real optionsand adapt these continuously to our learning.
- Product versions are released, no product is finished anymore. We need to ship fast, and often. The best way to gain knowledge is frequent feedback.
- Instead of pre-defined scope, we need incremental, deliberate discovery of value, and rigorously validated learning to deal with the unknowns.
- We need to balance demand and throughput instead of resource management.
We need to watch the baton, not the runners..
14 Comments
Mike
October 12, 2011I can understand why you feel there is a need for a new language and in a lot of ways I agree. However, here are some of the ways I don’t…
#1: We should stop treating members of organisations (management etc) as babies who cannot digest a simple change in meaning and for whom we need to constantly puree down concepts. I perceive something of this from your post, its just a perception. If we focus on the language change, it becomes about the language and soon you may have Certified New Management Speak courses. Yet we would deliver less value.
#2: Support the supportable and let the unconvinced perish – there are many organisations out there for whom none of the stuff you mention is off limits (in any language!) As change agents, we should seek them out and help them prosper beyond belief. We operate in an empirical world (seeing is believing after all). Those organisations for whom language is a barrier, can see results and relevant exemplars to emulate. That is far more valuable than simply changing the words we use, because if they cannot adapt after seeing examples, they were unsaveable anyway. Corporations also have a right to die – though some are perishing but are too dumb to know it (a bit like dinosaurs).
#3 You make contentions (employees seek mastery) that are made in books that sample a tiny tiny tiny set of the worlds workers. I disagree ALL employees seek mastery, not even a majority of employees seek mastery. If they did, we wouldn’t be in the state we are. My feeling is most folk want to do as little as they can get away with and still get paid. Industrial history has exploited this and perpertuated generations of workers disconnected to anything of value beyond the paycheck. New language ain’t gonna save these folk. Only they can save themselves. Of course they can seek knowledge (which is now abundant) in different ways of working, priorities etc but they have to make the move.
Overall I think you make good points though its a case of preaching to the choir.
Olaf
October 12, 2011Mike, thanks for your comment.
#1: I’m the first to agree that treating people as infants should be stopped:-)
Change of language to me is just a means to change mindsets…
And, in some cases, I think we should avoid using words that do more harm than good. Project is a term that I feel belongs to that category, and this is not limited to software development (though I can’t speak of all uses of the term as I don’t know all “projects”…).
Certification, by the way, is another of these terms and concepts we should abandon sooner rather than later! I’ll take that as a suggestion:-)
#2: I have no evidence of the dinosaurs being too dumb to notice… Exposing the empirical world in contrast to serving wrong beliefs is part of what I’m trying to achieve. Language is incidental, after all, and not the most important of our problems… On the other hand, it’s symptomatic of our mindset, and it does shape our thinking. As humans, we tend to categorise new ideas according to our experiences and habits, with a preference to place new ideas into our own comfort zones (if we feel the need to go with them at all)… When talking to project managers, I try to avoid a “I’ll be agile if I use stickies and turn my gantt chart 90 degrees so that I have a backlog” effect by telling them quite clearly that I see no value in having projects in an agile organisation. So far, that has lead to fruitful conversations.
I want them to leave their comfort zones and “prosper beyond belief” (beautiful phrase btw, thank you). This is my way of doing that:-)
#3: You’re totally right that I’m observing anecdotal evidence. I observe the people and organisations I work with and talk to and read about. You might be right about the attitude of a large percentage of the world’s workers—I do not know. I meet more and more people who sense that how they work or are told to work is wrong. They need to change it themselves. We are coaches, we are here to help. Part of this is putting into words what I observe in a way that lets others share my understanding. So that, when they seek knowledge, there’s something useful there to find:-)
Chris Matts
October 12, 2011Olaf
I agree with your sentiment. I’m not sure if we need new language, I think we need to be careful about which of the existing language we use. As someone who is guilty of inventing some of the worst language around I feel I could have chosen words more wisely.
I think the problem you are describing is how we name new things. The name is based on something similar that already exists. As a result we have many meanings covered by the same word. “Project” is one of the worst.
As you say, when we spot that a word is hiding the meaning behind another meaning we should find a better word.
As for project, I’ve allways liked the name “Bernard” but that is why I should never be allowed to name things.
Chris
Olaf
October 12, 2011Chris, thank you for your comment.
I try not to coin new words (for similar reasons). I try to find better ones:-)
The point here is different: I don’t object to the word, I think the whole concept is no longer useful in those cases where I see it applied.
So renaming it to Bernard… Would not help;-)
Jens Hoffmann
October 12, 2011Since we are talking about the right usage of words, I would propose to define the context first. I think you are talking about software development projects and not about projects in general. Otherwise, I’m afraid you are stuck in the pars pro toto trap, which is common among the agile development aficionados.
In my opinion, the term “project” is still valid and should be used when appropriate. The problem I imagine you would like to solve, is in my understanding not the wrong word, but a wrong perception and disability of managers and makers to sense the situations, they have to cope with and a lack of ability to choose and implement the right approach and actions to the right problem. If you really want to achieve a real leap forward, than you should not ban the word “project”, but foster and communicate the differences among “standardized operations”, “projects” and a flow of continuous incremental changes. For the last, we are lacking a short and descriptive word, unfortunately.
The accepted definition of the the term “project” is: “a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. (for exact sources: wikipedia).
This definition is not assuming, that a project executes an endeavor according to a detailed plan, in a stable environment as your post suggests. This definition separates the project as a temporary activity to create something new, from the standard operations prevalent in most organisations. Which is a necessary and still valid differentiation. Especially for industries where incremental change is simply not feasible or comes at high marginal costs, like plant engineering or construction.
The word “project” becomes problematic, when management or makers are not able to recognize when they are operating in a quiete stable environment or when they are operating in a highly volatile environment. In which they have to react with a high level of adaptability and continuous delivery of incremental improvements.
Most software development projects are falling in my understanding, in the “flow of continuous incremental changes” category. Most commercial software systems are not constructed at one point in time, but have a lifecycle which spans between 5 to 15 years. During this lifecycle they are not just in standard operations but under permanent construction. Permanent change not to fix errors or because the team couldn’t get it right from start, but because the environment, the requirements or the possibilities are changing, and the business wants to leverage the avantage. The same applies more and more to manufacturing, where technologies like 3D-printing are enabling also a continuous and very fast design-build-test-run-cycles with low marginal costs.
What Agile Management has to offer is a concept how to steer and control these flow of changes in an economic and productive way. This is the point, we should make to management.
Olaf
October 12, 2011Jens, thank you for your comment. This was what I intended by not constraining my musings in a specific context:-)
The reason for this is that I feel the project concept is used outside of the context (and maybe century) it was intended to be used in. People try to contain uncertainty by defining a project context around it, and work on the symptomatic consequences of this misuse… And this is not limited to software development. I see this in all sorts of endeavours that would be better off without it.
So yes, I’m talking about the general use of projects, but not about every use. There might be cases where defining a project adds value and improves outcome, but the way our world changes will limit the number of these cases further in the future.
So we should discuss where having projects is appropriate (you seem to have a better idea than I do) and (in-)validate my thesis.
I totally agree on the way you phrased the problem I’m trying to solve (“wrong perception and disability of managers and makers to sense the situations, they have to cope with and a lack of ability to choose and implement the right approach and actions to the right problem”), but I do not really see value (yet) in the distinction you want to make between “standardised operations”, “projects” and “a flow of continuous incremental changes”. As long as we’re talking about knowledge work (this is what I’m interested in and working with, and I don’t see why projects should be done outside that domain), I see operations are not improved by being standardised, and what people call projects are really just roughly grouped incremental changes aiming for a more or less uncertain goal. For this, we have words: discovering value, validating assumptions, learning, delivering products incrementally…
You mention the definition: I read on Wikipedia: “collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim”. Enterprise means organisation (which is difficult when you belong to more than one at a time), particular aim sounds much more certain than our business world usually allows, and carefully planned is something (notice the use of the past participle) that we both know does not work. Where’s the added value? I’m reading “according to a detailed plan, in a stable environment” there, and the core problem is that most people are used to do that. We could change our understanding of the term… But I doubt we would succeed. Take “catholic” for comparison. A nice word, meaning “according to the whole” or “in general”… Could we change the perception of that word against a world-wide organisation using it differently? So unless the PMI starts to change their understanding of the term… I’d rather not use it anymore.
Do you know a plant engineering or construction project where the people working and planning don’t inspect and adapt, don’t deal with uncertainty? What I perceive in IT is a big misunderstanding of projects done elsewhere… And look how the construction industry struggles. Are they really doing well using the project paradigm? I don’t think so.
I want to close with the most important sentiment of this very long reply: I agree with almost all of what you say, I just draw different conclusions.
We should definitely continue this… Elsewhere, and face to face:-)
T. Heller
October 13, 2011I agree that “project” is an antiquated model and doesn’t truly fit the nature of delivering value to a business and software development. Projects are temporal, they begin and end in relatively rapid cycles. Teams, systems, businesses and customers do not (typically).
In typical business and finance models, projects (if they must exist) are simply a container for funding and scope. The container exists to give context to a business plan, budget, training plan, rollout, etc. Ideally, features and stories should flow through standing teams who deliver value (working software) through a customer group, system/asset or other permanent model. Maturing business processes and finance models to enable this will be a critical to waste elimination and efficient delivery for an enterprise.
Olaf
October 13, 2011Tim, fully agree. Thanks for commenting!
If all we need the word project for is to frame investment and scope (which are better treated independently for greater flexibility) we should stop using it altogether and talk about what we’re doing instead of keeping expectations we no longer want to be in place…
Geir Amsjø
October 13, 2011You rise an important question here, Olaf! I am 100% with you – words shape our mindset. Agile implies radical change most places. Change is painful and will meet resistance. People in certain roles will actively try to make the need for change as small as possible.
I have observed this several times. In Norway we have very good agile conferences (in Norwegian) and what I experience is that the representatives for the agile projects (very often the PM) are satisfied with “just a little agility” (2 releases a year, a lot of up-front commitment, separate test team etc..). And they tend to defend their position. They talk about “doing earned value in agile projects”, but never mention retrospectives, TDD, MMF etc.
I don´t like to treat poples as children, but I believe keeping words that symbolise “good old times” tend to slow the change down, or even stop it. The most ambitious organisation I have seen simply goes from “project management” to “product development”.
One concrete problem with the project mindset is that we create a temporar organisation. This result in a lot of waste and it is unnecessary in many cases. Software systems will always evolve and may be developed in a more permanent (agile) organisation. This long term view will create a long term responsibility and long term thinking, resulting in more ownership and much more attention to reducing technical debt. Which is vital, you know!
Olaf
October 13, 2011This is exactly my point, thank you for the support:-)
The “temporal org” thinking is what makes projects create waste rather than value.
Bruce Scharlau
October 15, 2011Olaf,
I can see where you’re coming from and understand your sentiment. The word ‘project’ conveys lots of assumptions and preconceived notions, which don’t usually help deliver a successful project.
However, there is a central problem with your solution. From what I see on the blog and via twitter, which of course will not be a true ‘picture’ of you, your decision to not use the word ‘project’ will not have the desired effect. Your not where the PMI folks are. You’re not engaging them on their turf so to speak. In order to get them to ‘see the light’ we need to be like missionaries and go find the management folks who need our help, but don’t realise it, and show them solutions to their problems.
Hanging out with the converted is great, and really helps boost your morale, and I love it as much as the next person, but sometimes we gotta go into the dark to offer a torch to the others, and lead them into the light. Ok, maybe that came over too strong, but you get my idea I’m sure.
We need to use their terms and show them that they don’t have to mean the same thing they thought they did in the past: we can ‘do projects’ and work on one at a time and not be split across multiple projects. Anyways, go out into the dark and save a PM.
Torbjörn Gyllebring
January 15, 2012Hi Olaf, great post, my thoughts.
Your first point, that needs stressing is the weak form of the Sapir-Whorf hypothesis that language can and will influence thought and behavior.
This is the importance of ‘framing’ if we want to encourage certain behaviors and mindset, selecting the proper frame to draw attention to desirable properties is vital.
For us to be able to select the right frame and start nudging things in a beneficial direction we must first find at least some agreement concerning what purpose “Projects” actually have.
I posit the purpose of projects as solving problems.
Most people I’ve talked to agree to the following (short) definition:
“a Projects is a temporary endeavor having a defined beginning and end, constrained by some mixture of time, budget or deliverables, undertaken to create value or change”
Jerry Weinberg have observed that in essence this mean taking a system from a initial (perceived) state ‘A’ to some later desired state ‘B’ and the primary means to do so is by working on
* the perception of ‘A’
* the desires for ‘B’
* the realities of ‘A’ or ‘B’
with the most common real world solution being some mixture of all the above.
Project management thus is the application of these (and other) heuristics.
Can we find another frame for this process that brings with it better connotations?
I believe we can, a key observation for me is that the heuristic above is equivalent to the approach to solve a *problem*.
I’m very fond of Jerry’s notion of a problems as the difference between things as desired and things as perceived.
Ergo projects are formalized, measurable, solutions to problems!
Given that our desire is to solve a problem is there a different frame nudging us towards constructive collaborative actions?
My tentative answer is that yes, such a frame can be found and comes in the form of ‘initiative(s)’.
Why initiative?
Initiative brings with it the frame of initiating action & responsible decisions.
Further initiative is taken not assigned.
I propose we stop starting projects and start encouraging initiatives to solve problems.
Dan Mezick
January 19, 2012Hi Olaf and Friends,
This post is a [fascinating examination of language]; here is my take. For the record, I might have just labeled this post with a NAME.
Everything is framed by language. Change the language and you are changing the game.
Naming things makes sense of the world, yet it can be bad for teams. Ironically, naming things reduces the [flow of We]. That is because the names are literally symbolic of things. Names create very real divisions.
We are seeing exactly this play out in these comments. This blog post is polarizing precisely because it makes attempts at nominalization. Nominalization encourages polarization.
Nominalization is how one way we make sense of things. Nominalization assigns names to things and reduces them to nouns. Nominalization is a linguistic device that allows you to turn a verb (and other word types) into nouns. It’s a trap that can limit perception and thinking at the level of We.
But wait, there’s more… click here to see the whole post:
http://newtechusa.net/agile/nominalization/
Meghana
March 15, 2012Of all the management gibberish that needs changing, “resources” is the first one that comes to mind.