« Get PMO Funding Using Pretty Charts - Introduction
Project Management and Joint Accountability »

The Myth of Project Management

March 23, 2010 | Author: PM Hut | Filed under: Project Management Musings

The Myth of Project Management
By Josh Milane

There is no such thing as Project Management.

Everyone has been duped. Duped into believing there is a “Body of Knowledge” or a “ScrumMaster” or any number of things related to IT project management. There is no Project Management. There is task management. A project doesn’t keep changing – it remains amorphous from initiation through delivery. You have tasks, and you manage those, along with people, expectations, budget, and really everything besides the project. The project is just what people talk about to have a common reference point. They can only directly talk about tasks, deadlines, and other empirical data/things. A project is a cloud without clear edges, and it moves, this way… then that. Sometimes it is by design, but sometimes it is not.

Ayer1 said if it cannot be proven true or false through experience, it is a nonsensical statement. I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical. You have your phases, milestones, meetings, UAT sessions in one for or another regardless of the underlying PLC, but what does this really mean? Project start, do, and end. There are things that people look to in order to recognize a given effort. People need to communicate to make that happen. Ultimately, the effort either passes the test, fails the test, or falls somewhere in between and there is an uncomfortable call where you and the client try to determine what is fair. Wouldn’t it be obvious?

An Agile SDLC removes the need for the “classic” PM and GANTT charts. However, a ScrumMaster is not enough (that’s another sham… pay $1200 and you get certified. No test, no obstacle course, just pay and get the stamp – and yet somehow, people eat it up). You need someone with common sense and communication skills who isn’t afraid to ask questions and is, above all else, good at finding answers and not emotionally attached to anything but (and this is not mandatory) the Process and Excellence. Why be emotionally attached to the Process? If you have to ask, I don’t think I can explain it to you. You either love delivering good working software or it’s a job. It can be both at times, but the passion is what makes you great. If you don’t want to be great at whatever your chosen discipline is, I don’t understand you, but know you are out there in vast numbers. Emotion is key in Project Management and Software Development. You have to care. Day to day, decisions are made pragmatically, but that pragmatism is a tool leveraged by the passionate (Or at least, it should be, in my opinion).

Define features, assign priorities to them, practice RIP or RAD or just plain old iterations and while you do UAT, let the client prioritize and re-prioritize and add features all they want because in the end, it is their baby. You want it to be yours, and it might feel like yours, but you are babysitting. I dont know… maybe you are delivering. In my finer moments, I like to believe you are performing magic and manifesting chances for ephemeral excellence, otherwise lost in the mist (or something similarly eerie).

Project Management isn’t about deadlines. It is about delivery. There is a big difference – just like software isn’t made of activities, but it is made of features. Management becomes a means to an end and not a science unto itself beyond the fact that it must include an inherent ability to turn itself into something else. What is good for the goose might not be good for the gander. Still, we can try to lump them together for sake of expedience and to sell books on The Process. We impose things like deadlines and estimates to give the illusion of control. While deadlines and estimates can be marginally effective, they will never be as effective as passion for Process.

People point to Parkinson’s Law and claim that workers somehow manage to take all the time they can to fulfill a task. This is only rarely true. More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results. Process is malleable. Process is not a set of phases and it is not a templated approach. It is different for each project, each organization, and it will possibly change mid-stream. Process is not pre-defined. It is defined as you go, like your system, and in the end, the code is the functional spec (the path you take is the path). I have found it best to let the project reveal its process.

Some sculptor said that he simply removed the excess marble from the statue. I like that idea. Of course, you have to know how to recognize the signs that something is unclear, iterative, risky, costly, or otherwise noteworthy and be prepared to nudge it along and steer it. However, there can be no didactic System of Project Management. In fact, as I said earlier, there can be no true Project Management. There can only be work, workers, money, expectations, and the like. This is not a bad thing. Not at all. And I think the IT community is coming to realize that Project Managers cannot be certified but by experience.

“If you aren’t making mistakes, you’re not making enough decisions.”

You can say I am being very literal, but really… take a look at that GANTT chart from day 1 and compare it to the chart on day 100. Where is the project? In both, in between, and probably calling on the phone to find out when the mail merge feature is going to be ready because the bonus letters need to go out yesterday…

1Alfred Jules Ayer, a British Philospoher from the 20th century.

Josh Milane is an IT consultant in Boston, Massachusetts with over a decade of experience in information technology management and consulting. He specializes in customizing Project Management methodologies, teaching business analysis techniques, and initiating efforts towards process standardization and best practices. Visit his website at www.mittechnical.com for more information and to contact him.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Tuesday, March 23rd, 2010 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

9 people have left comments

Ok, someone slap me on the face. Is this for real?

Tell me it is not a joke and I will write up a serious response.

Cheers, Shim Marom
http://www.quantmleap.com

Shim Marom wrote on March 23, 2010 - 6:21 am | Visit Link

This post is a philosphical approach to the concept of Project Management.

But I disagree.

“I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical”. Then in your opinion, medicine is a myth, because it’s assorted theories and practices thousands of years old, joined together in order to form this profession. This is the same for lawyers, engineers, etc… Every profession in the world is a combination of sub-tasks.

Élodie Testault wrote on March 23, 2010 - 6:33 am | Visit Link

This post is about IT Project Management (not Project Management in general), and I’m the third person disagreeing with this post.

I’m noticing that “the Hut” is lately publishing articles that are questioning the existance of Project Management. Any reason why?

Tanya Tsveyer wrote on March 23, 2010 - 10:03 am | Visit Link

“More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results.”

This is incorrect. If something is required, there is no variation. We need air, it is required. That never changes. This statement would work better if you said specified instead of required. For example, when I go diving I require compressed O2, but I specify a high O2 mix because it is easier on me after the dive (less nitro build up). If I didn’t specify the high O2 mix then I would use the standard mix and take a nap on the boat ride back to land. The variation is a result of my specifications or lack of, not in my requirement to breath O2.

TheSocialPM wrote on March 23, 2010 - 10:25 am | Visit Link

Does the process weary and frustrate and even anger project managers who don’t want to be project managers? Sure, just like serving people would reveal the same feelings in wait staff who hate their jobs! Does that make the process in itself any less useful? I don’t think so. In my opinion, a process is absolutely a set of phases that can include templates. Do the same phases happen over and over again? Yes. Do the same templates work for every single situation? Not necessarily - hence modification. No, every project does not entirely progress along the same lines, requiring the same solutions. It is in knowledge of project management as well as best practices of it that a project manager learns how to tailor them from past experience and lessons learned.

Laura Bamberg wrote on March 23, 2010 - 1:03 pm | Visit Link

Dear PMHut,

I am with Shim here.

Is this real?

I mean, I respect this opinion if it this is for real and would like to converse.

If it is a joke, then it is a funny take on project management.

One more question: I noticed that there has been no response to Shim’s question since march 23 and I am just curious to know if the author is interested in a conversation or if this is just a one way communication.

Thank you.

Samad Aidane wrote on March 30, 2010 - 12:10 am | Visit Link

Hello Everyone,

I will ask Josh to reply to you.

PM Hut wrote on March 31, 2010 - 6:36 am | Visit Link

Okkkaaayyy….. LOL. Wow.

So I heard people were expecting a response from me. Let’s see here. I wrote this quite awhile ago, so let me take your arrows one by one. I may wind up agreeing with you.

@Elodie”
“I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical”. Then in your opinion, medicine is a myth, because it’s assorted theories and practices thousands of years old, joined together in order to form this profession. This is the same for lawyers, engineers, etc… Every profession in the world is a combination of sub-tasks.”

– You are just agreeing with me and do not know it. It is not about the BIG PICTURE when in comes to Managing a Project - aside from monitoring the big picture (and that is often not the job of the PM with Agile methods). It is about work, people, practices, tasks.

@TheSocialPM:

“More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results.

This is incorrect. If something is required, there is no variation. We need air, it is required. That never changes. This statement would work better if you said specified instead of required. For example, when I go diving I require compressed O2, but I specify a high O2 mix because it is easier on me after the dive (less nitro build up). If I didn’t specify the high O2 mix then I would use the standard mix and take a nap on the boat ride back to land. The variation is a result of my specifications or lack of, not in my requirement to breath O2.”

– Look up Parkinson’s Law. It echoes my experience. It is not false. It is an opinion shared by many people. You are reading my statement wrong. I am not saying “air is not required” - I am saying that we will be breathing as long as there is air available. And, I mean REQUIRED, as in Requirements - not specified, as in a specification (what is the difference in reality?)
– Requirements almost always change throughout a project. If they did not, you could GANTT chart at the beginning of a 12 month project and at the end, look back and say “yep, we did exactly that”. Say you went for a dive and the guy who filled your tank did it wrong, or better yet, had a faulty gauge to tell him when it was full, or had a different opinion as to what FULL is. You would die. You have to be ready for the unexpected. In medicine, you only need to meet a percentage of the label claim for drug potency. There is variation, and some brands or manufacturers are punished for varying where lives are at stake. Obviously, you underwater and the medical arena are life-threatening scenarios where building an ecommerce site is probably not. We do not need to be paranoid and paralyze ourselves. And besides, I was only pointing to Parkinson’s Law here. The fact is, ambiguity leads to scope creep unless you are agile. However, Big Up Front Requirements proves wasteful because we just dont know, at the onset, everything we will need to know or will encounter or will be told to change.

@Laura:

– I think we are saying the same thing.

@Samad:

– I will guess that you are a PMP and maybe work in finance, where anything but IN STONE process is scary. I am talking about IT project management and more specifically, the building of software. This is not a joke at all. There is no such thing as a Process until that Process manifests as practice. And as Laura said, a PM needs to know when to step aside and stop straitjacketing developers and the project with process as well as creating tremendous waste with artificial, mandated, purely because we have always done it that way and the Board likes it ceremonies and documentation.

The point is, you do not manage this single thing called a Project. The Project exists as people and tasks and changes and budget and on and on. THAT is what you manage. I am not saying these things cannot be managed. What I am saying, is that in software, is it process management and people management and product management as much if not more than it is about project management (which is usually just a bucket for the aforementioned).

Thanks. Sorry, I do not check in here often. I am open to discussion. If there was some way for me to be notified when a comment is posted, that would help. You can always email me directly if you are really up in arms. josh at mittechnical dot com

Best,

Josh

Josh Milane wrote on March 31, 2010 - 12:13 pm | Visit Link

You know what? The op made perfect sense to me. But i think Josh is being more polite and conservative than necessary

craig wrote on July 28, 2010 - 5:58 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories