There is one trait of poor management that really irritates me. Indecision. I like a fast moving organization that makes decisions. A long time ago, I read that AOL was like that. Their managers made snap decisions and deals without any deliberation. Too fast for the tastes of some. Of course AOL/Time Warner didn’t turn out so well…
But lots of the companies I work with are paralyzed with indecision. Here’s the kind of management I deal with all the time.
No… we couldn’t add the new Whiz Bang feature to the product because we needed Dan’s approval. He was out on vacation until the end of the month, and had 10,000 spams to deal with when he returned. Of course, we also needed Pam, Jim, and Joe’s input, but we couldn’t get them all scheduled for a meeting at the same time. Joe was busy with Mary’s project, Pam needed to review the specs again, and I don’t think Jim likes me. I’m not sure what the status is now…
Is it any wonder things don’t get done? I don’t see any negative consequenses to indecision. “Oh, you didn’t get the project done? Oh, that’s okay…” With a tightening economy, this don’t work.
My advice: if you are the manager of a project team, give your people the lattitude to make quick decisions – for good or for bad. The cost of indecision is higher than the cost of mistakes – IMHO.
I really wish I’d thought of this one… 🙂 (See the link below for PMI’s PM Network Magazine.) Two project management auditors gang up on Wyatt Earp, demanding to know why he’s failed so miserably at the O.K. Corral. They examine his project management methods and results, siting all kinds of iregularities. Poor Earp has failed miserably in his famous gun battle, and he doesn’t even know why.
Article by Michael Hatfield:
The point Hatfield is making is this: sometimes you just have to go out with guns blazing. Some projects just need to get done, regardless of what the experts say. I’ve done enough all-nighter’s, 24-hour weekends, and three-day coding summits to know what he is saying. The big showdown is sometimes what it takes to get the job done, and honestly, you feel like a gunfighter when the dust finally settles!
So, the next time your manager asks how you finished your project so quickly, tell him you went “Wyatt Earp” on it!
What is a project stakeholder? Any person who has something to lose if the project fails.
This normally includes higher-level people in the organization. People who would personally fail if the project fails. This can include customers, shareholders, executives, vice presidents, and even high-level managers.
A complete or partial project failure would cost these individuals something. It may cost them money, time, or position.
Every project has stakeholders, even small ones. It is important to identify these people. Who stands to lose something if the project goes over budget, is late, or is never completed? Those people will natually want to control the effort, and have the right to do so. They hold the purse strings, and they go down with the project.
Does that mean a project stakeholder controls every aspect? No. They must trust those who execute it. In other words, there will be engineers, technicians, and other creative people who actually do the work. Much of the ground-level control is in their hands. They report to the project stakeholders who direct their overall efforts.
This post will help you understand the Resource Graph in Microsoft Project. The Resource Graph shows a graphical view of when your employees are scheduled to work. You should also take a look at the Resource Allocation window in Standard Time. It has additional options to help view scheduled employee hours.
Steps to use the Resource Graph:
- Create a new task in a blank Microsoft Project file
- Enter 4 hours into the duration column and assign the task to your name
- Choose View, Resource Graph
- Right-click in the graph, and choose Work from the menu
- Notice the blue bar representing the hours you entered (it stops at the “4h” line)
- Choose View, Gantt Chart to go back to the task view
- Create a second task, enter 5 hours, and assign it to you
- Choose View, Resource Graph to see the effect
- Notice that the blue bar has a red bar on top (this is the over allocated portion)
The previous steps demonstrate two simple principles: a graphical representation shows when employees are scheduled to work, and over-allocated hours are shown in red. Standard Time takes this a step farther and shows under-allocated time in yellow.
Steps to add another resource:
- Choose View, Gantt Chart to see your tasks
- Add another task, enter some hours, and assign it to another resource
- Choose View, Resource Graph to return to the bar graph
- Right-click in the legend, and choose Next Resource
- Notice that the bar chart changes to show the hours for your second employee
Standard Time allows you to see groups of employees stacked on top of each other. This lets you see allocated hours for the entire workgroup.
Steps to change working hours for a resource:
- Right-click on the legend, and choose Resource Information
- Click the Working Time tab
- Click in the calendar to select a day
- Drag the mouse to select multiple days
- Change the working hours at the right side (you are overriding the defaults)
- Click OK to return to the Resource Graph
- Notice that the bars change to reflect your new working hours
Normally, you’ll leave the working hours at 40, and change the start dates of tasks to reschedule them.
We hope this has helped. Feel free to post comments on additional usage techniques!
If you’ve ever read a project management book, you’ve run across the statistic that 50 – 70% of all projects are over budget. Seen that, right?
What’s up with that? More times than not, I would guess that is a tactic to hook you into something. Maybe, it’s to buy a book. Or, a take a webinar, or buy consulting services. Look closely at the context the next time you see that. I will too. Now I’ve gotten myself curious. 🙂
But I wonder how they know. First off, only organizations that track their projects (time tracking, resource tracking, etc) know if they are over budget. And most people don’t do that. Instead, they fly by the seat of their pants, relying on hunches.
Secondly, so what? When your project is finished, you’ve probably happy about that, and don’t care to look back – unless you’ve taken a real black eye. It’s usually the fit-and-finish that takes three times longer than anticipated, but you’re always proud of the final product. So why worry about a little extra moolah.
How’s your project coming? Is it over budget yet?
How long does it take you to launch a new product? Doesn’t it always seem to take 2-3 times longer than anticipated? I’ve been involved in the launch of over fifty new products, and it’s always the same routine.
We have a great idea, which seems so simple. If we take our existing product and just tweak it a little here and there, we can introduce something new. Simple enough, right? Wrong.
Products take an incredible amount of time to mature. A few tweeks suddenly turns into a handful, and then more. Current products need attention, drawing your resources away from the new one. Excitement wains when people realize the instant payoff won’t be there. This is turning into work… We never expected this!
I’d like to hear your project team experiences with new products, and new revisions. How smooth is it for you?
Have you heard of the “Optimizing Organizational Performance” webinar PMI is hosting? It’s free, and the blurb looks good. I’ve already registered. Here’s the link below.
Here’s why you should attend:
AstroWix quote: Each year, an estimated $10 trillion is spent on projects around the world and almost 50% of them fail.
I’d like to hear your opinions, after the webinar. What did you learn? Was it over your head? Beneath you? Feel free to submit your comments here – that is, if you remember this blog posting after April 30th.
I personally don’t like heavyhanded project methodologies. Anything heavier than a project plan, timesheet, and regular meetings bothers me. I understand the need for process overhead, but sometimes people get carried away. Of course, the simple approach assumes a top-down buy-in from upper management, something I always have. Other organizations don’t have it so good. So, let’s see how this PMI webinar works!
Do you use project planning software like Microsoft Project to develop project plans? How’s that working for you? I have a problem with it, and I’d like to find an elegant solution.
What’s the problem? Well, building project plans is no trouble. I can lay down the phases and breakdowns, add tasks, and assign them to employees just fine. That’s the easy part. I can even track time to tasks. The problem I have is managing them later.
Let’s face it, project plans go obsolete the first week you create them. Something’s bound to change, and managing all those changes is hard. Yes, I know that’s what the PMO office does. But keeping project schedules current rubs me like a cheese grater. It’s an unnecessary overhead, and almost never gets done right. Tasks move, change scope, go away, get added, etc, etc, etc. You know what a headache it is…
Anybody have a better way?
There’s almost nothing good you can say about a plant closing. Especially with potentially 9,000 people losing their jobs. (See: http://www.eweek.com/c/a/Desktops-and-Notebooks/Dell-Closing-Austin-PC-Plant-in-Cost-Cutting-Drive/ )
The PC vendor announced March 31 that it would begin cutting costs and improving its efficiency in the second half of 2009 fiscal year. Besides announcing the closing of the Austin plant, Dell reaffirmed that it plans to eliminate nearly 9,000 positions as part of the cost cutting.
The only thing I’d like to say is, “fight for it!” I remember working for a huge company, where the average workday (in our engineering department) was five hours. Of course, this was a 8-hour shift, but nobody worked it. We got our coffee in the morning, caught up on the previous night’s adventures, and then did a little work before lunch. After lunch, a little more work, and then water cooler discussions of the evening’s plans.
Needless to say, that company cut 40,000 jobs in the late 80’s. I don’t remember ever fighting for the company’s survival, or even for competitive positioning. The culture simply wasn’t there.
I’m sure this is not the case with Dell. They are highly competitive. Sometimes things like this are out of our control. But let’s fight for our positions anyway!