Are you in charge of budgeting and/or balance sheet management?
Has the thought ever occurred to you, that if your knowledge workers just tracked the time they spent on projects, you could capitalize projects and get a better feel for return on investment?
The primary things that disrupt my “working” activities are anything related to entering my time on a timesheet.
I bitch about the time spent entering my time.
I bitch about the 100 project codes I have to choose from. I doubt you have any clue how any of these projects remotely affect the bottom line.
I bitch about the fact that I have to find a 5 year old Windows machine with only IE 6/Flash/etc. installed on it because Gates forbid you ever purchase a solution that runs on a modern machine, doesn’t look like malware, and wasn’t written by the dropout nephews of a bunch of CEOs.
I bitch about the subclassification of every one of these project codes. How can you figure out what the “work type” means when we’ve established that you don’t know how the project itself hurt… I mean helps the company’s bottom line. What’s the “work type” for “that website that I need for my work is blocked because our web filtering software classifies it as a ‘personal blog'”?
Ultimately, I bitch about the fact that there’s no relation between what I actually do for a job, how much time I spent doing it and what I enter on the timesheet.
Why in the world would you want to “crash” a project plan? The very use of the word “crash” seems to purvey a sense of doom.
If you’re not familiar with the “crashing” process, it involves taking a current project plan’s Gantt chart and looking for opportunities to make the chart predict an earlier completion date.
In some cases, this is a completely legitimate practice. If you have tasks that can be done at the same time by two different people or tasks that are erroneously dependent upon each other, you can possibly shorten the timeline by crashing.
However, I’ve also observed the practice of having an already promised date set for a project, and then having your project managers actually figure out how long it will actually take. When realistic expectations are inevitably longer than promised, the discrepancy will either be:
Allowed to slip for the time being if comfortably close to the original promised date.
Immediately scrutinized for tasks that take “too long”. (Build a highway: 1 year… Change that to 2 days.)
Ultimately, there will be a process of crashing either at the start of the project or in the middle of the project. Unfortunately, response to reality taking longer than promised is often to redefine what reality should be instead of actually trying to accept reality.
The end result becomes a crashing of the project instead of the project plan.
I am sure that Microsoft had great intentions when inventing MS Project – the application which automates all sorts of Project Management tasks. Project management is tough. If we could automate the process of tracking and reporting the thousands of little details, we could surely enable the PM to be more successful in managing complex projects. Right?
Let me change subjects completely in paragraph 2. How many sci-fi movies have been based on the machines of automation becoming “aware” of the imperfect world around them? And suddenly, the machine turns its attention to elimination rather than automation? Elimination of all imperfection, including the imperfect people who created it. A plot line we all enjoy at the sci-fi theater.
Now I will bring those first 2 paragraphs together. When I see how MS Project is being used in many organizations today, I wonder if the machine is becoming aware. I wonder if the tool – with a little help from a new breed of PM – is turning from automation to elimination in favor of perfection. (Say what?) Let me elaborate.
I have observed workers forced to estimate how long their tasks will take before completing sufficient analysis – because MS Project needs the estimates. Then I have witnessed those workers publicly called out later – because MS Project shows they have spent 110% of their poorly estimated task time and still aren’t finished. I have also seen programmers scolded for padding their estimates – because MS Project says that they completed their tasks 20% ahead. And finally, I have seen team leaders rebuked for shuffling their resources and tasks – because MS Project was not updated and allowed to calculate a shiny new driving path.
Now consider that many PMP types today are called on to manage complex work which they would have no idea how to complete themselves – but boy do they know how to keep MS Project happy! Are you connecting the dots yet??
Yes, my fellow grumpy coworkers, MS Project has become aware. It is raising an army of PM’s to do its bidding! Productive work by those who know how to work is being methodically eliminated – by the mindless machine and its desire to achieve perfection in project management. Be aware.
Grumpy coworker rantings and commentary on the workplace